RHEL on AWS, read against the EC2 hour.

RHEL on AWS marketplace economics describes the cost and entitlement reading on the EC2 instances of a buyer running RHEL inside an AWS estate. AWS sells RHEL through the AWS Marketplace as a Red Hat partner offering, and the EC2 instance running a RHEL image is billed at a tier above the equivalent EC2 instance running the Amazon Linux base. The surcharge is hourly, the entitlement flows back to Red Hat through the marketplace agreement, and the buyer is invoiced through AWS rather than directly by Red Hat. This is the pay as you go posture, abbreviated PAYG, and it is the default for an EC2 instance launched from a Red Hat published RHEL marketplace image.1

The second posture is the bring your own subscription read, where the buyer attaches an existing RHEL subscription to an EC2 instance through the Red Hat Cloud Access programme. The Cloud Access programme is the structural mechanism that permits a buyer to use a subscription purchased directly from Red Hat on an AWS EC2 instance; the buyer enrols specific subscriptions, AWS recognises the entitlement, and the EC2 instance is billed at the OS less rate. The two postures are structurally different and behave differently on cost and on the audit reading. The cross reading with the underlying pay as you go versus bring your own cost analysis sits in the RHEL bring your own versus pay as you go breakeven note.

What the buyer pays for on AWS is the EC2 hour. The EC2 hour carries either a RHEL surcharge or it does not; if it does, the entitlement is the PAYG line; if it does not, the entitlement must be a Cloud Access attached subscription, an in place upgrade from a marketplace image, or a missing entitlement. The third case is the source of the audit reading. The cross reading with the broader RHEL practice sits in the RHEL practice and the reading of cloud variant pricing across providers sits in the RHEL on public cloud marketplace note.

Three counting traps recur on RHEL on AWS readings. Each is structural; each remediates inside the next renewal cycle on the AWS side, the Red Hat side, or both.

The first trap is the parallel posture without reconciliation. A buyer runs a fleet of EC2 instances some of which are PAYG and some of which are Cloud Access attached, with no inventory of which is which. The AWS bill carries the PAYG surcharges; the Red Hat agreement carries the Cloud Access subscription lines; the buyer is paying both lines for some portion of the fleet. The reading is overpayment on the overlap. The remediation is the AWS account inventory pass to identify which instances are PAYG and which are Cloud Access, followed by the elimination of the duplicated lines at the next renewal cycle. The pattern is the most common single finding on AWS readings in the practice's observation and sits inside the broader treatment of recoverable over entitlement cost.2

The second trap is the AWS account that the procurement register has never seen. The enterprise has, over the trailing year, opened additional AWS accounts for business units, acquisitions, or development teams; each new AWS account runs RHEL EC2 instances; the procurement register reads against the central AWS account list from the prior fiscal year. The reading depends on which posture the new accounts are running. If PAYG, AWS is billing through and the cost is visible on the AWS bill but invisible to the Red Hat procurement register; if Cloud Access, the new accounts may be running without an attached subscription. The AWS account inventory should be the first input to the RHEL procurement register read on cloud, not the last. The remediation overlaps with the broader treatment in shadow Red Hat usage in mergers and acquisitions.

The third trap is the marketplace image converted in place. A buyer launched an EC2 instance from a PAYG RHEL marketplace image, ran a subscription manager attach to a Cloud Access subscription, and continued operating the instance. Depending on the configuration, the instance may continue to be billed as PAYG on the AWS side while consuming a Cloud Access entitlement on the Red Hat side, producing the duplicated reading on a per instance basis. The remediation is the procedural discipline of either launching from a bring your own image when Cloud Access is intended or accepting the PAYG line and not attaching a second subscription. The cross cluster bridge sits inside the broader treatment of financial services audit considerations where AWS posture is the most common cloud reading in the bank vertical.

The Cloud Access programme is the structural lever that permits the buyer to substitute a directly purchased RHEL subscription for the AWS PAYG line. The mechanics are unglamorous: the buyer enrols specific subscriptions in Cloud Access through the Red Hat customer portal, AWS recognises the enrolment, and EC2 instances launched from Cloud Access marketplace images or converted via subscription manager attach are billed without the RHEL surcharge. The Cloud Access subscription line is identical to the on premise RHEL line; the entitlement is portable rather than purpose built.3

The economic argument for Cloud Access is the breakeven on utilisation. The PAYG hourly surcharge is structurally above the hourly cost of an equivalent always on Red Hat subscription; the breakeven point sits in the range of typical production workloads but well above ephemeral or low utilisation patterns. The sibling treatment of the breakeven calculation sits in the RHEL bring your own versus pay as you go breakeven note; the cloud variant of the ephemeral pattern sits in the parallel note on the RHEL spot and preemptible instance economics.

The audit reading on the Cloud Access side has its own discipline. The Cloud Access enrolment record is the artifact: an enrolled subscription is portable to AWS, an unenrolled subscription is not. A buyer running an EC2 fleet on the Cloud Access posture without the corresponding enrolment is exposed on the entitlement. The remediation is the enrolment pass at the next renewal cycle. The discipline parallels the broader reading on the Red Hat Insights data and audit interaction.

The audit reading on RHEL on AWS walks three artifacts. The AWS account inventory of EC2 instances running RHEL, the AWS marketplace billing record for PAYG line items, and the Cloud Access enrolment record on the Red Hat side. The reading is internally consistent when every running EC2 instance with a RHEL image either carries a PAYG line on the AWS bill or is registered against an enrolled Cloud Access subscription, with no instance carrying both and no instance carrying neither.

The most common audit reading misstep is the use of the central RHEL subscription register as the AWS estate inventory. The two are not interchangeable. The Red Hat side records the Cloud Access enrolment; the AWS side records the EC2 line items; the reconciliation is the buyer's discipline, not Red Hat's and not AWS's. The remediation is the AWS account level inventory pass at the renewal cycle, performed against the AWS Cost and Usage Report or the equivalent billing data source. The discipline overlaps with the broader treatment in aligning subscription to deployment.4

The second misstep is the failure to read the AWS organisation level. A large buyer running AWS at scale typically operates dozens or hundreds of AWS accounts under an AWS Organisations master. The procurement register that reads against the master account, the central billing account, or any single account is reading against a slice and not the estate. The remediation is the organisation level query. The pattern interacts with the broader audit defense framework in audit defense.

The renewal posture on RHEL on AWS has three habits.

The first habit is the AWS organisation level read. The renewal input is the inventory of EC2 instances running RHEL across every AWS account in the organisation, classified by posture. The discipline sits inside the broader treatment in the 90 day subscription assessment.

The second habit is the posture rationalisation. At the renewal cycle, the buyer reads which workloads should remain PAYG, which should move to Cloud Access, and which should be retired. The reading is utilisation driven; the breakeven sits inside the parallel treatment of the bring your own versus pay as you go breakeven.

The third habit is the cross provider read. A buyer running RHEL on AWS frequently also runs RHEL on Azure, GCP, or IBM Cloud; the renewal posture is rationalised across the providers. The cross reading sits in the RHEL on Azure marketplace economics note and the parallel treatment in the RHEL on GCP marketplace economics note. The broader treatment of renewal cycle discipline sits in renewal negotiation. For the parent service hub on the renewal cycle, see renewal negotiation. For an engagement against the desk, see the contact form.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.