ROSA self managed and hosted, priced honestly.
ROSA self managed versus hosted control plane cost is the procurement question every OpenShift on AWS buyer should price honestly at signature. ROSA classic charges the buyer for the three control plane nodes and the two infrastructure nodes as standard OpenShift cores; ROSA with hosted control planes removes the control plane from the buyer's bill of materials and prices a fixed hourly fee per cluster instead. The breakeven runs through cluster count and worker pool size. Many small clusters favour hosted; a handful of large clusters favour classic. The buyer side discipline is to price both paths against the actual estate before the AWS marketplace agreement is signed.
The two ROSA paths, read for what the buyer actually pays.
ROSA self managed versus hosted control plane cost begins with the bill of materials each path issues to the buyer. ROSA classic, the original architecture, deploys an OpenShift cluster the way OpenShift on bare metal or VMware deploys: three control plane nodes running the API server, scheduler, controller manager, and etcd, alongside two or more infrastructure nodes running the registry, ingress, monitoring, and the cluster operators. The buyer pays for AWS EC2 capacity on all five of those nodes, and Red Hat charges OpenShift core entitlements against the control plane and infrastructure cores in the same way it charges them against worker cores. The cluster is an EKS sized footprint with five extra nodes that exist only to keep the control plane and the cluster services running1.
ROSA with hosted control planes, introduced in 2023 and generally available across 2024 and 2025, moves the three control plane nodes out of the buyer's AWS account and into a Red Hat managed AWS account. The buyer's cluster has zero control plane nodes and zero dedicated infrastructure nodes on the EC2 bill; the API server, etcd, and the control plane operators run as pods inside Red Hat's hosting account. The buyer pays a fixed hourly fee per cluster for the hosted control plane plus OpenShift core entitlements against the worker pool. The EC2 bill drops by five nodes per cluster; the OpenShift entitlement count drops by the control plane and infrastructure cores; the hosted control plane fee replaces them as a single line on the AWS marketplace invoice2.
The architectural distinction matters at the procurement table because the two paths invoice differently. ROSA classic invoices through the AWS marketplace as OpenShift hours metered against every core in the cluster. ROSA with hosted control planes invoices as a fixed cluster fee plus worker cores. The procurement function should know which line is which before the renewal arrives.
The breakeven line, read against cluster count and worker pool size.
The breakeven between ROSA classic and ROSA with hosted control planes runs through two variables: how many clusters the buyer operates, and how large each cluster's worker pool is. The hosted control plane fee is a fixed per cluster line, so a buyer with many small clusters multiplies that fee against the cluster count. The classic path absorbs the control plane overhead into the worker pool entitlement, so a buyer with a single large cluster amortises the five extra nodes across a large worker pool and the per worker overhead is small.
For a buyer with twenty small clusters of four worker cores each, the hosted control plane fee is paid twenty times and the worker pool entitlement is paid against eighty cores. The classic path on the same estate is paid against eighty worker cores plus one hundred control and infrastructure cores across the twenty clusters, for a total of one hundred eighty cores subscribed. The classic path looks cheaper if the control plane fee is high enough; the hosted path looks cheaper if the control plane fee is moderate against the avoided cores and the avoided EC2 bill. The procurement function should price both paths against the real cluster topology, not against a stylised one, before signature, because the marketplace agreement constrains the path for the term.
For a buyer with two large clusters of two hundred worker cores each, the classic path pays for four hundred worker cores plus ten control and infrastructure cores across the two clusters, for a total of four hundred ten cores. The hosted path pays for four hundred worker cores plus two hosted control plane fees. The hosted control plane fee against ten avoided cores is rarely cheaper at this scale; the classic path commonly wins. The amortisation of the control plane overhead across a large worker pool is the structural reason classic remains the right path for the small number of large clusters case3.
| Estate shape | Cheaper path | Operational note |
|---|---|---|
| Many small clusters (10+ of <16 cores) | Hosted | Control plane overhead dominates |
| Moderate count (4 to 8 clusters) | Near breakeven | Price both |
| Few large clusters (1 to 3 of 100+ cores) | Classic | Worker pool amortises overhead |
| Development and ephemeral clusters | Hosted | Faster provisioning |
| Regulated workloads with control plane residency requirement | Classic | Control plane in buyer's account |
The control plane fee, read against what it actually buys.
The hosted control plane fee is not only a financial charge. It buys an operational posture: Red Hat operates the control plane, patches it, upgrades it, and is on call for it under the ROSA support agreement. The buyer that paid for three control plane nodes in the classic path also paid the operational tax of patching them, upgrading them, and being on call for them, even though the ROSA managed service covered the cluster operators end to end. The hosted path retires that operational tax against the fixed fee, and the procurement function should price the operational delta into the comparison rather than reading the fee as pure margin4.
The fee also changes the upgrade cadence. On classic, the control plane and the worker pool upgrade together under a coordinated maintenance window the buyer schedules with Red Hat. On hosted control planes, the control plane upgrade is decoupled from the worker pool upgrade; Red Hat lifts the control plane minor version and the buyer schedules the worker pool upgrade independently. The decoupled cadence reduces the buyer's maintenance window count and is one of the structural reasons hosted control planes favour estates with many clusters that would otherwise require many coordinated windows.
The trade is control plane residency. On classic, the three control plane nodes and the etcd state live in the buyer's AWS account, the buyer's VPC, the buyer's subnet. On hosted, the control plane and the etcd state live in Red Hat's managed AWS account. For regulated workloads where the control plane and the cluster state must remain inside the buyer's network and audit boundary, classic is the structurally correct path even if hosted is the cheaper one. The procurement function should read the data residency policy before pricing the path.
The AWS marketplace agreement, read for the contract term.
ROSA invoices through the AWS marketplace, and the procurement function should read the marketplace private offer rather than the public hourly rate at any meaningful scale. The private offer prices ROSA on a committed term against either the classic line, the hosted control plane line, or both lines together. A buyer that signs a one or three year commitment receives a concession against the public hourly rate; the size of the concession is set at the negotiation table and varies with commitment volume and commitment depth. The procurement function should price the private offer against the estate's worker pool and cluster count rather than the headline hourly rate5.
The marketplace path also affects the buyer's AWS spend commitment. ROSA consumption counts against the AWS Enterprise Discount Program commitment if the buyer is on EDP; the AWS account team frequently positions ROSA as a way to drive EDP commitment, which is true on the AWS line and not necessarily true on the Red Hat economics. The procurement function should price the Red Hat side of the path independently of the AWS commitment incentive and treat the EDP draw down as a separate negotiation lane.
For the broader cross product reading, see the OpenShift practice hub, the renewal negotiation service hub for the marketplace negotiation discipline, the self managed versus dedicated versus ROSA decision read for the broader deployment choice, the OpenShift AI on ROSA pricing read for the AI workload economics on this same managed service, and the Application Foundations bundle economics read for the middleware layer that sits on top of either path. For the AWS marketplace economics on the underlying RHEL nodes, see the RHEL on AWS marketplace economics read. For the engagement protocol, see contact.
The procurement read at signature, and across the term.
The buyer side discipline at the procurement table is to price both ROSA paths against the actual estate at signature, name the cluster count and the average worker pool size, name the development and ephemeral cluster count, name the regulated workload residency requirement, and choose the path that prices cleanly against the estate's expected shape across the contract term rather than its day one shape. A buyer that signs ROSA classic at day one and then expands the cluster count over the term commonly pays the control plane overhead on every new cluster and arrives at the next renewal having paid more than the hosted path would have priced.
The mid term posture is to model both paths on a quarterly cadence against the current cluster topology, recognise when the estate crosses the breakeven line, and bring the path conversation to the next renewal cycle with the model in hand. ROSA private offers can include flexibility clauses that allow consumption against either line within the committed envelope; the procurement function should ask for that flexibility at the negotiation table.
ROSA self managed versus hosted control plane cost is a question with a real answer at any specific estate shape. The hosted path retires the control plane and infrastructure overhead, decouples the upgrade cadence, and prices cleanly at high cluster counts; the classic path amortises the overhead at large worker pools and keeps the control plane in the buyer's account for residency sensitive workloads. The buyer who prices both paths against the real estate at signature pays the cheaper line; the buyer who reads only the AWS account team's preferred path at signature commonly pays the dearer one.
Notes & references
- 1. Red Hat OpenShift Service on AWS documentation and architecture notes accessed across 2025 and 2026. ROSA classic deploys three control plane nodes and at least two infrastructure nodes in the buyer's AWS account, all counted against OpenShift core entitlements.
- 2. Red Hat OpenShift Service on AWS with hosted control planes documentation and AWS marketplace listings. The hosted control plane runs in a Red Hat managed AWS account and is invoiced as a fixed per cluster hourly fee in addition to worker core entitlements.
- 3. Practice observation: the breakeven between classic and hosted favours classic at low cluster count with large worker pools because the control plane overhead amortises across many worker cores; the breakeven favours hosted at high cluster count with small worker pools.
- 4. Red Hat ROSA support and operational responsibility documentation: the managed service covers the control plane operations on both paths, but the hosted path removes the control plane from the buyer's account entirely and decouples the upgrade cadence between control plane and worker pool.
- 5. AWS marketplace private offer mechanics: ROSA private offers price the classic line, the hosted control plane line, or both against a committed term, with concessions against the public hourly rate set at the negotiation table.
- 6. Concession bands and trailing twelve month figures refer to the practice observation across signed contracts. The eighty two percent audit exposure reduction in marginalia is the trailing twelve month average across defenses settled.
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.