RHEL on the public cloud marketplace, read carefully.
RHEL on a public cloud marketplace is the variant where the entitlement and the billing relationship are split. The cloud provider meters the host hours; Red Hat collects the subscription portion through the cloud bill. The buyer side reading turns on whether the same workload should ride the marketplace or move back onto the buyer's own Red Hat contract under Cloud Access. This note walks the two billing modes, the four workload patterns that decide between them, and the audit reading when both modes are in play.
Two paths onto the same instance.
RHEL on a public cloud marketplace arrives in two billing modes that the cloud provider exposes as different operational choices. The first mode is pay as you go. The buyer launches a RHEL image from the cloud provider's marketplace; the cloud provider meters the instance hours and bills the RHEL subscription portion alongside the compute on the cloud invoice; the entitlement is for the hours the instance ran. The second mode is bring your own subscription, frequently labelled Cloud Access. The buyer launches a RHEL image under an entitlement on the buyer's own Red Hat contract; the cloud provider bills only the compute, and Red Hat bills the subscription on the buyer's existing line items.1
Both modes appear on the same cloud and on the same instance type. The difference is operational, not technical. The pay as you go path is administratively simpler: the buyer needs no Red Hat contract to start, the per hour metering aligns with elastic workloads, and the cloud invoice carries the entire RHEL cost. The Cloud Access path is, in steady state, frequently cheaper per instance hour for stable workloads under a committed Red Hat line, but the path requires a Red Hat contract and a registered entitlement on the cloud workload. Cloud Access is the path discussed in RHEL elasticity models.
The variant interacts with the rest of the RHEL subscription set discussed in RHEL subscription models explained and with the cloud specific OpenShift discussion in OpenShift on AWS, Azure, GCP, IBM Cloud. The cloud marketplace path is also where the practice observes the most frequent slippage between the buyer's view and Red Hat's view of the running estate, and where the audit reading therefore has the most to discover.
Four workload patterns that choose for you.
Four workload patterns recur as the structural decision between marketplace pay as you go and Cloud Access on the buyer's own contract. The decision is rarely a single estate wide answer; the four patterns appear in different proportions within the same buyer.
The first pattern is the elastic batch workload. Instances spin up to process a job and spin down when the job ends. Hours per instance are short; the population of running instances varies by the hour; the workload's annual hour count is unpredictable. The pay as you go path matches the metering to the consumption; the Cloud Access path requires forecasting the hours in advance and pays for the headroom. The pay as you go path wins for elastic batch.
The second pattern is the development and test estate. Instances are launched and terminated frequently; the per instance lifespan is short; the estate is heterogeneous in terms of instance types. The pay as you go path again matches the metering to the consumption, and the administrative simplicity of not having to attach a Red Hat entitlement to every short lived instance is a separate operational virtue. The pay as you go path frequently wins for development and test.
The third pattern is the steady state production fleet. Instances run continuously, the population is stable across the year, the instance types are predictable. Cloud Access on a committed Red Hat line is, per instance hour, frequently cheaper than the marketplace meter. Cloud Access wins for steady state production, provided the Red Hat side line is correctly sized.2
The fourth pattern is the data residency or sovereign workload. The cloud provider's commercial invoice may travel through routes the buyer's legal team does not want for the RHEL subscription portion; or the entitlement carries support implications the marketplace meter does not. Cloud Access on the buyer's own contract gives the legal team the contract path it expects. The legal posture wins regardless of the per hour arithmetic.
| Workload pattern | Path | Why |
|---|---|---|
| Elastic batch | marketplace | metering matches usage |
| Development and test | marketplace | short lived instances |
| Steady state production | Cloud Access | committed line cheaper |
| Sovereign or data residency | Cloud Access | contract path required |
The audit reading when both modes are running.
The audit reading on a marketplace estate joins three data sources. The cloud provider's billing record of pay as you go RHEL hours. The buyer's Red Hat subscription register of Cloud Access entitlements. The host inventory of running RHEL instances on each cloud account. The reading is internally consistent when every running RHEL instance is either on the marketplace meter or against a registered Cloud Access entitlement, and when no instance is double counted across both.3
Three inconsistencies recur. The first is the Cloud Access entitlement attached to an instance that the cloud provider is also billing through the marketplace. The buyer pays twice for the same instance hour; the audit reading frames this as overpayment to be retired, not exposure. The remediation is to either remove the Cloud Access registration or to relaunch the instance from a Cloud Access image rather than a marketplace image.
The second inconsistency is the marketplace instance carrying neither a marketplace meter nor a Cloud Access entitlement. The image was a custom image derived from a RHEL base, the registration was stripped during the customisation process, and the cloud provider's billing record carries the instance only as compute. The audit reading cites the instance as unentitled RHEL for the period of operation. The remediation is to attach a Cloud Access entitlement going forward; the period of past operation is the basis for the settlement reading.
The third inconsistency is the Cloud Access instance running outside the buyer's named cloud accounts. A workload launched in a partner cloud account, a sandbox account, or a new business unit account uses the buyer's Red Hat entitlement; the Red Hat side reads the registration through the cross account relationship; the buyer's subscription assessment does not see the account. The reading is structurally similar to the cluster expansion trap in RHEL Unlimited Virtual when it pays. The remediation is an account inventory of record that includes every cloud account the entitlement can reach.
The renewal posture that holds both contracts honest.
The marketplace path produces a parallel set of renewal mechanics. The cloud provider's renewal cycle, the buyer's Red Hat renewal cycle, and any committed cloud spend agreement that includes RHEL all interact. A renewal posture that holds both contracts honest has three habits.
The first habit is the per workload path log. Every RHEL workload on the cloud is tagged with the path that bills it. Marketplace pay as you go or Cloud Access. The log is reviewed at each renewal cycle of either contract. Workloads that have changed pattern across the year are reassigned; the log is the artifact that drives the assignment, not the cloud provider's billing default. The log sits inside the subscription assessment.
The second habit is the committed cloud spend reading. Cloud providers frequently include RHEL in commitment programmes that discount marketplace RHEL hours against a committed cloud spend total. The discount changes the per hour arithmetic against Cloud Access; the discount is also negotiated separately from the buyer's Red Hat contract. The renewal posture reads both contracts together; the alternative is to negotiate each contract against the other without realising the interaction. The broader posture is in renewal negotiation.
The third habit is the Cloud Access entitlement sizing. Cloud Access pulls from the buyer's RHEL subscription pool; the pool size must accommodate the cloud workload alongside the on premise estate; a pool sized only for on premise will run short when the cloud workload spikes. The Cloud Access pool sizing is an annual exercise, not a renewal cycle exercise. The pool is right sized at the start of the year on the projected workload, and adjusted at the renewal cycle on the actual.4
For the broader exit reading on cloud workloads, see exit planning. For an engagement against the desk, see the contact form.
Notes & references
- 1. Red Hat Cloud Access is the programme that permits subscriptions on the buyer's own Red Hat contract to entitle RHEL on supported cloud providers. The programme has changed naming and scope across releases; the mechanic of pulling from the buyer's subscription pool to entitle a cloud instance is the persistent feature. The cloud providers each expose their own marketplace path in parallel.
- 2. The per hour arithmetic between marketplace and Cloud Access on a steady state workload depends on the buyer's committed line discount on the Red Hat side and the marketplace per hour rate on the cloud side. The practice observes Cloud Access cheaper on most steady state workloads where the buyer's Red Hat commitment is mature; the inverse can hold at low volume positions.
- 3. The audit reading on a marketplace estate requires the cloud provider's billing record at the line item level. Buyers without this visibility can request the billing data from the cloud provider; without it, the reading rests on the host inventory and the Red Hat side records alone, which produces a less complete picture.
- 4. Cloud Access pool sizing is the most frequent miss in the practice's observation. Buyers who size the pool at the start of the year on the on premise estate alone, and then attach cloud workloads through the year, run out of pool on the cloud workloads and are pushed into ad hoc marketplace consumption. The annual sizing exercise prevents the slippage.
- 5. The interaction between cloud committed spend programmes and Red Hat renewal cycles is sensitive to the specific cloud and the buyer's commitment posture. The practice reads both contracts together as part of the renewal cycle review.
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.