BYOL or PAYG, read at the breakeven.

RHEL bring your own subscription versus pay as you go on cloud is the rationalisation decision a buyer running RHEL on the public cloud makes for each workload class. The pay as you go posture, abbreviated PAYG, bills the buyer an hourly RHEL surcharge through the cloud provider's marketplace; the bring your own subscription posture, abbreviated BYOL or BYOS, lets the buyer apply a directly purchased Red Hat subscription to the cloud host through the Red Hat Cloud Access programme. The hourly line and the annual line are structurally distinct cost mechanisms; the buyer who has not chosen between them has chosen both for some part of the fleet.1

The economic argument is simple in form and operationally demanding in practice. The PAYG line is variable on the hour: a host that runs four hundred hours in a year pays four hundred hours of RHEL surcharge. The BYOL line is fixed on the year: a subscription paid for the year covers the host for the year regardless of whether the host ran four hundred hours or eight thousand. The breakeven sits at the utilisation rate at which the annual BYOL fee equals the cumulative PAYG hourly cost. Below the breakeven, PAYG is cheaper; above the breakeven, BYOL is cheaper. The breakeven is computed per workload class and per cloud provider. The cross reading with the provider specific economics sits in the RHEL on AWS marketplace economics note, the RHEL on Azure marketplace economics note, and the RHEL on GCP marketplace economics note.

The Cloud Access programme is the structural mechanism that makes BYOL possible on the public cloud. The buyer enrols specific RHEL subscriptions through the Red Hat customer portal, the cloud provider recognises the enrolment, and a host carrying a Cloud Access subscription is billed by the cloud provider at the OS less rate. Cloud Access is portable: the same subscription can be applied to AWS today and Azure tomorrow with the buyer's choice of where the subscription lives at any given time. The cross reading with the broader RHEL practice sits in the RHEL practice.

The breakeven calculation is the structural input to the BYOL versus PAYG decision and the first place the buyer's rationalisation should land.

The mechanics are arithmetic. The annual BYOL fee for a RHEL subscription at the appropriate tier is divided by the hourly PAYG surcharge for the equivalent host on the cloud provider. The result is the number of paid hours per year at which the two postures cost the same. Above that number of hours, BYOL is cheaper; below, PAYG is cheaper. The breakeven typically lands in the range of fifty to seventy percent of an always on year for standard tier workloads, with the exact figure depending on the provider, the host size, the support tier of the RHEL subscription, and the marketplace surcharge tier on the provider. The figure should be computed against the buyer's actual contracted RHEL price, not the published list price.2

The fleet segmentation is the operational discipline that turns the breakeven into a decision. The fleet is segmented by workload class and utilisation pattern: always on production hosts, business hours hosts, scheduled batch hosts, ephemeral development hosts, and burst capacity hosts. Each class carries a typical annual utilisation rate; each class is then read against the breakeven number. Always on production hosts sit above the breakeven and should default to BYOL; ephemeral development and burst hosts sit below the breakeven and should default to PAYG; the middle band requires individual reading. The cross reading on the ephemeral pattern sits in the RHEL spot and preemptible instance economics note.

The breakeven differs by cloud provider and the buyer's rationalisation should compute the figure per provider. The breakeven is not a single number; it is four numbers, one per provider, computed against the buyer's actual contracted prices. The differences arise from three structural features. The first is the marketplace surcharge tier, which differs by provider and by host size class. The second is the interaction with provider specific compute discounts; AWS Reserved Instances, Azure Reserved VM Instances, GCP sustained use and committed use discounts, and IBM Cloud Reserved Capacity all discount the compute base but not the RHEL surcharge. The third is the support tier match; the cloud marketplace PAYG tier typically maps to standard tier RHEL support, while a directly purchased BYOL subscription can be either standard or premium.3

The discipline is the per provider breakeven table maintained as part of the procurement register. The table is rebuilt at the renewal cycle against the actual contracted prices and the actual provider discount posture. The sibling treatment of the Reserved Instance interaction sits in the parallel notes on each provider's marketplace.

The cross cluster bridge sits in the OpenShift on AWS Azure GCP IBM Cloud note where the same BYOL versus PAYG decision applies to the OpenShift entitlement layered on top of RHEL on the same providers.

The audit reading on a mixed BYOL and PAYG fleet walks three artifacts. The cloud provider's inventory of hosts running RHEL, the marketplace billing record showing which hosts carry the PAYG surcharge, and the Cloud Access enrolment record on the Red Hat side. The reading is internally consistent when every host either carries a PAYG line on the cloud bill or is registered against an enrolled Cloud Access subscription, with no host carrying both and no host carrying neither.

The most common audit reading finding on a mixed fleet is the host carrying both lines. The pattern arises when a PAYG launched host is converted in place to BYOL via subscription manager attach without the marketplace plan being removed. The remediation is the per host posture audit at the renewal cycle. The pattern sits inside the broader treatment of recoverable over entitlement cost.4

The second finding is the host carrying neither line. The pattern arises when a host built from a custom image lacks both the marketplace plan and the Cloud Access enrolment. The reading is exposure for the period of operation. The discipline overlaps with the broader treatment in under entitlement audit exposure; the cross cluster bridge sits in financial services audit considerations where the audit pressure on cloud posture is the highest.

The renewal posture on the BYOL versus PAYG decision has three habits.

The first habit is the fleet segmentation. The cloud fleet is segmented by workload class and the segmentation is the input to the procurement register and the renewal cycle. The discipline sits inside the broader treatment in the 90 day subscription assessment.

The second habit is the per provider breakeven table. The table is rebuilt at the renewal cycle against the actual contracted prices and the actual provider discount posture. The sibling treatment of the actual provider mechanics sits in the RHEL on IBM Cloud marketplace economics note and the parallel notes on the other providers.

The third habit is the Cloud Access enrolment hygiene. Subscriptions intended for BYOL are enrolled in Cloud Access; subscriptions not intended for BYOL are not. The enrolment record is the audit ready artifact. The broader treatment of renewal cycle discipline sits in 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.