I am pleased to share that Microsoft has been named a Leader in the 2026 Gartner® Magic Quadrant™ for Container Management, positioned furthest to the right on Completeness of Vision. We believe this recognition reflects our ability to help customers modernize existing applications and embrace AI workloads without adding operational complexity.

Furthermore, this recognition comes at a moment when container platforms are being asked to support a far broader range of workloads, operating models, and deployment environments than many organizations ever anticipated.

When we started working on Kubernetes over a decade ago, the problem was narrow: democratize distributed systems so that reliable services were easier to build. We were careful to describe workloads in terms of what they needed instead of where they should go, mostly because we wanted the scheduler to have room to make good decisions. That turned out to matter more than we expected, because it meant the system never had strong opinions about what the workloads actually were.

AI has reshaped the requirements for container management. While Kubernetes has proved well suited for AI workloads, the bigger shift is that applications and AI now need to run closer to data and users, and increasingly inside specific sovereign and regulatory boundaries. Organizations now need more than container orchestration; they need a platform that provides a consistent operating model across cloud, edge, and hybrid deployments while adapting to new requirements without needing applications to be rebuilt. This vision underpins Microsoft’s container portfolio, spanning Azure Kubernetes Service (AKS), Azure Container Apps, Azure Arc, and Azure Kubernetes Fleet Manager..

Run AI on the platform you already operate

Across customer deployments, we’ve seen it settle into two distinct architectural models. In the first, a platform team owns a persistent serving layer, GPU scheduling, model lifecycle, and the compliance boundary around the system. Once volume is high and predictable, organizations increasingly want AI infrastructure to behave like any other platform capability: application teams consume it, while platform teams retain control over how it is operated and governed. On AKS, open-source tooling such as the AI toolchain operator helps automate model deployment and GPU provisioning, while AKS holding CNCF AI Conformance certification gives customers confidence that the ecosystem around their applications remains compatible as it evolves.

In the second model, an application or agent invokes inference when needed, runs generated code, and releases capacity when the work finishes. This model places a premium on elasticity and isolation. Capacity needs to appear quickly, be removed when it’s no longer needed, and safely contain workloads whose behavior isn’t always predictable in advance. Azure Container Apps is designed around that operating model, with serverless GPUs for on-demand inference, and hardware-isolated sandboxes for agent hosting that preserve state between interactions.

Almost every enterprise we work with needs both, and I’d argue the interesting engineering problem is making the boundary between them easy to cross: the same image, the same identity and network controls, the same policy, whichever side a team lands on. Platform teams want the control the first model gives them for the models the business depends on. Application teams and agent frameworks want the second, and they often want it without learning Kubernetes.

Keep one operating model as the estate spreads out

Once inference follows the data, the estate stops being centralized. Clusters accumulate across regions, in datacenters, at sites, and in environments where connectivity is intermittent or prohibited outright, often because sovereignty rules require the workload and its data to stay inside a jurisdiction. The resulting failures are usually coordination failures rather than single-cluster failures: configuration drift between locations, upgrades landing unevenly, and policy being applied in one environment but not another. Hybrid strategies can often fail when teams treat coordination problems as isolated cluster issues instead of platform problems.

We know that AI needs to spread from cloud to edge. To address that, we’ve built AKS Everywhere to enable a consistent, Azure-built and secured Kubernetes platform from cloud to edge. Going even broader, with Azure Arc for Kubernetes we extend a common identity, policy, and observability model across CNCF-conformant Kubernetes environments, including clusters in other clouds. With many clusters comes cluster sprawl, and Azure Kubernetes Fleet Manager addresses the coordination problem that emerges as estates grow, helping organizations manage upgrades, workload placement, and policy consistently across fleets.

Holding all of that together depends on AKS staying close to upstream Kubernetes, and we’ve kept it there deliberately. There’s no proprietary fork, and open-source is at the core of our strategy. Microsoft is the second-largest contributor to CNCF projects overall and the largest among cloud providers for the past three years. That work is what keeps the API you build against stable no matter where the workload lands, and why the ecosystem around your cluster looks the same inside Azure and outside it.

Hold operations steady as the estate grows

Cluster counts often grow faster than operations teams do, and most organizations feel that pain before they have a plan for it.

Some of the answer is better defaults. AKS Automatic applies operational practices derived from Microsoft’s experience running Kubernetes at scale, while preserving the flexibility of the Kubernetes API.

The larger shift, however, is agentic operations. I expect this area to change more than any other over the next few years. Azure SRE Agent and the AKS MCP Server help operators move from alert to diagnosis to remediation using the same permissions and controls they already use today. The goal isn’t to replace operators; it’s to reduce the amount of routine investigation that still consumes too much operational time.

A platform built to absorb new requirements has more surface area than one built for a single scenario, and that demands more judgment from the people running it. Our job is to keep pulling that complexity into the platform, and the work is not finished.

Customer momentum

These examples highlight how customers are applying Azure’s container portfolio across AI, business-critical applications, and hybrid environments.

• Wayve trains its autonomous driving models on petabytes of video and sensor data, using AKS to pull thousands of GPUs into what amounts to a single elastic training system.
• AT&T built Ask AT&T with AKS as the orchestration core for its containerized agents, and every agent clears legal, security, and finance review before it reaches production.
• Replit‘s agent takes a plain-language description, writes the application, and deploys it as a Container App inside the customer’s own Azure environment, where it picks up that customer’s network and compliance controls from the first deployment onward. Roughly three-quarters of their enterprise users don’t write code for a living.
• SimCorp moved the investment management platform behind many of the world’s largest asset managers from virtual machines onto AKS, driven by the need for identity, logging, and security policy to apply identically for every client in every jurisdiction, and to be auditable when someone asks.
• Emirates Global Aluminium runs about two-thirds of its estate in Azure and a third on-premises at its own sites, with image and video analytics running next to the plant floor and applications moving between the two without being re-engineered.

A training cluster spanning thousands of GPUs has very little in common with a regulated multi-tenant SaaS platform or with analytics running beside a smelter. What connects them is that each one eventually needed something its original architecture wasn’t built for.

Azure Kubernetes Service gives us the control and cost efficiency we need. We can scale GPU resources based on call volume and test new models without touching production.

Brian Sutliffe, Vice President of Engineering, CallRevu

Being named a Leader in this Magic Quadrant is an honor for us, and it solidifies clear expectations for our work ahead. At the end of the day, only the team running a workload can decide where it belongs, and the answer will vary across an estate. The platform’s role is to let that answer change without forcing the team to redesign the application or adopt a second operating model. I also want to personally thank all of Azure Cloud Native since this recognition reflects a lot of hard work by many people throughout Microsoft and Azure.

You can read a complimentary copy of the 2026 Gartner® Magic Quadrant™ for Container Management here.

---

Gartner ® Magic Quadrant™ for Container Management, Dennis Smith, Tony Iams, Wataru Katsurashima, Lucas Albuquerque, 2 September 2026

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.

Gartner and Magic Quadrant are trademarks of Gartner, Inc., and/or its affiliates.

This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request here.