Azure Compute & Container Cost Optimization
Compute spans everything from raw virtual machines to fully managed containers and serverless functions, and the pricing model changes completely depending on which layer a workload runs at — hourly VM billing, per-second container billing, and per-execution function billing don't share a mental model, let alone a single optimization approach. This guide covers where cost concentrates at each layer and how to commit to compute spend without locking into the wrong instrument. For the broader cost optimization method this fits into, see the main Azure cost optimization guide.
Virtual Machines
VMs are the foundation most other compute services are built on, and they're also where waste is easiest to create and easiest to overlook. Sizing is the first lever — a VM family and size chosen for peak load stays provisioned at that size even when actual usage never approaches it. Idle runtime compounds that: dev, test, and staging VMs left running outside business hours bill exactly the same as production VMs that are actually being used around the clock. Autoscaling — via Virtual Machine Scale Sets rather than a fixed VM count — closes some of that gap automatically, and Spot VMs offer a steep discount in exchange for the possibility of eviction, which makes them a strong fit for fault-tolerant or batch workloads and a poor fit for anything that can't tolerate interruption. Finally, disk and network costs are easy to lose track of separately from the VM itself: attached managed disks keep billing after a VM is deallocated, and egress from VM-hosted workloads shows up as its own line item entirely apart from compute.
Kubernetes — AKS
AKS costs are really VM costs plus orchestration overhead: the underlying node pools bill at standard VM rates, and on top of that, the Standard pricing tier adds an uptime SLA fee that the free tier doesn't carry. The most common source of waste is pod resource requests set well above what a pod actually consumes, which forces the cluster to provision more node capacity than the real workload needs. See cutting AKS costs for where to look first.
Containers — Container Apps & Container Instances
Service | Billing model | Best for |
|---|---|---|
Consumption-based — vCPU-seconds, memory-seconds, and requests, with scale-to-zero when idle | Variable or bursty workloads that benefit from scaling down to nothing between requests | |
Per-second billing for CPU and memory while the container is running, with no scale-to-zero orchestration | Simple, standalone containers that need to run continuously without the overhead of an orchestration layer |
Container Apps is usually cheaper for anything with meaningful idle time, since Container Instances keeps billing at full rate regardless of whether it's actively serving traffic. Container Instances can still be the simpler and cheaper choice for a single always-on container that doesn't need scaling logic at all.
Serverless — Azure Functions
Azure Functions bills differently depending on the hosting plan. The Consumption plan charges per execution and execution time with a free monthly grant. Flex Consumption — now Microsoft's recommended plan for new apps — also bills per execution and GB-second, but at a slightly higher rate than Consumption, in exchange for configurable memory sizes and optional "always ready" instances that reduce cold starts without paying full Premium rates; instances not marked always-ready still scale to zero. The Premium plan bills continuously for pre-warmed instances regardless of how often they're actually invoked, and the Dedicated plan folds Functions into the cost of an underlying App Service Plan. Choosing Premium for cold-start avoidance on a low-traffic function is a common way to overpay — Flex Consumption's always-ready option now covers that same need at a lower cost.
See Azure Functions cost optimization for how to pick the right plan.
App Service
App Service bills per plan, not per app, which means multiple low-traffic apps are often better consolidated onto fewer, larger plans instead of each running on its own dedicated plan sized for its own peak. See App Service plan consolidation for how to identify which apps are good candidates.
Dedicated Hosts
Dedicated Hosts commit an entire physical server to a single customer, billed as a fixed cost regardless of how many VMs actually run on it. That makes them expensive by default, and cost-effective only when VM density on the host is high enough that the per-VM effective cost drops below standard VM pricing — or when licensing and compliance requirements make single-tenant hardware a requirement rather than a choice. See Dedicated Host cost optimization for how to judge whether that threshold is being met.
Committing to Compute Spend
Azure offers several commitment mechanisms for compute — including Reservations, Savings Plans, and Hybrid Benefit — that apply across services such as VMs, App Service, and eligible container and serverless workloads. See the full guide to Azure commitment management for how to choose between them and combine them without over-committing.
Balancing that across every layer here — VMs, AKS node pools, App Service plans, and whichever containers or functions are eligible for a commitment — while workloads keep shifting between them is exactly the kind of ongoing, cross-cutting problem that's easy to get wrong by hand as an environment grows.
Managing Azure Compute Costs with nOps
nOps was built to handle exactly this balancing act automatically, with:
- Commitment Management: Automatically maximize discounts and minimize commitment risk across Reservations, Savings Plans, Reserved Capacity, and Hybrid Benefit — continuously rebalancing as usage shifts rather than requiring a one-time decision. Customers typically save ~20% by switching to nOps — and with results-based pricing, you pay only when you get better results.
- Unified visibility: Get all of your spending from Azure, AWS, GCP, AI, and SaaS in one place, with cost allocation by application, customer, team, or business unit to understand what is driving spend and where optimization will have the greatest impact.
We've talked to companies that can save millions on their cloud bills by switching to nOps from competitors. Book a free savings analysis to quantify exactly how much more you could save across your Azure compute and the rest of your cloud environment.
nOps manages $5B+ in cloud spend and was recently rated #1 in G2's Cloud Cost Management category.
Demo
AI-Powered Cost Management Platform
Discover how much you can save in just 10 minutes!
Book a Demo
FAQ
How much does an AKS cluster cost?
An AKS cluster's cost is mostly the cost of its underlying node pool VMs, billed at standard VM rates. On top of that, the Standard pricing tier adds an uptime SLA fee per cluster that the free tier doesn't carry, and any load balancers or persistent storage attached to the cluster bill separately as their own resources.
Container Apps or Container Instances — which is cheaper?
Container Apps is typically cheaper for workloads with meaningful idle time, since it scales to zero and bills only for active usage. Container Instances bills continuously at a per-second rate while running, so it's more cost-effective mainly for simple, genuinely always-on containers that don't need the ability to scale down.
How are Azure Functions billed?
It depends on the hosting plan. The Consumption plan bills per execution and execution time, with a free monthly grant. The Premium plan bills continuously for pre-warmed instances regardless of invocation volume, trading cost for eliminated cold starts. The Dedicated plan bills as part of whatever App Service Plan the function runs on.
When do Dedicated Hosts cost less than standard VMs?
Only when VM density on the host is high enough that the fixed host cost, divided across all the VMs running on it, comes in below what the same VMs would cost individually. Outside of high-density scenarios, Dedicated Hosts are chosen for licensing or compliance requirements that mandate single-tenant hardware, not for cost savings.
Can you run AKS on Spot VMs?
Yes, through Spot node pools, which offer a steep discount versus standard node pools in exchange for the possibility of eviction. They're a good fit for fault-tolerant or batch workloads that can handle interruption, and a poor fit for system-critical node pools that need to stay available.
