Virtual Machines vs AKS in Azure

The core trade-off

Running a workload on a VM is straightforward: provision a VM, install the application, and it runs. The VM’s CPU and memory are dedicated to that workload. If the workload uses 10% of the VM’s capacity, 90% is idle and still billed.

Running on AKS means multiple workloads share node capacity. A pod that uses 0.5 vCPU and 512 MiB runs on a node alongside other pods. The node’s unused capacity is available to any pod scheduled there. When the cluster has 10 services, each using an average of 15% of node resources, a single node can potentially run all 10 services at reasonable utilisation — versus 10 individual VMs running at 15% utilisation each.

The break-even point — where AKS overhead is justified by density savings — is typically around 3–5 containerised services. Below that, the operational complexity of running Kubernetes outweighs the density benefits. Above it, AKS typically reduces compute costs while improving deployment consistency.

Comparison across key dimensions

Density and cost efficiency at scale

Consider 10 microservices, each requiring 0.5 vCPU and 512 MiB at average load. On VMs, the smallest reasonable VM for each is a Standard_B2s (2 vCPU, 4 GiB) at approximately $35/month — total: $350/month for 10 VMs, utilising roughly 25% of their combined CPU capacity.

On AKS, these 10 pods need a combined 5 vCPUs and 5 GiB RAM. A node pool of two Standard_D4s_v5 VMs (4 vCPU, 16 GiB each) at ~$140/month each = $280/month provides that capacity with headroom — a saving of $70/month at half the utilisation. At higher service count, the density advantage grows.

The AKS node cost also benefits from Spot node pools, which can reduce node VM costs by 60–90% for batch workloads and non-critical services. VM Scale Sets support Spot VMs too, but AKS makes managing mixed on-demand and Spot node pools more straightforward.

Deployment consistency and rollouts

VM deployments are often heterogeneous — different VMs may have different versions of runtimes installed, different patch levels, or slightly different configurations that have accumulated over time. “Configuration drift” is a well-documented problem in VM-based infrastructure that leads to “works on this VM but not that one” issues.

Container images enforce reproducibility. Every pod running the same image runs exactly the same binaries, dependencies, and configuration. AKS Deployments support rolling updates natively — new pods are started before old pods are terminated, ensuring continuous availability. Rollbacks are a single command.

# Deploy a new image version with zero downtime
kubectl set image deployment/my-app my-app=myregistry.azurecr.io/my-app:v2.1

# Check rollout status
kubectl rollout status deployment/my-app

# Roll back if the new version is broken
kubectl rollout undo deployment/my-app

When VMs are the right choice

• Running 1–3 services where AKS operational overhead exceeds density savings
• Applications that cannot be containerised — legacy apps with deep OS dependencies, Windows Services, COM-based applications
• Workloads requiring specific OS versions, kernel modules, or hardware-level isolation
• Lift-and-shift migrations where containerisation would delay time-to-cloud significantly
• Teams without Kubernetes expertise where the learning curve is not justified by current workload scale

When AKS is the right choice

• Running 5+ containerised services where density savings justify the operational investment
• Teams deploying frequently — AKS rolling updates and GitOps workflows are faster and safer than VM-based deployment scripts
• Workloads with variable load that benefit from fast horizontal scaling — pods scale in seconds, new VMs take minutes
• Polyglot microservice environments where different services use different runtimes — each runs in its own container with its own dependencies
• Teams that want application portability across Azure, on-premises, or other clouds

Migration path from VMs to AKS

Moving from VM-hosted workloads to AKS is a multi-step process. The containerisation step is usually the most effort-intensive for legacy applications, but modern applications built with frameworks like .NET, Node.js, or Python containerise quickly.

1. Containerise: Write a Dockerfile for each application. Test locally with Docker or Docker Compose. Ensure the application reads configuration from environment variables (not hardcoded or file-based).
2. Build and push: Set up a CI pipeline to build the container image and push to Azure Container Registry (ACR). Tag images with the commit SHA or version number.
3. Deploy to AKS: Write Kubernetes Deployment and Service manifests. Deploy to a staging AKS cluster and validate.
4. Configure Ingress: Install an Ingress controller (NGINX, Azure Application Gateway Ingress Controller) and configure routing rules to replace the VM’s load balancer or direct DNS.
5. Cut over traffic: Update DNS to point to the AKS Ingress. Monitor application behaviour. Keep the VM running for a short overlap period as a fallback.
6. Decommission VM: Once the AKS deployment is stable, delete the VM, its managed disk, and associated resources.