Your AKS Migration Is Costing You More Than the VMs It Replaced

Logan Hemphill
Apr 9
6 min read

You moved six workloads to Azure Kubernetes Service last quarter expecting a 30% cost reduction. Your Azure bill went up 20% instead. Nobody on your team can explain where the money is going...because half of it isn't even in the AKS resource group.

I've seen this pattern several times. A team reads a case study about containers saving money at scale, gets approval for a migration project, spins up an AKS cluster, containerizes a handful of apps, and then watches the bill climb instead of drop. The problem isn't Kubernetes itself. The problem is that nobody did the actual math before migrating, and the hidden costs of running AKS add up faster than most teams realize.

The cost savings pitch vs. reality

The argument for containerization usually goes something like this: containers are lighter than VMs, you can pack more workloads onto fewer nodes, and you'll use your compute more efficiently. That's technically true at scale. At 50+ microservices with variable load patterns and a mature platform engineering team, Kubernetes absolutely earns its keep. But that's not where most organizations start.

Most organizations start by taking three to five monolithic apps running on dedicated VMs, wrapping them in Docker containers, and deploying them to a three node AKS cluster. At that scale, you aren't consolidating anything. You're adding overhead.

Where the money actually goes

Here's the breakdown that catches teams off guard.

Compute overhead you can't avoid. Every AKS cluster needs a system node pool. Microsoft recommends at least three nodes for production. Those nodes run CoreDNS, kube proxy, the metrics server, and other system components. On a Standard_D2s_v5 (2 vCPU, 8 GB RAM), that's roughly $70 per node per month, so $210/month just to keep the lights on before a single application pod runs.

Then there's the resource reservation tax. AKS reserves memory and CPU on every node for kubelet and the OS. On a node with 8 GB of RAM and a max pod count of 30, AKS reserves about 650 MB for kube reserved (20 MB times 30 pods plus 50 MB) and another 100 MB as the hard eviction threshold. That's 750 MB gone on an 8 GB node. You're paying for 8 GB but your pods can only use about 7.25 GB. On smaller nodes, the percentage gets worse. A 4 GB node with a higher max pod count can lose over 25% of its memory to system reservations before a single application container starts.

Container Insights will eat your monitoring budget. If you enable Container Insights (and you should, because running Kubernetes blind is asking for trouble), every node starts shipping logs and metrics to your Log Analytics workspace. A modest three node cluster generating stdout logs, Kubernetes events, and performance metrics can easily push 5 to 10 GB per day into Log Analytics. At $2.30 per GB on pay as you go, that's $345 to $690 per month in ingestion costs alone. I've seen teams with 10 node clusters spending more on Container Insights than on the actual compute.

The supporting cast of services. AKS doesn't run in isolation. You need Azure Container Registry to store your images ($5/month for Basic, $20/month for Standard, $50/month for Premium with geo replication). You need an Azure Load Balancer or Application Gateway for ingress, which adds $18 to $200+ per month depending on the SKU. You probably need Azure Key Vault integration for secrets, which has per operation costs. And if you're running any persistent workloads, you're paying for managed disks attached to your nodes on top of the VM cost.

The team tax. This one doesn't show up on the Azure bill, but it's real. Your team that was perfectly capable of managing IIS on Windows VMs now needs to understand pod scheduling, resource requests and limits, horizontal pod autoscaling, ingress controllers, persistent volume claims, and Helm charts. The learning curve isn't free. The first six months of a Kubernetes migration involve a lot of debugging that would have been trivial on a VM. That's engineering time you're paying for.

The math nobody does before migrating

Let me walk through a real scenario I've seen. A team had three applications running on three Standard_D4s_v5 VMs (4 vCPU, 16 GB RAM each). Total compute cost: about $420/month ($140 per VM on pay as you go in East US).

They migrated to AKS. Here's what the new environment cost:

Three node user pool (Standard_D4s_v5): $420/month. Same compute, because the apps needed the same resources. Containers don't magically reduce CPU and memory requirements for a monolith you shoved into a Docker image. The workloads didn't get lighter...they just got a new address.

Two node system pool (Standard_D2s_v5): $140/month. The system components needed somewhere to run.

Container Insights ingestion (estimated 7 GB/day): $483/month. Five nodes generating logs, metrics, Kubernetes events.

Azure Container Registry (Standard): $20/month.

Azure Load Balancer (Standard): $18/month base plus data processing.

Total: roughly $1,081/month, compared to $420/month on VMs. That's a 157% INCREASE.

Now, someone will point out that they were also paying for monitoring on the VMs. Fair. But VM diagnostic settings generating a couple GB per day is a fraction of what a Kubernetes cluster produces. And the VMs didn't need a container registry or a separate system pool.

When containerization actually saves money

I'm not arguing against Kubernetes. I'm arguing against containerizing for cost reasons when you don't have the workload profile to benefit from it.

Kubernetes saves money when you have dozens of microservices with variable load patterns that can share node resources efficiently. When you're running 40 pods across 10 nodes and the cluster autoscaler can scale down to 5 nodes at night, you're winning. When you have workloads that need to scale from 2 replicas to 20 in response to traffic spikes and scale back down within minutes, Kubernetes earns its keep.

Kubernetes doesn't save money when you take three monoliths, each consuming a fixed amount of CPU and memory, and run them on dedicated nodes that look identical to the VMs they replaced. At that point you've added complexity and cost for ZERO density improvement.

What I'd tell your team before migrating

If you're considering an AKS migration, do this first. Run a KQL query against your existing VM performance data to understand your actual resource utilization:

// Check average CPU and memory utilization across your VMs over the last 30 days
Perf
| where TimeGenerated > ago(30d)
| where ObjectName == "Processor" and CounterName == "% Processor Time" and InstanceName == "_Total"
| summarize AvgCPU = avg(CounterValue), P95CPU = percentile(CounterValue, 95) by Computer
| join kind=inner (
    Perf
    | where TimeGenerated > ago(30d)
    | where ObjectName == "Memory" and CounterName == "% Committed Bytes In Use"
    | summarize AvgMemory = avg(CounterValue), P95Memory = percentile(CounterValue, 95) by Computer
) on Computer
| project Computer, AvgCPU, P95CPU, AvgMemory, P95Memory
| order by AvgCPU desc

If your VMs are sitting at 15% CPU and 30% memory on average...you have a right sizing problem, not a containerization opportunity. Right sizing those VMs will save you more money in a week than a six month AKS migration ever will.

If your VMs are running at 70%+ utilization with predictable loads, reserved instances or savings plans will cut your bill by 30 to 60% with zero architectural change. A one year reservation on a Standard_D4s_v5 drops the price from $140/month to about $96/month with instance size flexibility (or ~$83/month if you lock to a specific region). A three year commitment takes it to roughly $65/month. That's over 50% savings without touching a Dockerfile.

Containerize when you need deployment velocity, scaling flexibility, or workload density. Don't containerize because someone told you containers are cheaper. They aren't, unless you have the workload patterns and the team maturity to make them cheaper.

The real reason to migrate to AKS

Frankly, the best reason to move to Kubernetes has nothing to do with cost. It's deployment velocity. Rolling updates with zero downtime. Blue green deployments without managing two sets of infrastructure. Horizontal scaling that responds to demand automatically. Self healing workloads that restart when they crash.

Those are real operational improvements that justify the cost increase. But they only justify it if your organization actually needs those capabilities. If you're deploying once a month and your traffic is flat, you're paying a premium for features you aren't using.

Here's the deal. I've helped organizations that genuinely needed Kubernetes, and I've talked others out of it. The right answer depends on where you are today and where you're headed. If your migration plan doesn't include a side by side cost comparison that accounts for system pools, monitoring ingestion, supporting services, and the engineering time to operate the cluster, you're flying blind.

If this sounds like your environment, I do free 30 minute Azure cost reviews. It's a conversation to see if there's a fit, not a sales pitch.

Book a Free Azure Cost Review