There are three sensible ways to run Kubernetes on Azure: AKS, ARO, and a cluster you manage yourself. Teams often pick by familiarity or by whichever a vendor pushed hardest. The better way is to match the option to your operational reality. Here’s how we frame the decision.
Azure Kubernetes Service gives you a Microsoft-managed control plane. It’s the fastest to deploy and the cheapest of the three. You don’t pay for or operate the control plane, you bring your own tooling for the things OpenShift bundles, and you get a clean, current Kubernetes that tracks upstream closely.
The trade-off is that AKS is Kubernetes and not much more. The enterprise features that OpenShift ships out of the box, the integrated registry, build pipelines, developer console, opinionated operators, you assemble yourself from the ecosystem. For a capable platform-engineering team that wants to choose its own components, that’s a feature. AKS is the right default for greenfield teams who can build their own platform layer on top.
Azure Red Hat OpenShift is OpenShift delivered as a managed service, jointly supported by Microsoft and Red Hat. You get the full enterprise feature set on day one: operators, image streams, an internal registry, integrated builds, a polished developer console, and OpenShift’s hardened defaults and compliance documentation.
It costs more than AKS, both in licensing and in the heavier infrastructure footprint, in the region of twice AKS for equivalent capacity. What you buy for that is operational maturity and a single dual-vendor support relationship. When something breaks, Microsoft and Red Hat own the resolution jointly rather than pointing at each other. For regulated enterprises that need the compliance artefacts and the named support contract, ARO earns its premium. It’s the right pick when the organisation values supportability and a hardened baseline over raw cost.
ARO also changes how your developers work, for better and worse. The platform is opinionated. The built-in registry, the source-to-image builds, the project model, and the operator catalogue give application teams a paved path that AKS leaves you to build. Teams that embrace the OpenShift way move fast on it. Teams that want to assemble their own stack find the opinions get in the way. Know which kind of team you have before you commit.
kubeadm, kops, or Cluster API on your own VMs gives you maximum control and maximum operational burden. You own the control plane, etcd, upgrades, certificate rotation, and every failure mode that the managed options handle for you.
This is justifiable only for specific requirements that the managed services can’t meet: a custom CNI the managed offerings don’t support, kernel-level patches or tuning, or an air-gapped deployment with no path to a managed control plane. Absent a concrete requirement like that, self-managing is choosing to operate undifferentiated heavy lifting that Azure will do for you. Most teams who think they need it don’t.
The hidden cost is the long tail of operational work the managed plane absorbs. Control-plane upgrades on a cadence. etcd backups and the practice runs to prove a restore works. Certificate rotation before things expire. Patching the nodes and the kubelet. None of it ships features. All of it pages someone when it goes wrong. Before choosing self-managed, price that work honestly against an engineer’s time, because it rarely comes out cheaper than the managed control plane it replaces.
Walk these questions in order.
Team capability. Do you have an SRE team that can run a control plane through upgrades, etcd incidents, and certificate expiries at 3am? If not, the managed options aren’t a preference, they’re a requirement. Self-managing without that capability is how clusters die.
Regulated workload requirements. Do you need OpenShift’s compliance documentation and hardened defaults to satisfy an auditor? If the regulator wants to see the artefacts ARO ships with, that pushes you toward ARO and away from assembling equivalents on AKS yourself.
Enterprise support obligations. Does a Red Hat support contract and joint accountability matter to your risk posture? For some enterprises, having a named vendor on the hook is a procurement and governance requirement, not a nicety. That favours ARO.
Budget. ARO runs roughly twice AKS for comparable capacity. If the budget is tight and you have the team to build your own platform layer, AKS delivers the same Kubernetes for less. If the budget can carry the premium and you value the bundled maturity, ARO is defensible.
Multi-cluster needs. Running many clusters across teams or regions rewards strong automation and consistent tooling. Both AKS and ARO support this well; the choice between them still comes down to the criteria above rather than cluster count.
A Lagos fintech with a four-person platform team, a regulator that wants to see hardened configuration and audit artefacts, and a budget that can carry the cost. ARO. The compliance documentation maps to what the auditor asks for, the dual-vendor support satisfies the governance requirement, and the team is small enough that the bundled platform layer saves them more than the licence costs. Building the OpenShift feature set themselves on AKS would consume the team they don’t have to spare.
A product company with a strong eight-person SRE function, no regulatory pressure beyond the ordinary, and a need to keep infrastructure spend lean. AKS. They have the capability to compose their own platform, they don’t need OpenShift’s bundled features or its support contract, and the cost difference is real money they’d rather spend elsewhere. Neither team should self-manage. Neither has a requirement that forces it.
Most clients should pick AKS or ARO. AKS when you have a platform team that wants to compose its own stack and keep costs down. ARO when you’re a regulated enterprise that values the bundled feature set, the compliance documentation, and the dual-vendor support, and the budget supports it.
We’ve built and run all three. Self-managing has a place, but it’s a narrow one, and we’ll talk you out of it unless you have a real requirement that forces it. The operational burden is rarely worth it when Azure will manage the control plane for you.
If you’re weighing these options for a specific workload, our DevOps team has shipped on each and can tell you which fits your team and your compliance needs. Book a consultation and we’ll work through the criteria against your actual situation rather than a generic recommendation.