Azure Kubernetes Service

About Azure Kubernetes Service

Azure Kubernetes Service (AKS) is Microsoft's managed Kubernetes service in Azure. It is designed for teams that want to run containerized applications on Kubernetes without operating every part of the control plane themselves. AKS supports two operating approaches: AKS Automatic, which applies more managed production defaults, and AKS Standard, which gives platform teams deeper control over node pools, networking, scaling, upgrades, and cluster configuration. The right choice depends on how much infrastructure control a team needs and how much Kubernetes operational work it wants Azure to handle.

What is Azure Kubernetes Service used for?

AKS is used to deploy and operate applications packaged in containers when a team needs Kubernetes features such as pod scheduling, rolling deployments, service discovery, autoscaling, namespaces, and workload isolation. Typical use cases include microservices, APIs, internal platforms, event-driven services, batch workloads, and applications that need to scale across multiple worker nodes.

Microsoft manages the AKS control plane, while customer workloads run on worker nodes. This reduces some of the operational burden compared with installing and maintaining Kubernetes completely on your own infrastructure. It does not remove application operations, capacity planning, security ownership, networking decisions, or cost management. Teams still need to understand Kubernetes concepts and the Azure resources attached to the cluster.

AKS Automatic vs AKS Standard: which should you choose?

Microsoft currently recommends AKS Automatic as the production-ready default for many teams and new workloads. Automatic mode preconfigures operational areas such as node provisioning, scaling, security guardrails, monitoring, and upgrades. It is aimed at teams that want Kubernetes without spending as much time designing and maintaining the underlying cluster platform.

AKS Standard is the better fit when a platform team needs deeper infrastructure control. Microsoft positions Standard for scenarios that require custom networking, Windows node pools, particular VM choices, specialized upgrade behavior, or existing automation around node pools and cluster operations. The tradeoff is more responsibility. Standard can be more flexible, but the team must make more architecture and lifecycle decisions itself.

How do scaling and node pools work in AKS?

AKS runs application pods on worker nodes that are organized into node pools. In Standard mode, teams can design node pools for different workload requirements and configure scaling behavior. Microsoft documents the cluster autoscaler for increasing or decreasing the number of nodes when pods cannot be scheduled or when nodes become underused. Kubernetes workload scaling can also use mechanisms such as the Horizontal Pod Autoscaler, while Microsoft documents KEDA and vertical scaling options in supported AKS scenarios.

Scaling is not automatically a cost optimization strategy. More nodes increase compute cost, and poorly configured requests, limits, autoscaling thresholds, or pod placement can leave capacity underused. Teams should monitor application demand, node utilization, scheduling failures, and the effect of scaling rules instead of assuming autoscaling will always choose the cheapest outcome.

How does AKS pricing work?

AKS does not have one simple all-inclusive price. Microsoft separates cluster management pricing from the Azure infrastructure and services consumed by the cluster. The current AKS management tiers are Free, Standard, and Premium. Free provides free cluster management for development, testing, learning, and other non-production scenarios, while customers still pay for the Azure resources they consume.

Standard is designed for production and enterprise workloads and includes financially backed uptime SLA coverage. Premium adds longer Kubernetes version support through Long Term Support. AKS Automatic uses the Standard cluster management tier by default. Beyond the management tier, buyers should budget for worker-node virtual machines, disks, load balancers, public IPs, outbound data, monitoring, container registries, security services, backups, and any other Azure services used by the application. Pricing was checked against Microsoft documentation on August 25, 2026.

What reliability and availability options does AKS provide?

Microsoft's current Standard and Premium pricing tiers include an uptime SLA for the Kubernetes API server. Microsoft states 99.95 percent availability for clusters using Availability Zones and 99.9 percent for clusters that do not use Availability Zones. The Free tier is best effort and does not include a financially backed uptime SLA.

AKS Automatic also includes pod readiness SLA coverage for qualifying workloads. These service commitments do not make an application highly available by themselves. Application replicas, node placement, zone design, storage choices, ingress, database architecture, dependency resilience, backup, and disaster recovery still need to be designed for the required business outcome.

What should teams plan before adopting AKS?

AKS is most successful when teams treat Kubernetes as a platform rather than only as a deployment target. Before adoption, organizations should decide how clusters will be created, who owns platform operations, how identity and secrets are handled, which network model is appropriate, how images are built and stored, how workloads are monitored, and how upgrades are tested.

Version lifecycle also matters. Kubernetes and node operating systems have support windows, and Microsoft publishes AKS version and image retirement information. For example, Microsoft states that Azure Linux 2.0 is no longer supported for AKS and that affected node pools need to move to a supported Azure Linux version. Organizations should therefore include cluster and node-image upgrades in normal platform operations rather than treating an AKS cluster as a static environment.

What are the main limitations and tradeoffs of AKS?

AKS reduces control-plane work, but Kubernetes remains a complex operating model. Teams can still encounter networking issues, scheduling problems, upgrade planning, configuration drift, container security concerns, storage constraints, noisy-neighbor effects, and unexpected infrastructure cost. A managed Kubernetes service is not the same as a fully managed application platform.

AKS can also be excessive for applications that do not need Kubernetes portability, orchestration flexibility, or platform-level control. A small web application may be simpler on Azure App Service. Event-driven code may fit Azure Functions. Container workloads that need less Kubernetes administration may fit other Azure container services. The best choice depends on whether Kubernetes itself provides enough value to justify the skills and operational overhead it introduces.

Who should choose something else?

Teams without Kubernetes experience, organizations with only a few simple applications, and buyers that primarily want to deploy code without managing cluster concepts should compare higher-level Azure services before choosing AKS. AKS is also a weaker fit when the organization cannot dedicate ownership to upgrades, security, observability, networking, and cost control.

AKS is strongest for teams that deliberately want Kubernetes and need a managed Azure implementation with a choice between more automated defaults and deeper infrastructure control. The decision should be based on application architecture, operational skills, portability requirements, governance needs, and total platform cost rather than on Kubernetes popularity alone.