RHEL on GCP, read against the Compute Engine hour.

RHEL on GCP marketplace economics describes the cost and entitlement reading on the Compute Engine VMs of a buyer running RHEL inside a Google Cloud estate. Google sells RHEL as a premium image on Compute Engine; the VM running a RHEL premium image is billed at the underlying Compute Engine rate plus an hourly RHEL surcharge that flows back to Red Hat through the Google partner relationship. This is the pay as you go posture, abbreviated PAYG, and it is the default for a Compute Engine VM launched from a Google published RHEL premium image. RHEL premium images include the standard RHEL line and, separately, the RHEL with Update Services for SAP Solutions image where the SAP support tier is the read.1

The second posture is the bring your own subscription posture, where the buyer attaches an existing RHEL subscription to a Compute Engine VM through the Red Hat Cloud Access programme. The Cloud Access enrolment permits a directly purchased subscription to be portable to GCP; the Compute Engine VM is then billed at the rate without the RHEL surcharge. The two postures behave differently on cost and on the audit reading. The cross reading with the equivalent postures on AWS and Azure sits in the RHEL on AWS marketplace economics note and the RHEL on Azure marketplace economics note.

GCP carries a structural feature that distinguishes its reading from AWS and Azure: the sustained use discount. Compute Engine applies an automatic discount on the compute base of a VM that runs for a significant portion of the month. The discount applies to the compute hour but not to the RHEL surcharge; the surcharge is flat across utilisation tiers. The discount changes the breakeven calculation between PAYG and BYOS in ways that differ from the cloud variant on the other providers. The cross reading with the broader RHEL practice sits in the RHEL practice.

Three counting traps recur on RHEL on GCP readings. Each is structural; each remediates inside the next renewal cycle.

The first trap is the project level visibility gap. A large GCP estate operates across dozens of projects, each potentially in a different organisation node, each running Compute Engine VMs with their own image selections. The procurement register that reads against the billing account aggregate misses the per project distribution. The reading depends on which posture each project is running; the remediation is the project level inventory pass, performed against the GCP billing export at the per project resolution. 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 Compute Engine VMs some of which are PAYG premium images and some of which are BYOS via Cloud Access; the procurement register carries the Cloud Access subscriptions; the GCP bill carries the PAYG surcharges; the buyer is paying both lines for some portion of the fleet. The reading is overpayment on the overlap; the remediation is the project level inventory and the elimination of the duplicated lines at the next renewal. The pattern sits inside the broader treatment of recoverable over entitlement cost.

The third trap is the sustained use discount mismodel. A buyer modelled the all in cost of a Compute Engine VM running RHEL by applying the sustained use discount to the full hourly cost including the RHEL surcharge. The model overshoots the actual savings because the discount applies only to the compute base. The remediation is the breakeven model rebuild at the renewal cycle, performed against the actual billing line items rather than against the published rate card. The cross reading with the underlying breakeven calculation sits in the bring your own versus pay as you go breakeven note.

The GCP project is the cloud equivalent of the AWS account and the Azure subscription scope: the resolution at which the procurement register must read. A buyer running Compute Engine VMs across forty projects is running RHEL in forty separate operational contexts, each with its own image selection, its own billing line items, and its own potential for posture drift. The renewal posture that reads against the GCP billing account aggregate, the GCP organisation, or any single project is reading against a slice.3

The discipline is the project level export of the Compute Engine inventory and the RHEL line items, performed at the cadence of the renewal cycle. The cross reading on the multi region pattern sits in multi region Red Hat agreements where the same discipline applies to cross border estates.

The cross cluster bridge sits in the Red Hat Advanced Cluster Security pricing note where the project boundary discipline applies in parallel for OpenShift clusters running on GKE on GCP; the two readings frequently coincide on the same buyer's estate.

The audit reading on RHEL on GCP walks three artifacts. The Compute Engine inventory of VMs running RHEL across the GCP projects, the GCP billing export of marketplace RHEL 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 GCP bill or is registered against an enrolled Cloud Access subscription.

Three inconsistencies recur. The first is the project the procurement register has never seen. The GCP project boundary is the audit resolution; the billing account aggregate is not. The remediation is the project level inventory at the renewal cycle. The second is the custom image source. A Compute Engine VM may have been deployed from a Google published premium image, from a custom image built by the buyer, or from a snapshot. The licensing posture depends on the source; a custom image without a marketplace plan attached requires the BYOS posture. The third is the in place conversion: a VM launched from a premium image, converted via subscription manager attach to a Cloud Access subscription, with both lines still attached. The remediation overlaps with the broader treatment in aligning subscription to deployment.4

The discipline interacts with the broader audit defense framework in audit defense; the GCP billing export is the audit ready artifact and the buyer's narrative about project use is not.

The renewal posture on RHEL on GCP has three habits.

The first habit is the project level read. The renewal input is the inventory of Compute Engine VMs running RHEL across every GCP project, classified by posture and image source. The discipline sits inside the broader treatment in the 90 day subscription assessment.

The second habit is the breakeven rebuild. The PAYG versus BYOS decision is utilisation driven and on GCP the sustained use discount changes the breakeven point relative to AWS or Azure. The model is rebuilt at the renewal cycle against the actual billing data. The sibling treatment of the breakeven calculation sits in the bring your own versus pay as you go breakeven.

The third habit is the cross provider read. A buyer running RHEL on GCP frequently also runs RHEL on AWS, Azure, or IBM Cloud; the renewal posture is rationalised across the providers. The cross reading sits in the RHEL on IBM Cloud marketplace economics note. 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.