Microsoft announced public preview of hosted control planes for Azure Red Hat OpenShift on September 15, 2026. It is a new deployment option alongside the standard architecture, which remains supported and actively developed. Read the announcement.
For platform teams, the interesting question is how this changes the operating model for a fleet of clusters. My recommendation is to evaluate it with one representative non-production application and a written list of requirements, rather than treating a successful cluster deployment as the whole assessment.
What Moves, and What Stays With You
The hosted architecture separates the control plane from the worker nodes. Microsoft and Red Hat manage the control plane centrally on shared management infrastructure; application workers remain in your Azure subscription. The implementation builds on HyperShift while preserving the OpenShift application experience. Microsoft Learn: deployment architectures.
That distinction belongs in your architecture diagrams and support runbooks. Label where administrators connect, where application traffic enters, and which team owns each dependency. A managed component can still be part of an application's failure path, even when its virtual machines are no longer visible in your subscription.
I would make the pilot's first deliverable a short ownership map. Include identity, network changes, application releases, persistent data, monitoring, and incident escalation. This is more useful than simply replacing one cluster icon with another.
A Smaller Starting Point Is Not an Availability Design
Microsoft's comparison lists a minimum of two worker nodes for hosted control planes, versus three control-plane nodes and three workers for standard clusters. Hosted node pools occupy a single availability zone each; separate pools can be placed across zones. Platform components such as ingress, the image registry, and monitoring run on workers. Architecture and footprint comparison.
My practical recommendation is to size the application after accounting for those platform workloads. Reserve enough capacity to sustain the failure and maintenance scenarios you intend to support. Two nodes may be sufficient to create an environment, but creation requirements do not establish your application's resilience target.
For a pilot, record the resources consumed before deploying your application, then repeat the measurement under representative load. Keep that baseline with your proposed worker sizing and zone layout.
Read the Quickstart Defaults Before Deploying
The hosted-cluster quickstart offers Azure CLI and Bicep paths. Its default configuration makes both the API server and application ingress public, and uses platform-managed keys for etcd encryption. The guide points to a customizable deployment path for options such as private visibility and a private Key Vault. Quickstart configuration and prerequisites.
Do not assume that a hosted control plane means a private API endpoint. For a security-conscious evaluation, decide the intended access model before selecting a template. Have the network owner review the route from an administrator workstation and the separate route used by application clients.
The preview API also requires a dedicated VNet integration subnet for private connectivity between the hosted control plane and cluster nodes. That subnet cannot be shared with the worker or node-pool subnets. Hosted-cluster platform settings.
My recommendation is to put the subnet allocation, address-space checks, and ownership into infrastructure review. Avoid discovering a network design conflict only after the application team has built its deployment around the pilot.
Separate Upgrade Flexibility From Application Readiness
The comparison documentation allows the hosted control plane and individual node pools to be upgraded separately; control-plane patch updates are managed automatically by Red Hat SREs. Upgrade model comparison.
Use that separation to make your test evidence more specific. Identify which operators, admission controls, storage dependencies, and application components must be checked when a worker pool changes. Record the actual control-plane and worker versions with every result.
I would also rehearse an ordinary application rollback during the pilot. Infrastructure upgrade flexibility does not tell you whether yesterday's application image still understands today's database schema. Keep the application recovery plan separate from the platform maintenance plan.
Keep the Preview Decision Honest
The announcement describes preliminary pricing that can change before general availability. It also explicitly attributes the listed compliance certifications to the standard architecture. Do not treat that list as certification evidence for this preview. Announcement scope and pricing caveat.
My recommendation is to retain a dated service-scope review with the pilot: selected region, supported versions, required controls, current commercial terms, and unresolved questions. A promising technical result should not quietly become a production commitment while those questions remain open.
Practical Cloud Engineer Takeaway
My proposed acceptance checklist is:
Confirm the intended API and ingress exposure from approved and unapproved network paths.
Verify application identity and access to its Azure dependencies with least-privilege permissions.
Capture worker capacity before and during representative application load.
Exercise application rollout, rollback, and a controlled worker-maintenance scenario.
Check that an application failure produces an actionable alert with a named owner.
Preserve deployment configuration and document how the disposable pilot will be cleaned up.
These are recommended checks, not results from a deployment I have performed.
Who Should Care?
OpenShift platform owners, Azure landing-zone teams, Kubernetes engineers, and organizations evaluating a repeatable model for multiple application environments.
Bottom Line
Hosted control planes are worth a focused evaluation. Judge the result by operational clarity, application behavior, and a defensible deployment configuration—not merely by how quickly the cluster becomes available.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments