azurerm_container_app cost estimation
Serverless containers billed by active vCPU-seconds and GiB-seconds. An always-on 0.5 vCPU / 1 GiB replica is ~$39/month; scale-to-zero apps cost far less.
An azurerm_container_app runs containers on the serverless Container Apps platform without you managing nodes or a Kubernetes cluster. On the Consumption plan the cost model is resource-seconds: you pay for the vCPU and memory your replicas actually use, per second, only while they're active. There's a meaningful free grant each month (the first ~180,000 vCPU-seconds and ~360,000 GiB-seconds), after which active vCPU is roughly $0.000024/vCPU-second and memory about $0.000003/GiB-second.
That makes the cost entirely a function of how long replicas run × how big they are. A single 0.5 vCPU / 1 GiB replica left running 24/7 is about $39/month. The same app with scale-to-zero (min_replicas = 0) that only runs a few hours a day might cost a couple of dollars — the platform's headline advantage over an always-on App Service plan or AKS node.
The cost surprises come from two directions. First, min_replicas > 0 defeats scale-to-zero: setting a floor of 2 replicas for availability means you pay for two always-on replicas regardless of traffic. Second, generous CPU/memory requests multiply directly — bumping a replica from 0.5 to 2 vCPU quadruples the compute line whether or not the app uses it.
Container Apps also bills a separate environment (azurerm_container_app_environment) and, if enabled, Log Analytics ingestion for logs. c3x estimates the app from template_container_cpu and template_container_memory_gb at the active-usage rates; request-per-second and scale-to-zero behaviour are usage-driven.
Terraform example
A minimal but realistic configuration that C3X can estimate.
resource "azurerm_container_app" "api" {
name = "api"
container_app_environment_id = azurerm_container_app_environment.main.id
resource_group_name = azurerm_resource_group.main.name
revision_mode = "Single"
template {
min_replicas = 0
max_replicas = 10
container {
name = "api"
image = "myregistry.azurecr.io/api:latest"
cpu = 0.5
memory = "1Gi"
}
}
ingress {
external_enabled = true
target_port = 8080
traffic_weight {
percentage = 100
latest_revision = true
}
}
}Pricing dimensions
What you actually pay for when you provision azurerm_container_app.
| Dimension | Unit | What's being charged |
|---|---|---|
| Active vCPU usage | per vCPU-second | vCPU allocated to running replicas, per second of activity, after the monthly free grant. ~$0.000024/vCPU-second active |
| Active memory usage | per GiB-second | Memory allocated to running replicas, per second of activity, after the monthly free grant. ~$0.000003/GiB-second active |
| Requests | per million | Per-request charge after the free monthly grant. Usually a rounding error next to resource-seconds. |
Sample C3X output
One always-on 0.5 vCPU / 1 GiB replica (min_replicas ≥ 1) for the month:
azurerm_container_app.api
├─ vCPU active usage 0.5 vCPU × 730h $30.46
└─ Memory active usage 1 GiB × 730h $8.96
Monthly $39.42Optimization tips
Common ways to reduce azurerm_container_app cost without changing the workload.
Set min_replicas = 0 for anything that can scale to zero
Up to ~95% for spiky/low-traffic appsScale-to-zero is the whole point of Container Apps. An HTTP app with min_replicas = 0 spins down when idle and pays nothing while stopped. Setting a non-zero floor for availability turns a serverless app back into an always-on bill.
Right-size CPU and memory requests
Proportional to the cutCost scales linearly with the cpu and memory you request per container. Many apps are over-allocated 'to be safe' at 1–2 vCPU when 0.25–0.5 is plenty. Halving the request halves the compute line.
Keep min_replicas low and let max_replicas absorb spikes
One+ replica-month per lowered floorYou pay for replicas that run, so a floor of 1 plus a generous max gives availability without paying for peak capacity around the clock. Reserve min_replicas ≥ 2 for apps that genuinely can't tolerate a cold start.
Use a dedicated workload profile only at sustained scale
Workload-dependentThe Consumption plan is cheapest for variable load. Dedicated workload profiles make sense only when an app runs large and steady enough that reserved capacity beats per-second billing — measure before switching.
FAQ
How is Azure Container Apps billed?
On the Consumption plan, by active resource-seconds: vCPU-seconds and GiB-seconds your replicas use while running, plus a per-request charge, after a monthly free grant. You pay for what runs, not for provisioned nodes.
Does an idle Container App cost anything?
With min_replicas = 0, an idle app scales to zero and the resource-second charges stop. You may still pay for the environment and any Log Analytics ingestion. With min_replicas ≥ 1, the floor replicas bill continuously.
Why is my Container App more expensive than expected?
Usually min_replicas > 0 (always-on replicas) or oversized cpu/memory requests. Both bill regardless of traffic. Check the floor and the per-container resource requests first.
How does c3x estimate a Container App?
From template_container_cpu and template_container_memory_gb at Azure's active vCPU-second and GiB-second rates. Because real cost depends on how long replicas run, scale-to-zero and request volume are modelled as usage in c3x-usage.yml.
Related resources
Estimate this resource in your own Terraform
Free, open source, no API key. C3X parses your Terraform and shows line-item cost for every resource, including azurerm_container_app.