RHEL on Azure, read against the VM hour.
RHEL on Azure marketplace economics turn on the pay as you go posture where Microsoft bills the buyer an hourly surcharge for RHEL over the underlying Azure compute hour, and the bring your own subscription posture where the buyer attaches an existing RHEL subscription via Red Hat Cloud Access. Azure subscription scope, the Hybrid Benefit posture, and the Enterprise Agreement billing relationship add a second layer of reading on top of the cloud sub estate. The buyer side reading on Azure turns on whether the Azure subscription inventory has been reconciled against the procurement register at the subscription scope, not at the Enterprise Agreement aggregate.
RHEL on Azure, in plain language.
RHEL on Azure marketplace economics describes the cost and entitlement reading on the Azure virtual machines of a buyer running RHEL inside an Azure estate. Microsoft sells RHEL through the Azure Marketplace as a Red Hat partner offering, and the Azure VM running a RHEL image is billed at a tier above the equivalent VM running a Canonical or SUSE base. The surcharge is hourly, the entitlement flows back to Red Hat through the marketplace agreement, and the buyer is invoiced through Azure rather than directly by Red Hat. This is the pay as you go posture, abbreviated PAYG, and it is the default for an Azure VM launched from a Red Hat published RHEL marketplace image.1
The second posture is the bring your own subscription posture, abbreviated BYOS, where the buyer attaches an existing RHEL subscription to an Azure VM through the Red Hat Cloud Access programme. The Cloud Access enrolment is the structural mechanism that permits a subscription purchased directly from Red Hat to be used on an Azure VM. The Azure side recognises the entitlement, and the VM is billed at the OS less rate without the RHEL surcharge. The two postures are structurally different and behave differently on cost and on the audit reading. The cross reading with the equivalent posture on AWS sits in the RHEL on AWS marketplace economics note; the underlying breakeven calculation sits in the RHEL bring your own versus pay as you go breakeven.
The Azure side adds a third structural reading the buyer must account for. The Azure Enterprise Agreement, when present, frequently aggregates the marketplace billing under a master account that flattens the visibility of which Azure subscription scope is running which workload. The reading at the Enterprise Agreement aggregate is not the same as the reading at the subscription scope; the procurement register that walks the aggregate misses the per scope distribution. The cross reading with the broader RHEL practice sits in the RHEL practice and the reading of cloud variant pricing across providers sits inside the RHEL on public cloud marketplace note.
The three counting traps the Azure reading encounters.
Three counting traps recur on RHEL on Azure readings. Each is structural; each remediates inside the next renewal cycle on the Azure side, the Red Hat side, or both.
The first trap is the Azure subscription scope the procurement register has never seen. A large Azure estate operates across dozens of Azure subscriptions for business units, environments, and regulatory boundaries. The procurement register that reads against the central Azure subscription, the Enterprise Agreement billing master, or the prior fiscal year subscription list misses the subscriptions opened or transferred across the trailing twelve months. The reading depends on which posture the new subscriptions are running. If PAYG, Azure is billing through and the cost is visible on the Azure bill but invisible to the Red Hat procurement register; if BYOS, the new subscriptions may be running without enrolled Cloud Access entitlement. The pattern overlaps with the broader treatment in shadow Red Hat usage in mergers and acquisitions.2
The second trap is the parallel posture without reconciliation. A buyer runs a fleet of Azure VMs some of which are PAYG and some of which are BYOS, with no inventory of which is which. The Azure bill carries the PAYG surcharges; the Red Hat agreement carries the BYOS 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 Azure subscription level inventory pass to identify which VMs are PAYG and which are BYOS, followed by the elimination of the duplicated lines at the next renewal cycle. The pattern sits inside the broader treatment of recoverable over entitlement cost.
The third trap is the Reserved Instance commitment for an OS less workload that is in fact running RHEL via PAYG. The buyer reserved the Azure compute for three years to lock in the discount on the VM hour; the VM is running a RHEL PAYG image; the reservation discount applies to the compute base but not to the RHEL hourly surcharge. The buyer who modelled the reservation against the all in cost will frequently overshoot the savings; the reservation does not cover the marketplace surcharge. The cross reading with the broader Reserved Instance pattern sits in the parallel treatment of RHEL spot and preemptible instance economics.
| Posture | Billed by | Procurement register |
|---|---|---|
| PAYG (marketplace image) | Azure hourly | Azure invoice line |
| BYOS (Cloud Access) | Red Hat direct | Red Hat sub line |
| In place converted | both | overlap risk |
| Reserved compute + PAYG OS | partial | surcharge unmoved |
The Enterprise Agreement aggregate, read against the scope.
The Azure Enterprise Agreement is the structural mechanism that aggregates the buyer's Azure spend under a master commercial relationship with Microsoft. The marketplace billing for RHEL PAYG flows through the Enterprise Agreement as a line item; the aggregate is visible to procurement; the per subscription scope distribution is not always visible without the subscription level cost report. The reading discipline is the same as the AWS organisation level read but with one structural difference: the Azure Enterprise Agreement has its own commercial cycle, distinct from the Red Hat renewal cycle, and the two cycles do not always align.3
The renewal posture should account for both cycles. A buyer entering an Azure Enterprise Agreement renewal frequently has flexibility to renegotiate the marketplace surcharge structure for committed workloads; the buyer entering a Red Hat renewal cycle has flexibility on the Cloud Access enrolment count and tier. The two cycles are independent commercial events with overlapping subject matter. The discipline overlaps with the broader treatment in multi region Red Hat agreements where the same dual cycle discipline applies to global estates.
The cross cluster bridge sits in healthcare audit considerations where Azure is the most common cloud reading in payer environments; HIPAA boundary readings and the Azure subscription scope frequently coincide.
The audit reading, at the subscription scope.
The audit reading on RHEL on Azure walks three artifacts. The Azure subscription level inventory of VMs running RHEL, the Azure 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 VM with a RHEL image either carries a PAYG line on the Azure bill or is registered against an enrolled Cloud Access subscription, with no VM carrying both and no VM carrying neither.
The most common audit reading misstep on Azure is the use of the Enterprise Agreement aggregate as the inventory. The aggregate flattens the per scope distribution. The remediation is the subscription scope level inventory pass at the renewal cycle, performed against the Azure Cost Management export at the per subscription resolution. The Azure subscription scope is the cloud equivalent of the AWS account; the procurement register reads against scopes, not against the Enterprise Agreement aggregate. The discipline overlaps with the broader treatment in aligning subscription to deployment.4
The second misstep is the failure to read the VM image source. An Azure VM may have been deployed from a Red Hat published marketplace image, from a custom image built by the buyer, or from a snapshot of a previously running VM. The licensing posture depends on the source; a custom image without a marketplace plan attached does not carry the PAYG line and requires the BYOS posture. The remediation is the image source audit at the renewal cycle. The pattern interacts with the broader audit defense framework in audit defense.
The renewal posture, against the Azure inventory.
The renewal posture on RHEL on Azure has three habits.
The first habit is the Azure subscription level read. The renewal input is the inventory of VMs running RHEL across every Azure subscription scope, classified by posture and image source. The discipline sits inside the broader treatment in the 90 day subscription assessment.
The second habit is the dual cycle alignment. The Azure Enterprise Agreement cycle and the Red Hat renewal cycle are anticipated together. The buyer who lets the cycles drift independently frequently misses the leverage moment when both are open at once; the buyer who anticipates the alignment carries leverage into both negotiations. The sibling treatment sits in three year commit protections.
The third habit is the cross provider read. A buyer running RHEL on Azure frequently also runs RHEL on AWS, GCP, or IBM Cloud; the renewal posture is rationalised across the providers. The cross reading sits in the RHEL on AWS 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 an engagement against the desk, see the contact form.
Notes & references
- 1. RHEL on Azure is sold through the Azure Marketplace as a Red Hat partner offering. Azure VMs launched from Red Hat published marketplace images carry an hourly surcharge above the equivalent OS less VM; the entitlement flows back to Red Hat through the marketplace agreement.
- 2. The Azure subscription scope the procurement register has not seen is the most common single finding on Azure readings. Large Azure estates operate across dozens of subscriptions and the procurement register that reads against the Enterprise Agreement aggregate misses the per scope distribution.
- 3. The Azure Enterprise Agreement and the Red Hat renewal cycle are independent commercial events with overlapping subject matter. The buyer who anticipates the alignment carries leverage into both negotiations.
- 4. The Azure subscription scope is the cloud equivalent of the AWS account; the procurement register reads against scopes, not against the Enterprise Agreement aggregate. The cost management export at the per subscription resolution is the renewal input.
- 5. The Reserved Instance discount applies to the Azure compute base but not to the RHEL marketplace surcharge. A buyer who modelled the reservation against the all in cost will frequently overshoot the savings.
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.