Azure AKS Pricing UK 2026

Control plane tiers · Uptime SLA · Node pools · Spot nodes · Egress · Reserved Instances

All prices in GBP · UK South · Last verified April 2026

How AKS billing actually works

AKS has three distinct charging surfaces that appear on separate line items in your Azure bill:

• Control plane — the Kubernetes API server, etcd, and scheduling components managed by Azure. Free tier is £0; Standard tier is a flat £55.10/cluster/month regardless of node count.
• Node pool VMs — the virtual machines running your workloads. Billed at standard VM rates (same SKUs and prices as standalone Virtual Machines in UK South). This is almost always the largest component.
• Egress and Load Balancer — AKS provisions a Standard Load Balancer by default. Outbound rule data processing charges apply at £0.0037/GB, and these do not appear on the AKS pricing page at all.

For a typical production cluster with 5× D4s v3 nodes, the split looks roughly like: control plane 10%, node pool 88%, egress 2%. The node pool usually dominates — but the control plane is where the hidden surprises are.

The Standard tier upgrade trap

The Free tier control plane is suitable for dev and test environments. When you promote a cluster to production, the standard recommendation is to upgrade to Standard tier for the 99.5% uptime SLA on the API server.

What teams miss: Standard tier costs £55.10/cluster/month, billed from the moment you switch — even if you have zero workloads running. For organisations running multiple environments (dev, staging, uat, prod, dr), this adds up fast:

The fix is simple: keep dev and test clusters on Free tier. Only upgrade to Standard for clusters with real SLA requirements. Free tier clusters still get full Kubernetes functionality — just no guaranteed API server availability.

Uptime SLA: what you're actually paying for

Uptime SLA is a separate add-on, not a tier name. This is the source of significant confusion. The billing model is:

• Standard tier: £55.10/month (flat control plane fee)
• Uptime SLA enabled on Standard tier: £55.10 + £55.10 = £110.20/month
• Uptime SLA is not available on Free tier

The SLA uplift goes from 99.5% (Standard without Uptime SLA) to 99.95% (Standard with Uptime SLA). Whether that 0.45% availability gap is worth £55.10/month per cluster depends entirely on your workload. For most internal tooling, it isn't. For payment processing or customer-facing APIs, it often is.

Node pool sizing — VM-equivalent pricing with a system overhead

AKS node pool VMs are billed at the same rates as standalone VMs in UK South. A D4s v3 node in an AKS cluster costs the same as a standalone D4s v3 VM: £0.1746/hour (£127.46/month) at Pay-as-you-go rates.

What the pricing page doesn't show: every AKS node has a system node pool overhead. The kube-system components (coredns, metrics-server, konnectivity, azure-cni) consume approximately 0.5–1.0 vCPU and 1–2 GB RAM per node. On a D2s v3 (2 vCPU, 8 GB RAM), that's 25–50% of compute reserved for infrastructure before your workloads run.

Common sizing mistake: choosing D2s v3 because it costs half as much as D4s v3, then discovering that available capacity after system overhead is insufficient for the target pod density. Moving from D2s v3 to D4s v3 roughly doubles the cost but more than doubles usable capacity — the node overhead stays flat.

Spot node pools — the 70% discount and when it backfires

Spot nodes offer approximately 70% discount versus Pay-as-you-go rates. A D4s v3 drops from £0.1746/hr to roughly £0.052/hr. For a 10-node pool running 730 hours/month, that's £1,275 vs £381 — a saving worth having.

The risk: Azure can evict Spot VMs with 30 seconds notice when capacity is needed elsewhere. Kubernetes handles this by draining the node and rescheduling pods — but only if your workloads tolerate interruption. Safe use cases for Spot nodes:

• Batch processing jobs (idempotent, checkpointed)
• Dev and test workloads
• Stateless, horizontally-scalable services with multiple replicas
• CI/CD build agents

Avoid Spot for: stateful workloads (databases, message brokers), services with strict availability SLAs, anything that can't tolerate pod restart mid-operation. A common failure pattern is running a Redis cache or MongoDB replica on Spot nodes to save cost, then debugging availability incidents that trace back to node eviction.

Egress and Load Balancer rule pricing

AKS automatically provisions a Standard Load Balancer per cluster for outbound internet access. The first 5 LB rules are included in the Standard LB base price, but outbound rule data processing charges apply: £0.0037/GB.

This charge doesn't appear on the AKS pricing page. For clusters with low external traffic it's negligible, but for API-heavy or data-exporting workloads it can reach £30–50/month before the team notices it in the bill. Check the "Load Balancer" line in your Azure Cost Analysis, not the "Kubernetes Service" line.

You can reduce this by using a NAT Gateway instead of the default outbound rule (NAT Gateway charges differently — see the Networking calculator for modelling). For clusters in the same region communicating with other Azure services, use Private Endpoints and VNet peering to avoid public egress entirely.

Reserved Instances and Savings Plans for AKS nodes

AKS node pool VMs qualify for Reserved Instances and Azure Savings Plans — the same discounts available for standalone VMs. 1-year Reserved Instance for D4s v3 in UK South saves approximately 38% versus Pay-as-you-go; 3-year saves approximately 58%.

The complication: AKS node pools can be resized or deleted dynamically. If you reserve capacity for a D4s v3 node pool and later resize to D8s v3, the reservation becomes stranded — you pay the reservation fee but the discount no longer applies to the new SKU. Reservations follow the VM SKU, not the AKS cluster.

Azure Savings Plans are more flexible — they apply to any compute usage across eligible SKUs. If your node pool composition is likely to change within a year, a Savings Plan carries less risk than SKU-specific reservations.

Node pool sizing worked example — 100-user internal app

A common question on UK engineering teams: should we run 6× D2s v3 or 3× D4s v3 for a 100-user internal app? The total vCPU is identical (12 vCPU either way), but the cost and usable capacity differ significantly.

3× D4s v3 wins on cost (50% cheaper) and usable capacity (fewer system overhead duplicates). The trade-off is higher blast radius per node loss: losing one of three nodes drops 33% of capacity vs 17% for the six-node pool. For a 100-user internal app that isn't latency-critical, this is acceptable. Add a fourth D4s v3 as a buffer node (£509.84/month total) and you get both the cost efficiency and the blast-radius safety net.

For workloads requiring strict pod anti-affinity (e.g. one replica per node for HA), more smaller nodes gives more placement flexibility. For bulk throughput workloads (batch, ML inference), fewer larger nodes reduce scheduling overhead and network hops.

Monitoring AKS with Log Analytics — the Container Insights cost

Azure Monitor Container Insights is the recommended monitoring solution for AKS. It works by installing the Azure Monitor agent on each node, which collects metrics, logs, and container inventory and ships them to a Log Analytics workspace. It is one of the most common sources of unexpectedly large Log Analytics bills.

Container Insights ingestion typically generates 2–5 GB per node per day, depending on cluster activity, the number of containers per node, and log verbosity. For a 5-node cluster:

Container Insights ingestion is the single largest variable cost in many AKS deployments — larger than the control plane fee for clusters with verbose workloads. Three levers to reduce it:

• Reduce collection frequency — the default metrics scrape interval is 60 seconds. Increasing to 120s halves metric volume with minimal monitoring impact for non-latency-critical clusters.
• Exclude noisy namespaces — kube-system and the Azure CNI components generate significant log volume. Exclude them from collection if you don't need them in your workspace.
• Use Basic Logs tier for Container Insights tables — Log Analytics Basic tier (£0.524/GB ingestion, 8-day retention) is available for ContainerLog and ContainerInsights tables. This is appropriate if you query these logs rarely and primarily need them for incident response.

Use the Log Analytics calculator to model Container Insights ingestion costs before enabling it on a new cluster — especially before enabling it on a cluster with high pod density or verbose logging.

Frequently asked questions