AKS is Microsoft’s managed way to run Kubernetes on Azure, so teams spend their time on applications instead of on cluster plumbing.

The problem containers solved

Years ago, moving software from a developer’s laptop to a server was painful. The app worked on one machine and failed on another because a library was missing or a setting was different. A container fixes this by packing the application together with everything it needs to run. The package behaves the same everywhere, whether it sits on a laptop, a test server or a cloud machine.

Why Kubernetes appeared

One container is easy to run. Five hundred containers spread over fifty machines is a different story. Somebody must decide which machine runs which container, restart the ones that crash, add more copies when traffic grows, and route visitors to the right place. Doing this by hand is slow and error-prone. Kubernetes is the open-source system that does this work automatically. You describe what you want, such as “run six copies of my web app”, and Kubernetes keeps reality matching that description.

Why a managed service on top of Kubernetes

Running Kubernetes yourself is possible, but the cluster has a brain, called the control plane, that must always be healthy. It stores the entire cluster state in a small database, signs certificates that expire, needs backups, and must be upgraded carefully every few months. If the brain fails, you cannot deploy, scale or heal anything. Many teams discovered that looking after the brain consumed more effort than looking after their own products.

AKS removes that burden. Azure creates, runs, patches and repairs the control plane for you. You still own the worker machines and everything that runs on them, but the hardest, most delicate part is in expert hands. You get the same Kubernetes that the whole industry uses, with the same tools and the same concepts, plus tight links to the rest of Azure such as identity, networking, storage and monitoring.

Who looks after what: the shared responsibility idea

With a managed service, responsibility is split. It is important to know exactly where the line sits, because many outages happen in the gap between “I thought Azure handled that” and “Azure thought you handled that”.

Where AKS fits among Azure compute choices

Azure offers several ways to run software. Virtual machines give you the most control and the most chores. Simple app hosting services give you the least control and the least work. AKS sits in the middle: strong control over how applications are packaged, connected and scaled, without managing a fleet of hand-built servers. It is a good fit when you have many services, need fine control over networking and scaling, or want portability because Kubernetes skills and tools travel across clouds.

AKS is Kubernetes with Azure wiring, so every AKS discussion rests on a small set of Kubernetes building blocks.

The big idea: desired state and the reconciliation loop

The most important idea in Kubernetes is that you do not give step-by-step orders. You declare a goal, called the desired state, such as “I want four copies of this application running”. Kubernetes continuously compares that goal with what is actually running, which is the current state. When they differ, controllers take action until they match. This loop never stops.

The building blocks

Labels and selectors: how things find each other

Kubernetes uses simple name tags called labels to group objects. A service finds its pods by asking for every pod that carries a certain label. This loose link is powerful because nothing is wired by fixed address. If a pod disappears and a new one appears with the same label, the service automatically includes it.

Resource requests and limits

Every container can say how much processing power and memory it needs, which is called a request, and the most it may use, which is called a limit. The scheduler uses requests to decide which node has room. Limits protect neighbors from a greedy container. Many production problems later in this guide trace back to missing or unrealistic requests, so keep this idea in mind.

An AKS cluster has two halves: a managed brain that Azure runs and a set of worker machines that live in your subscription.

The two halves

Every AKS cluster is split into the control plane and the data plane. The control plane makes decisions and stores state. The data plane, also called the worker side, does the actual work of running your containers. The split is the heart of the managed model: Azure owns the first half, and you share ownership of the second.

flowchart TD
  U["You and your pipelines"] --> API["Kubernetes API server"]
  subgraph CP["Control plane - managed by Azure"]
    API --> ETCD["State store"]
    API --> SCH["Scheduler"]
    API --> CM["Controller manager"]
    API --> CCM["Cloud controller manager"]
  end
  subgraph DP["Data plane - worker nodes in your subscription"]
    N1["Node 1 with kubelet and pods"]
    N2["Node 2 with kubelet and pods"]
    N3["Node 3 with kubelet and pods"]
  end
  API --> N1
  API --> N2
  API --> N3
  CCM --> AZ["Azure resources: load balancers, disks, networks"]
        

What lives in the control plane

The control plane is the cluster’s office staff. It receives every request, remembers the cluster’s state, decides where new pods should run, and talks to Azure when the cluster needs a load balancer or a disk. In AKS you never see or log into these machines. You only talk to them through the Kubernetes API, using command-line tools, dashboards or automation.

In regions that support availability zones, the control plane of a cluster is automatically spread across zones, so a problem in one building of the data center does not take down the cluster’s brain. This spreading happens regardless of how you place your own nodes, which is a quiet but valuable benefit.

What lives in the data plane

The data plane is made of virtual machines that Azure creates in your subscription and organizes into groups called node pools. Each machine runs a small agent called the kubelet that listens to the control plane, starts containers when told to, and reports health back. Your applications run here, and so do some system helpers such as the cluster’s internal name service.

The node resource group

When you create a cluster, AKS makes a second resource group, separate from the one you named, to hold the infrastructure the cluster needs. Inside it you will find the virtual machine scale sets, network interfaces, load balancers, public addresses and disks. This group exists for AKS to manage.

How you talk to the cluster

Public and private access to the control plane

By default the API server has a public address protected by identity checks. Many organizations prefer a private cluster, where the API server is reachable only from inside their own network. There are also options that let you limit which internet addresses may reach the public endpoint. Choosing between these is one of the first real security decisions you will make, and it is easier to decide at creation time than to change later.

Each part of the control plane and each part of a node has one clear job, and knowing those jobs makes troubleshooting far easier.

Control plane components

Node components

Node pools: groups of identical machines

A node pool is a group of nodes that share the same machine size, operating system and settings. Behind the scenes, each pool is backed by an Azure virtual machine scale set, which is the Azure feature that can add or remove identical machines on demand. A cluster can have many pools, so you can mix small general-purpose machines with large memory-heavy ones or with graphics-capable ones for machine learning.

System pools and user pools

The reason to separate them is protection. If your application suddenly eats all available memory on a shared pool, the cluster’s name service could starve and every other application would lose the ability to find its neighbors. Keeping system helpers on their own pool means a runaway application can hurt only itself.

Operating system choices

AKS nodes can run Linux or Windows. For Linux, Ubuntu has long been the common choice, and Microsoft also offers its own Azure Linux distribution designed to be small and well maintained, along with newer container-focused options. Windows node pools exist for applications that must run on Windows. Operating system support changes over time, so always check the current support notes before choosing, and avoid mixing many different operating systems unless you truly need to.

Taints, tolerations and affinity in plain words

Sometimes you want to control where pods land. A taint on a node says “keep away unless you are specially allowed”. A toleration on a pod says “I am allowed”. Affinity and anti-affinity rules let pods say “place me near these” or “place me away from those”. Together they let you reserve expensive machines for the workloads that need them and spread copies of one application across different machines so a single failure cannot remove them all.

Two things are easy to mix up: the operating mode of a cluster, and the tier you pay for to manage its control plane.

Two operating modes

AKS comes in two modes. AKS Standard gives you direct control over networking, node pools, upgrade policy and cluster features. It is flexible, and it expects you to make many decisions. AKS Automatic, which became generally available in late 2025, is an opinionated mode. Azure picks production-ready defaults for security, networking, scaling, monitoring and upgrades, so you can start deploying applications without first becoming a cluster designer.

What AKS Automatic sets up for you

An Automatic cluster is preconfigured with the Standard management tier, support for up to 5,000 nodes, a cluster uptime guarantee and a pod readiness guarantee. It enables Microsoft Entra integration and Azure role-based access for authorization, workload identity for pods, network policies, the overlay networking model with the Cilium dataplane, and managed monitoring through Azure Monitor and managed Prometheus. It uses node auto-provisioning, based on the Karpenter project, to add and remove machines as pods need them, and it applies automatic upgrades for both Kubernetes versions and node operating system images.

It also adds deployment safeguards. These are checks that reject risky configurations, such as workloads that omit resource requests or health probes, before they can cause trouble. Managed system node pools, now generally available for Automatic clusters, hand even the care of the system machines to Azure. Despite all this guidance, an Automatic cluster remains fully compatible with the Kubernetes API, so familiar tools and manifests still work.

Three pricing tiers for cluster management

Separately from the mode, every Standard-mode cluster chooses a management tier: Free, Standard or Premium. In all three you pay for the nodes, storage and network you use. The tier decides what extra you get around the control plane.

The uptime guarantee for the Kubernetes API server is stronger when the cluster uses availability zones than when it does not. Check the current service agreement for exact percentages and conditions, since contract terms matter more than blog summaries. Note that the guarantee covers the API server, not your application. If your own pods are poorly designed, no tier will protect you.

Standard or Automatic: how to decide

Networking is the part of AKS that is hardest to change later, so it deserves the most careful thinking at the start.

Three kinds of addresses

Every cluster juggles three families of addresses. Node addresses belong to the virtual machines and come from your Azure virtual network. Pod addresses belong to the pods, and where they come from depends on the networking model you choose. Service addresses are virtual, stable addresses that exist only inside the cluster and point at groups of pods. Keeping these three ranges apart, and making sure none overlaps with other networks you must connect to, prevents a whole class of painful surprises.

The networking models

flowchart LR
  subgraph VNET["Your virtual network"]
    N1["Node 1 - network address"]
    N2["Node 2 - network address"]
  end
  subgraph OV["Overlay range hidden inside the cluster"]
    P1["Pod A - private pod address"]
    P2["Pod B - private pod address"]
    P3["Pod C - private pod address"]
  end
  N1 --- P1
  N1 --- P2
  N2 --- P3
  P1  P3
  EXT["Other networks"] --> N1
  EXT -.->|"reach pods through services and ingress"| P1
        

The Cilium dataplane

The dataplane is the engine that actually moves packets between pods and enforces network rules. AKS can run it with Cilium, a modern technology built on a feature of the Linux kernel known as eBPF. In simple terms, eBPF lets small safe programs run deep inside the operating system, so network decisions are made quickly and with great visibility. Cilium brings efficient policy enforcement, better observability of traffic flows and room for advanced features such as encryption between pods.

Network policies: rules for pod-to-pod traffic

By default, every pod in a Kubernetes cluster can talk to every other pod. That is convenient and dangerous. A network policy is a rule that says which pods may talk to which. A good starting position is to deny everything and then allow only the specific conversations your application needs. If one pod is compromised, the attacker finds closed doors instead of an open hallway.

Outbound traffic: how pods reach the internet

Pods often need to call external services, download updates or reach partner systems. AKS offers several outbound paths. The default path uses a load balancer’s public address. A managed network address translation gateway gives more outbound capacity and a stable set of outgoing addresses. Organizations with strict rules can route all outbound traffic through a firewall using custom routes, so every connection is inspected and logged.

DNS inside the cluster

Pods find each other by name through the cluster’s built-in DNS service. A name lookup that seems instant to a developer actually travels through this service. Under heavy load, DNS can become a bottleneck, and slow lookups look like mysterious application slowness. AKS offers options to run local DNS caching on nodes to reduce that pressure, and newer Automatic clusters preconfigure it.

Getting visitors into the cluster safely involves several layers, each with a different job.

Service types in a sentence each

A service of the internal type is reachable only inside the cluster. A service of the node-port type opens a port on every node and is rarely used directly. A service of the load-balancer type asks Azure to create a real load balancer with its own address, and the cloud controller manager does that work. Most production traffic from outside enters through a layer that understands web requests rather than through many separate load balancers.

Layer 4 and layer 7 in plain words

A layer 4 load balancer looks only at addresses and ports, like a mail sorter who reads just the street and number on an envelope. A layer 7 load balancer reads the content of web requests, like a receptionist who reads the full request and sends you to the right department. Layer 7 can route by website name or path, handle certificates, and apply security rules.

Public or private entry

Not every application should face the internet. Internal load balancers expose a service only on private addresses inside your network, which suits back-office tools and internal APIs. Many companies place a single, well-protected public entry point in front, with everything else kept private behind it.

Choosing an entry design

Certificates and names

Visitors expect a secure padlock, which means a valid certificate. Letting each team handle certificates by hand leads to expired certificates at the worst moment. Automate issuance and renewal, store certificates in a central secret store, and monitor expiry dates like any other critical metric.

Scaling happens on two levels: how many pods you run, and how many machines you have to hold them.

Two levels of scaling

Imagine a call center. Pod scaling is deciding how many agents sit at desks to answer calls. Node scaling is deciding how many desks and rooms you rent. If calls surge, you first add agents, but eventually you run out of desks and need more rooms. If you have rooms but no agents, calls go unanswered. Both levels must work together.

Scaling pods

Scaling nodes: the cluster autoscaler

The cluster autoscaler watches for pods that cannot be placed because no node has room. When it finds such pods, it grows a node pool by adding machines of that pool’s size. When machines sit mostly empty for a while, it removes them. It works pool by pool, so you must have created pools with suitable machine sizes in advance.

Scaling nodes: node auto-provisioning

Node auto-provisioning, often shortened to NAP, is a newer approach built on the open-source Karpenter project. Instead of growing a fixed pool, it reads what waiting pods actually need, such as processor, memory, graphics hardware and zone, and creates machines that fit. It generally became available in mid-2025 and now also supports options like capacity reservation groups. You describe allowed machine families and rules, and the system picks sizes automatically.

flowchart TD
  A["New pods cannot be placed"] --> B["Scheduler marks them pending"]
  B --> C["Node auto-provisioning reads their needs"]
  C --> D["Chooses machine size and zone that fit"]
  D --> E["Azure creates the virtual machine"]
  E --> F["Node joins the cluster"]
  F --> G["Pods are placed and start running"]
  G --> H["Idle or wasteful nodes are later consolidated away"]
        

Special hardware and savings options

Why requests make scaling honest

Autoscalers act on numbers. If a pod claims it needs almost nothing, the scheduler will pack too many of them on one machine and they will fight for resources. If a pod claims far more than it needs, you pay for idle capacity. Honest requests, measured from real usage, are the foundation of both performance and cost control.

Pods are temporary, so anything that must survive needs a home outside the pod.

The storage vocabulary

A volume is a folder attached to a pod. A persistent volume is a piece of real storage that exists independently of any pod. A persistent volume claim is a pod’s request for storage, such as “I need 100 gigabytes of fast disk”. A storage class describes the kind of storage on offer, such as fast or cheap. Kubernetes matches claims to storage, and in AKS the matching can create Azure storage on demand.

The main Azure storage options

Zones and disks: a classic surprise

A disk lives in one availability zone. If a pod using that disk is rescheduled onto a node in a different zone, it cannot attach the disk and stays stuck. Good designs use storage classes that are aware of zones, keep nodes in every zone, and consider zone-redundant storage types for important data. Understanding this single behavior prevents many confusing stuck-pod incidents.

Stateful workloads: think before you run them in the cluster

Running a database inside Kubernetes is possible and sometimes sensible, but it adds responsibility for backups, failover, upgrades and tuning. Many teams prefer Azure’s managed database services for primary data and keep the cluster for stateless applications. If you do run stateful workloads, use stateful sets, test restores regularly, and never treat a backup as real until you have restored from it at least once.

Following one deployment from request to running pod shows how every component earns its keep.

The story of one deployment

Suppose you ask for four copies of a web application. A surprising number of steps happen in a few seconds, and each step is handled by a different component that knows nothing about the others except through the shared state store. This loose cooperation is what makes Kubernetes resilient: if one helper restarts, it simply reads the state and carries on.

sequenceDiagram
  participant You as You or pipeline
  participant API as API server
  participant Store as State store
  participant Ctl as Controllers
  participant Sch as Scheduler
  participant Kub as Kubelet on node
  participant Run as Container runtime
  You->>API: Submit deployment for four copies
  API->>API: Check identity, permission and policy
  API->>Store: Save desired state
  Ctl->>API: Notice new deployment
  Ctl->>API: Create four pod records
  Sch->>API: Notice pods without a node
  Sch->>API: Assign each pod to a node
  Kub->>API: Notice pod assigned to my node
  Kub->>Run: Pull image and start containers
  Kub->>API: Report pod running and ready
        

Step by step in words

Health checks: the three questions

Rolling updates: changing the plane while it flies

When you publish a new version, Kubernetes does not stop everything and start again. It creates a few new pods, waits until they are ready, then retires a few old ones, and repeats. At every moment enough healthy pods remain to serve users. The speed and safety of this dance are controlled by settings for how many extra pods may be created and how many may be unavailable at once.

Graceful shutdown

When a pod must stop, Kubernetes first removes it from receiving new traffic, then tells the application to finish current work, and only after a waiting period forces it to stop. Applications that ignore the polite request drop active user requests. Good applications catch the signal, finish in-flight work and exit cleanly.

Tracing a single user click through every hop reveals where delay, failure and risk can hide.

The journey of one web request

A customer opens your site. Their request does not go straight to a pod. It passes through several layers, and each layer can add speed, protection or trouble. Knowing the path helps you place security checks, monitoring and timeouts where they matter.

flowchart LR
  C["Customer browser"] --> DNS["Public DNS"]
  DNS --> FD["Global edge with firewall"]
  FD --> GW["Gateway or ingress"]
  GW --> SVC["Service in the cluster"]
  SVC --> P1["Web pod"]
  P1 --> API["Internal API pod"]
  API --> DB["Managed database"]
  API --> Q["Message queue"]
  Q --> W["Worker pod"]
        

North-south and east-west traffic

Traffic that enters or leaves the cluster is called north-south. Traffic between pods inside the cluster is called east-west. Most security attention goes to north-south traffic, yet in a busy microservice system the majority of requests are east-west. Network policies and service meshes are tools for watching and controlling that internal chatter.

The path of a name lookup

When one pod calls another by name, the name goes to the cluster’s DNS service, which returns the stable service address. The dataplane then picks one healthy pod behind that service and forwards the request. Because the answer is a stable address and not a pod address, pods can be replaced without callers noticing.

Where time is spent

The control path versus the data path

One more distinction is valuable. The control path is the route that management commands take to reach the API server. The data path is the route your users’ traffic takes to reach your pods. Because they are separate, a control plane problem does not instantly stop already running applications. Your pods keep serving users even if you temporarily cannot deploy. However, without a working control plane, the cluster cannot heal or scale, so a prolonged outage still hurts.

Good cluster security is built in layers, so that one mistake never opens the whole building.

Defense in depth

A castle was never protected by a single wall. It had a moat, an outer wall, an inner wall, guards at the gate and a locked treasury. Cluster security follows the same idea. You protect the network, the identities, the images, the workloads and the data separately, so that if one layer fails, the next still stands.

The layers of AKS security

Two kinds of permission systems

Kubernetes has its own role-based access control that says which users may create or read which objects. Azure has its own, which says who may manage the cluster resource itself. AKS lets you use Azure roles for Kubernetes authorization too, so one set of groups and assignments covers both. This reduces the chance that a permission lives in one place and is forgotten in another.

Workload identity: no passwords in pods

Old designs stored a password or key in a secret so a pod could reach a database or storage account. Those secrets leak, expire and get copied. Workload identity solves this by letting the cluster issue each pod a signed identity token. Microsoft Entra ID trusts the cluster’s issuer, so it exchanges that token for a short-lived access token. Nothing long-lived is stored, and the pod can only do what that identity is allowed to do.

sequenceDiagram
  participant Pod as Application pod
  participant OIDC as Cluster token issuer
  participant Entra as Microsoft Entra ID
  participant Svc as Azure service
  Pod->>OIDC: Receive signed pod identity token
  Pod->>Entra: Present token and ask for access
  Entra->>OIDC: Check issuer is trusted
  Entra->>Pod: Return short-lived access token
  Pod->>Svc: Call service with access token
  Svc->>Pod: Allow only what this identity may do
        

Policies and guardrails

Policy is a way to say “no” automatically. You can require that every workload sets resource requests, forbid containers from running as the all-powerful administrator account, block images from untrusted registries, and demand that load balancers are internal by default. Doing this in policy means the rule applies to every team every time, instead of depending on people remembering a checklist.

Auditing and detection

Prevention is never perfect, so you must also be able to see what happened. The API server can record who did what, and those audit records can be sent to a central log store. Combine them with alerts for risky events, such as someone granting themselves broad access or a workload being created in a sensitive namespace.

Kubernetes moves fast, so staying current is not optional. The skill is making upgrades routine and boring.

Two things that need upgrading

An AKS cluster has two separate update streams. The Kubernetes version covers the control plane and the node software, and it changes the features and behavior of the cluster. The node operating system image covers security fixes for the underlying machines. Confusing the two leads to gaps, such as a cluster whose Kubernetes version is current but whose machines have gone unpatched for months.

The support window

AKS supports each generally available Kubernetes minor version for about twelve months. New minor versions arrive a few times a year, so a cluster that is never upgraded will fall out of support. Premium tier clusters can enable long-term support for selected versions, which extends the window to roughly two years, but that is a bridge for slow organizations, not a way to avoid upgrading.

Platform-initiated upgrades

Microsoft has announced that, starting in mid-2027, AKS will automatically upgrade clusters that remain on an unsupported Kubernetes version after a 60-day grace period. In plain terms, if you do not choose your upgrade moment, the platform will choose it for you. That is a strong reason to set up your own upgrade routine, maintenance windows and application readiness well before then.

Upgrade channels: choosing how automatic you want to be

How a rolling node upgrade works

AKS upgrades nodes gradually. It first adds a temporary extra node, called a surge node. It then picks an existing node, marks it as unavailable for new pods, and drains it by politely evicting its pods so they restart elsewhere. The empty node is rebuilt with the new version, rejoins the cluster, and the process moves to the next node. The surge setting controls how many nodes are handled at once, trading speed against risk.

flowchart TD
  A["Start upgrade of a node pool"] --> B["Add surge node with new version"]
  B --> C["Cordon one old node"]
  C --> D["Drain pods respecting disruption budgets"]
  D --> E["Rebuild node with new version"]
  E --> F{"More old nodes left"}
  F -->|"Yes"| C
  F -->|"No"| G["Remove surge capacity and finish"]
        

What can stop an upgrade

Maintenance windows and rollback

Maintenance windows let you say when automatic upgrades may happen, such as quiet hours on weekends. A node pool rollback capability, now generally available, lets you return a node pool to an earlier version if a problem appears after an upgrade. Rollback is a comfort, but it works best when you have also tested the new version beforehand and watched dashboards during the change.

A calm upgrade routine

You cannot fix what you cannot see, and in a cluster that changes every minute, seeing takes deliberate design.

The signals you collect

The Azure toolbox

Azure provides managed pieces that cover these signals. Container Insights collects logs and basic health data into Log Analytics. Azure Monitor managed service for Prometheus collects metrics in the open Prometheus format without you running the storage. Azure Managed Grafana gives dashboards over those metrics. Control plane metrics collection through managed Prometheus is now generally available, so you can watch the API server itself and spot trouble such as slow or throttled requests.

flowchart LR
  P["Pods and nodes"] --> M["Managed Prometheus metrics"]
  P --> L["Container logs"]
  CP["Control plane"] --> M
  CP --> AU["Audit and diagnostic logs"]
  M --> G["Managed Grafana dashboards"]
  L --> LA["Log Analytics workspace"]
  AU --> LA
  M --> AL["Alert rules"]
  LA --> AL
  AL --> ON["On-call people and runbooks"]
        

What to measure first

Alerting that people can live with

An alert should mean “a human must act now”. If alerts fire constantly and most are harmless, people learn to ignore them, and the one real alert gets lost in the noise. Alert on symptoms users feel, such as high error rates, rather than on every internal number. Attach each alert to a short runbook that explains what it means and what to try first.

Network visibility

When networking runs on Cilium, you can add flow visibility features that show which pods are talking to which and which connections were denied. This is very useful when a new network policy accidentally blocks a legitimate call and the application only shows a vague timeout.

Reliability means the system keeps serving users even when parts of it fail, and parts always fail.

Failure domains

A failure domain is a group of things that can fail together. One pod is a failure domain. So is one node, one availability zone and one whole region. Reliable design spreads copies across failure domains so no single event removes every copy of something important.

Building blocks of availability

Single region or multiple regions

flowchart TD
  U["Users worldwide"] --> FD["Global traffic manager"]
  FD --> R1["Region A cluster across three zones"]
  FD --> R2["Region B cluster across three zones"]
  R1 --> D1["Primary data store"]
  R2 --> D2["Replica data store"]
  D1 -.->|"replication"| D2
        

Active-active versus active-passive

Practice failure on purpose

Reliability that has never been tested is only a hope. Run drills where you remove a node, drain a zone or restore a backup, and see whether the system behaves as designed. Small, planned failures in a safe environment teach more than any document. Agree on targets for how much downtime and data loss you can tolerate, then check your design against those targets.

Kubernetes makes it easy to start resources and just as easy to forget them, so cost needs steady attention.

Where the money goes

For most clusters, the biggest cost by far is the virtual machines that make up the nodes. Next come storage, network traffic leaving Azure, load balancers, public addresses, and monitoring data. If you use the Standard or Premium tier, there is also a small fixed fee per cluster per hour. The control plane itself is not where most money disappears. Idle or oversized nodes are.

Levers you can pull

Make cost visible to the teams who cause it

When no one can see which team’s workloads cost what, no one feels responsible for waste. Use labels on workloads and tags on Azure resources so that spending can be grouped by team, product and environment. Sharing a monthly view with each team often reduces waste more than any technical trick.

Teams that run AKS well tend to repeat a handful of patterns, at the level of the platform, the cluster and the application.

Platform-level patterns

Cluster layout patterns

Delivery patterns

Application-level patterns

These habits look harmless on day one and become expensive on day two hundred.

A short, practical checklist in plain words, grouped by the topics you have just learned.

Best practices by area

Common mistakes beginners and experts both make

These typical scenarios show how the ideas in this guide combine in practice. They are illustrative patterns, not descriptions of specific companies.

What the examples have in common

In every scenario, the winning teams treated the cluster as a product with owners, standards and a routine. They kept state outside disposable pods, they spread failure risk deliberately, they automated patching and delivery, and they measured what mattered to users. The technology differs by industry, but the habits are strikingly similar.

Plain answers to questions that newcomers and experienced engineers often ask when they first meet AKS.

Not exactly. Kubernetes is the open-source system that runs containers. AKS is Azure’s managed service that runs Kubernetes for you. You use the same Kubernetes ideas and tools, but Azure takes care of the control plane and provides links to Azure networking, identity, storage and monitoring.

It depends on the tier. The Free tier has no cluster management fee, but also no financially backed uptime guarantee. Standard and Premium add a small hourly management fee and include the uptime guarantee. In every tier you pay for the nodes, storage, networking and monitoring you use.

If your team is small and your workloads are ordinary, Automatic gives you strong defaults and removes many decisions. If you need precise control over networking, node images, upgrade timing or unusual features, Standard fits better. Review the current limitations of each mode before deciding, because features evolve.

A container is a packaged running application. A pod is the unit Kubernetes schedules, and it wraps one or a few containers that share an address and storage. Most pods hold one main container, sometimes with helper containers beside it.

Anything stored only inside the pod is lost. Data in a persistent volume or in an external database survives and can be attached to the replacement pod. That is why durable data should always live outside the pod.

Plan for regular, small upgrades rather than rare large ones. AKS supports each Kubernetes minor version for roughly twelve months, so you should upgrade at least a couple of times a year, and apply patch and node image updates continuously through automatic channels.

No. The guarantee covers the availability of the Kubernetes API server. Your application stays available only if you design it that way, with several replicas, spread across zones, honest health checks and safe data storage.

Not at the start. A mesh helps when you need encrypted, identity-aware traffic between many services, fine-grained traffic control or deep traffic visibility. For simpler systems, network policies and good monitoring are often enough, and a mesh adds operational work.

A common starting point is at least separate clusters for production and non-production. More clusters give stronger isolation but cost more effort to manage. Add clusters when you have a clear reason, such as regulation, very different workloads or regional needs, and manage them as a fleet.

Use the Free tier where an uptime guarantee is not needed, keep node pools small, use spot machines for tolerant work, and stop the cluster outside working hours. Clean up forgotten disks, addresses and load balancers regularly.

You can, but it brings responsibility for backups, failover and upgrades. Many teams keep primary databases in managed Azure database services and use the cluster for stateless applications. If you do run stateful workloads, test restores often.

Technically there are ways, but it is discouraged. Nodes are replaced during upgrades and scaling, so manual fixes disappear. Fix the cause in configuration or code, and let the platform rebuild nodes from a known good state.

No. For a single small site or a simple event-driven function, simpler Azure services can be cheaper and easier. Kubernetes shines when you have many services, need strong control over scaling and networking, or want a common platform across teams.

AKS changes quickly. The official AKS documentation, the Kubernetes version release calendar, the release tracker and the published release notes are the best sources for current features, version dates and retirements. Treat any article, including this one, as a guide to understanding rather than a replacement for those pages.

AKS lets you run Kubernetes without running the cluster’s brain. Azure handles the control plane, while you decide how worker machines are shaped, connected, secured, scaled and updated. The service offers two operating modes and three management tiers, and its newer features such as node auto-provisioning, the overlay and Cilium networking model, workload identity and managed observability reduce the amount of plumbing teams must build. Yet the heart of success is unchanged: honest resource requests, truthful health checks, spread-out failure domains, least-privilege access, routine upgrades and clear visibility. Teams that treat the cluster as a product with a steady routine enjoy quiet, predictable operations. Teams that treat it as a one-time setup meet the same problems again and again.