Azure Container Apps Pricing: Consumption vs Dedicated, and the Idle Bill (2026)

Azure Container Apps pricing is sold as "pay only for what you use," and for a service that genuinely scales to zero that is close to true — until you set a minimum replica count. From that point on, Azure Container Apps pricing has two rates for the same vCPU: an active rate while a request is being served, and a lower idle rate that runs 24/7 for every replica you keep warm. Most surprise bills are idle time, not traffic.

This guide breaks Azure Container Apps pricing into its parts. The vCPU, memory, and request rates in the table below are pulled at build time from the Azure Retail Prices API for East US, so they are Azure published list prices, not our estimates. After the table we cover what the pricing page skips and work through a realistic example.

How Azure Container Apps pricing works#

There are two billing models:

• Consumption — serverless. You are billed per second for the vCPU and memory your replicas are allocated, at an active rate when they are handling requests and an idle rate when they are running but quiet. Requests are billed per million. Scale to zero and the compute bill goes to zero.
• Dedicated (workload profiles) — you reserve nodes of a fixed size and pay per hour for them regardless of utilisation, plus a flat management fee per hour for the profile. Useful for large or steady workloads, GPU, or when you need predictable isolation.

Every Container App runs inside an environment. The environment itself has no base charge on the Consumption model, but options attached to it — a private endpoint, a dedicated workload profile — do.

Azure Container Apps pricing table (East US)#

Last updated: 2026-09-06. Azure Container Apps published pricing (East US, USD), pulled from the Azure Retail Prices API at build time. Published list prices, not a live feed.

Azure also grants a monthly free allowance per subscription on the Consumption plan — the first 180,000 vCPU-seconds, 360,000 GiB-seconds, and 2 million requests each month are not billed. The worked example below subtracts it.

What the Container Apps pricing page doesn't tell you#

Minimum replicas bill around the clock. Set minReplicas: 0 and an app with no traffic costs nothing. Set minReplicas: 2 — the usual move to avoid cold starts — and those two replicas bill at the idle vCPU and memory rate for all 730 hours in the month whether or not a single request arrives. The idle rate is much lower than the active rate, but it is not zero, and it is the single most common reason a "serverless" bill is bigger than expected.

Active vs idle is decided per second, not per deployment. A replica is "active" for the seconds it is processing at least one request and "idle" otherwise. You cannot see the split in advance; it depends entirely on traffic shape. A bursty API that is busy 20% of the time and warm the rest pays mostly the idle rate; a steadily loaded one pays mostly the active rate.

Allocated, not used. Billing is on the vCPU and memory you request for the replica, not what the container consumes. A replica set to 1 vCPU that averages 0.2 vCPU still bills for 1.

Dedicated plans bill the node, not the app. On a workload profile you pay for the whole node's vCPU and memory by the hour, plus roughly $0.10/hour (about $73/month) in management fee per profile, before your apps use any of it. Consumption is cheaper until you are running enough always-on replicas to fill a node.

Scale rules can thrash. An aggressive KEDA scale rule that adds and removes replicas on small traffic swings pays the active ramp-up cost repeatedly and can leave replicas running through the cooldown window.

Hidden and networking costs to watch#

Egress is billed separately, under Azure Bandwidth. Data transfer out of the environment to the internet is not in the Container Apps meters at all — it is billed at standard Azure bandwidth rates (the first 100 GB/month is free, then roughly $0.087/GB). A chatty API returning large payloads can run an egress bill that rivals its compute bill.

A stable outbound IP costs extra. Container Apps environments share outbound IPs by default. If a downstream service needs to allowlist you, you attach a NAT gateway or a private endpoint — the private endpoint alone is about $0.10/hour (about $73/month) per environment, from the table above, before per-GB processing.

Logs go to Log Analytics, which is metered per GB. By default a Container Apps environment ships console and system logs to a Log Analytics workspace, and Azure Monitor bills that ingestion per GB. High log verbosity across many replicas adds a line item that never appears in a Container Apps cost estimate.

Dedicated GPU profiles are large, hourly, and always on. A GPU workload profile bills by the hour for the whole GPU node for as long as the profile exists, not just while a job runs.

A worked example: a Consumption API with warm replicas#

Assume an East US Consumption app:

• Average 3 replicas running, each allocated 0.5 vCPU and 1 GiB
• Traffic keeps replicas active about 40% of wall-clock time; the other 60% they are warm but idle (minReplicas holds them up)
• 50 million requests per month
• 730 hours in the month

vCPU (3 replicas × 0.5 vCPU × 730 h × 3,600 s = 3,942,000 vCPU-seconds/month)

• Active: 40% = 1,576,800 vCPU-sec, minus the 180,000 free = 1,396,800 × $0.000024 = $33.52
• Idle: 60% = 2,365,200 vCPU-sec × $0.000003 = $7.10

Memory (3 × 1 GiB × 730 h × 3,600 s = 7,884,000 GiB-seconds/month)

• Active: 40% = 3,153,600 GiB-sec, minus the 360,000 free = 2,793,600 × $0.000003 = $8.38
• Idle: 60% = 4,730,400 GiB-sec × $0.000003 = $14.19

Requests

• 50,000,000 minus 2,000,000 free = 48,000,000 ÷ 1,000,000 × $0.40 = $19.20

Line item	Monthly cost
vCPU active	$33.52
vCPU idle	$7.10
Memory active	$8.38
Memory idle	$14.19
Requests	$19.20
Total	$82.39

The idle lines — vCPU and memory together — are $21.29, about a quarter of the bill, and they are pure minReplicas cost. Drop the minimum to zero and accept cold starts on the first request after quiet periods and the same app is closer to $61. Run it instead on a Dedicated workload profile and you add ~$73/month in management fee before any compute, so Consumption stays ahead until you are filling a node with always-on replicas. For the node-based Kubernetes equivalent on Azure, see the AKS pricing guide; for AWS, the EKS pricing guide.

Frequently asked questions#

Is Azure Container Apps free?#

The Consumption plan has a monthly free grant per subscription: 180,000 vCPU-seconds, 360,000 GiB-seconds, and 2 million requests. An app that scales to zero and stays within that grant costs nothing. Past the grant, every vCPU-second, GiB-second, and request is billed at the rates above.

Why is my Container Apps bill high when traffic is low?#

Almost always minReplicas above zero. Those replicas bill at the idle vCPU and memory rate 24/7. Other causes: over-allocated vCPU/memory per replica, egress billed under Azure Bandwidth, and Log Analytics ingestion.

What's the difference between the active and idle rates?#

The active rate applies for the seconds a replica is processing at least one request; the idle rate applies when it is running but not serving anything. The idle rate is much lower, but it still runs continuously for every replica you keep warm.

When is the Dedicated plan cheaper than Consumption?#

When you have enough steady, always-on load to keep a workload-profile node reasonably full. Below that, the flat per-hour management fee and paying for a whole node make Consumption cheaper.

Does Azure Container Apps charge for data transfer?#

Not in its own meters. Egress to the internet is billed at standard Azure Bandwidth rates (first 100 GB/month free, then roughly $0.087/GB), on a separate line.

Where Container Apps cost actually comes from#

Container Apps cost tracks two things: how much vCPU and memory each replica is allocated (not what it uses), and how many replicas stay warm when there is no work to do. Both are the same problem Kubernetes teams have with resource requests and idle nodes — provisioned capacity nobody is using. That is the core of what DevZero's Kubernetes cost optimization addresses on the cluster side: measuring real usage and trimming the gap. You can also compare live compute rates across clouds and instance types in the instance pricing explorer.