Skip to content
AzureAzure Container AppsContainers

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.

DimensionUnitWhat's being charged
Active vCPU usageper vCPU-secondvCPU allocated to running replicas, per second of activity, after the monthly free grant.
~$0.000024/vCPU-second active
Active memory usageper GiB-secondMemory allocated to running replicas, per second of activity, after the monthly free grant.
~$0.000003/GiB-second active
Requestsper millionPer-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.42

Optimization 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 apps

Scale-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 cut

Cost scales linearly with the cpu and memory you request per container. Many apps are over-allocated 'to be safe' at 1 to 2 vCPU when 0.25 to 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 floor

You 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-dependent

The 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

Azure
azurerm_linux_function_app

The other Azure serverless compute option; event-driven vs container-based

Azure
azurerm_kubernetes_cluster

Full AKS when you need node-level control instead of serverless containers

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.

Get StartedStar on GitHub
← Browse all Azure resources