OpenShift self managed, dedicated, or ROSA.

OpenShift self managed, dedicated, and ROSA are not three editions of the same software. They are three commercial contracts that wrap a common upstream platform, each with its own unit of measure, its own operational responsibility split, and its own audit surface. The choice between them is a contract choice as much as an architecture choice, and the choice rarely gets the attention the unit of measure deserves.1

Self managed is the original consumption pattern. The buyer runs the cluster on its own infrastructure, on premises or in a cloud account it controls, and licenses OpenShift as a subscription against worker node cores. The buyer owns operations end to end: cluster lifecycle, upgrades, monitoring, incident response. Red Hat sells the subscription and the support entitlement; everything else is on the buyer's side of the line.

Dedicated is a managed OpenShift cluster operated by Red Hat on Red Hat's choice of cloud account, with the buyer paying for the cluster as a service. The unit of measure shifts from worker cores to a per cluster and per node fee, and the operational responsibility split shifts as well: Red Hat takes the platform layer and the buyer keeps the application layer. The Dedicated brand has narrowed in 2026 as Red Hat has pushed buyers toward the hyperscaler integrated offerings, but it remains the cleanest example of the managed pattern.2

ROSA, Red Hat OpenShift on AWS, is the hyperscaler integrated form of the managed pattern. The cluster runs in the buyer's AWS account and is billed jointly by Red Hat and AWS. The same shape exists on Azure as Azure Red Hat OpenShift and on IBM Cloud as Red Hat OpenShift on IBM Cloud. The unit of measure here is per worker node, with cluster level fees on top, and the billing is metered hourly through the cloud provider rather than annually through Red Hat. The split of responsibility sits closer to Dedicated than to self managed.

For the broader OpenShift licensing mechanics that govern how each of these models reads at the audit window, see the OpenShift practice hub. For the audit defense engagement that sits behind any inquiry on an OpenShift estate, see audit defense.

Self managed OpenShift is the model the audit team reads most often, because it carries the largest counting surface. The subscription is priced against pairs of physical cores on worker nodes. Master nodes (the control plane that runs the API server, scheduler, and etcd) are not directly counted under the self managed listing on properly tainted clusters; infrastructure nodes that carry only platform services such as routers, image registries, and monitoring are also outside the count where the taint configuration holds.3 The trap, as set out on the OpenShift practice hub, is that taints drift under autoscaling, and a master that begins to schedule customer workloads becomes a counted node.

Hyperthreading sits inside the core count question. Red Hat's published metric for self managed OpenShift defines a subscription core as either one physical core on bare metal or two vCPUs in a virtualized environment, with carve outs in the schedule that read cleanly on paper and unevenly in deployment. An estate that ships with hyperthreading enabled and was modelled against physical cores will be read by the audit team against vCPUs and arrive at roughly twice the buyer's number. The fix is to read the schedule version that the order form actually carries, then count against that version, not against the current published metric.

The OpenShift Plus bundle layers on top of self managed. Plus prices a bundle of OpenShift, OpenShift Data Foundation, Advanced Cluster Management, Advanced Cluster Security, and Quay against a single core count. The bundle entitles every included component to every core counted, which means the audit floor across the bundle is set by the largest component deployment. Self managed estates that adopted Plus to discount the core rate frequently carry a Plus floor that is well above the deployed footprint of the bundle's smaller components, and the surface that produces is contractual rather than architectural.

Self managed is the right choice when the buyer has the operations bench to carry the platform and wants the negotiation surface that comes with an annual subscription. It is the wrong choice when the operations bench is thin, because the platform incident sits on the buyer's side of the line.

The managed models trade core counting for a per cluster and per node fee, paid as long as the cluster exists. The accounting surface is smaller because there are fewer numbers to dispute. The negotiation surface is not necessarily smaller, but it moves elsewhere: from line item counting at the audit window to cluster sizing and term commitment at the contract window.

OpenShift Dedicated is priced against a cluster fee that covers the control plane, plus a per worker node fee that scales with the cluster. The cluster runs in a Red Hat managed cloud account, and the operational boundary sits at the platform layer. The buyer commits to a term and a cluster count; the spend is predictable in a way that self managed is not, and the audit surface is materially smaller because the count is a cluster register rather than a core register.4 Dedicated has become less common in 2026 as buyers moved toward the hyperscaler integrated forms.

ROSA on AWS, Azure Red Hat OpenShift, and Red Hat OpenShift on IBM Cloud are the dominant managed forms in 2026. The cluster runs in the buyer's cloud account, with the cloud provider operating the underlying infrastructure and Red Hat operating the platform. Billing is hourly through the cloud bill, with a per cluster fee and a per worker node fee combined in the line item. The buyer can commit to a term for a unit discount (Reserved on AWS, equivalent on Azure and IBM Cloud) or run pay as you go at a higher unit rate. The negotiation tends to consolidate inside the cloud commitment rather than running as a separate Red Hat contract.

The hyperscaler integrated forms have changed the buyer's posture at the audit window. The hourly bill is harder for Red Hat to dispute than an annual subscription, because consumption is metered by a third party and recorded continuously. The audit surface narrows to whether the workload that ran on the managed cluster was correctly placed there, and whether any self managed OpenShift remained on the same fleet under a different counting rule. Estates that run a mix of self managed and ROSA, which is most large estates in 2026, carry both surfaces.

The cost line on a managed cluster is rarely lower than on a tuned self managed cluster at the same workload. The premium pays for the operations bench, the platform incident coverage, and the smaller audit surface. Whether it is worth paying depends on what the buyer values: spend, operations, or audit posture.

Each of the three models breaks in a predictable place. The break is not always financial; sometimes it is operational and the financial consequence arrives a year later. Naming the break before signature is the work of the assessment and the negotiation, not the discovery.

Self managed breaks on counting drift. An estate that grows by ten percent a year in worker core terms will see its OpenShift line grow by more than ten percent at the next renewal, because the negotiated discount band reset when the volume crossed a tier and because the Plus bundle floor moved with the largest deployed component. Self managed estates that did not run a counting exercise between renewals routinely face quote movements they did not model. For the counting work that surfaces this drift, see subscription assessment and the related note on OpenShift core counting in mixed environments.

Dedicated breaks on cluster shape. Buyers who provisioned Dedicated clusters at a comfortable headroom for early adoption frequently never resize, and the per cluster fee accumulates on clusters that ran well below their capacity for a year or more. The recoverable excess on Dedicated estates lives in cluster count and cluster size, not in core count.

ROSA and the hyperscaler forms break on placement. A workload that drifted from a managed cluster to a self managed cluster (because a development team preferred the self managed operator catalog, or because a node selector was set incorrectly during a migration) will be counted by Red Hat against the self managed core register and not against the managed cluster fee. Estates that run both models without a placement policy face the worst of both surfaces. For the engagement that builds that placement policy as a buyer side artefact, see the advisory retainer.

The choice between self managed, dedicated, and ROSA is rarely a clean choice in 2026. Most enterprises of consequence carry at least two of the three: a self managed footprint that predates the managed offerings, a ROSA or ARO footprint that grew under the cloud migration of the last two years, and sometimes a Dedicated footprint that sits between the two. The right question is not which model to pick. The right question is which model carries which workload, and whether the placement holds at renewal.

Self managed makes sense where the workload is steady, the operations bench is real, the data residency requirements rule out the managed forms, or the estate has scaled past the point at which the managed premium pays for itself. It is also the model where the buyer keeps the most negotiation surface, because the counted line is large and visible and the discount band moves with commit volume.

Dedicated and the hyperscaler integrated forms make sense where the operations bench is thin, the workload runs in a cloud account already, the audit posture matters more than the line item, or the buyer wants the platform incident off its desk. Managed forms also tend to land cleaner inside an existing cloud commitment.

The discipline is to place each workload against the model that fits it, write the placement down, and read the placement against actual telemetry at the next renewal. Workloads drift. Placement policies decay. The audit team reads the drift before the buyer does. For the broader engagement that builds the placement policy and reads it against deployment, see subscription assessment; for the negotiation that turns the placement into a quote, see renewal negotiation; for the inquiry that lands when placement and entitlement diverge, see audit defense. To start a buyer side reading of the current OpenShift posture, write the desk via the contact page.5

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.