A production API can look inexpensive in a monthly forecast, but official Azure list pricing and pay as you go rates don’t make that forecast a guaranteed bill. Illustrative estimates, including any eligible savings plan scenario, should account for always-on replicas, request volume, logs, egress, and attached services. Together, these inputs determine the monthly cost.
Azure Container Apps is a serverless containers platform for containerized workloads. The right plan depends less on container count than on replica count, traffic shape, and replica lifetime. Availability targets also affect whether workloads can scale to zero, so test estimates against realistic operating conditions.
Key takeaways
- The Consumption plan bills allocated vCPU and memory over time, plus HTTP requests after the monthly allowance is exhausted.
- Each Azure subscription receives 180,000 vCPU-seconds, 360,000 GiB-seconds, and 2 million free grants per calendar month. These allowances are shared across resources in the subscription.
- Scale-to-zero can eliminate charges for running resources during inactive periods, but background work and persistent activity can keep replicas running.
- Dedicated plan capacity is billed at the environment level and includes a plan management fee. Steady workloads may be modeled with pay as you go rates or an eligible savings plan, which is a separate pricing scenario from list pricing.
- A credible API forecast includes compute, requests, observability, registry, networking, gateway, data, and outbound-transfer costs.
Azure Container Apps pricing: choose the plan by traffic shape
Azure Container Apps offers Consumption and Dedicated plans within Container Apps environments. Both run containerized workloads and support autoscaling. Use official regional rates for estimates, with pay as you go as the neutral baseline. Compare architecture and utilization with Azure Kubernetes Service, not just headline rates. Evaluate an eligible savings plan only for sustained qualifying capacity, rather than assuming a savings plan fits variable demand.
Consumption plan for variable API demand
The Consumption plan bills at the application level. Azure measures the vCPU-seconds and GiB-seconds allocated to running replicas, plus HTTP requests. Configured resource requests shape that allocation, but aren’t a separate billing meter. Allocation matters even when an API is underutilized, so a 1 vCPU replica consumes twice the CPU meter of a 0.5 vCPU replica during the same period. Total usage also depends on replica count.
This model suits APIs with large quiet periods, unpredictable bursts, or independently scaling microservices. It also supports scale to zero, which avoids resource-consumption charges after replicas reach zero. For specialized workloads such as dynamic sessions, price session behavior separately.
Dedicated plan for provisioned capacity
The Dedicated plan uses dedicated profile capacity, which reserves compute for applications in an environment. Billing includes profile-instance vCPU-hours and GiB-hours, along with an environment-level management charge when dedicated capacity exists.
That structure favors APIs with sustained traffic, consistently warm capacity requirements, or hardware needs that don’t fit the Consumption profile. It also makes capacity planning more important, because idle provisioned capacity remains part of the cost base.
How Consumption plan billing works
Microsoft’s Container Apps billing documentation identifies three core meters: allocated vCPU time, measured in vCPU-seconds; allocated memory time, measured in GiB-seconds; and HTTP requests. Compute and memory charges accrue by the second after free grants are exhausted.
Free grants and metered usage
Every subscription receives the following monthly free grants, shared across its eligible Container Apps Consumption usage:
| Meter | Monthly free grant |
|---|---|
| vCPU-seconds | 180,000 |
| GiB-seconds | 360,000 |
| HTTP requests | 2,000,000 |
The grants reset each calendar month. They apply subscription-wide, not separately to every app, revision, environment, or resource group. They’re also separate from any other pricing commitment.
After that allowance, resource calculation follows each replica’s allocation and runtime. A 0.5 vCPU, 1 GiB API replica running for 10,000 seconds consumes 5,000 vCPU-seconds and 10,000 GiB-seconds. Higher replica counts multiply both values.
Active, idle, and zero replicas
A replica incurs active usage while starting up or processing work. When Azure holds a healthy replica at the configured minimum without active work, it may qualify for a reduced idle usage rate. Microsoft doesn’t publish one universal idle percentage for every region or agreement, so teams should use the applicable regional rate rather than a generic 30% or 40% assumption.
A revision with minReplicas: 0 can scale to zero, and Azure Monitor can verify its replica state, runtime, and scaling behavior. Zero replicas remove Container Apps resource-consumption charges, but dependent-service charges still apply.
A minimum replica is a reliability choice with a cost consequence. Even an API with almost no requests can consume grants or paid compute while one replica remains running.
Build a production API cost model
A defensible estimate starts with a month of operating assumptions. Before opening the pricing calculator, record traffic, configured CPU and memory, resource requests, replica count, minimum and maximum replicas, runtime percentage, and dependent services. Use regional official list pricing or pay as you go pricing for the baseline. Validate a savings plan separately, and don’t subtract a discount unless the calculator confirms the selected meter and agreement are eligible.
Set workload assumptions before entering prices
For example, model an East US API on the Consumption profile with 0.5 vCPU and 1 GiB per replica, minReplicas: 0, a maximum of 10 replicas, and 30 days in the month. Suppose it averages two active replicas for 5% of the month, serves 4 million HTTP requests, and sends application logs to a Log Analytics workspace.
Traffic concurrency and autoscaling turn the replica count into replica-seconds. That scenario produces about 259,200 replica-seconds of runtime. Its compute usage is 129,600 vCPU-seconds and 259,200 GiB-seconds before considering idle time. Both sit within the monthly resource grants, while 2 million requests exceed the included request allowance.
Compare the configured values and resource requests with observed production utilization. Container Apps calculates allocated CPU and memory, not a generic Kubernetes invoice. Use Azure Monitor to validate runtime, request volume, and replica assumptions before finalizing the monthly cost.
This is an illustration, not a guaranteed bill. Region, currency, enterprise agreement, traffic concurrency, autoscaling behavior, and actual replica runtime can change the result.
Add the charges outside the app runtime
Container Apps compute is only one line item. Production API budgets often need Azure Container Registry image storage and pulls, Log Analytics ingestion and retention, Application Insights telemetry, API Management, Front Door or Application Gateway, Key Vault, managed databases, private networking, and internet egress.
Connect financial reporting to API behavior as well. A practical guide to cost per API call helps teams divide shared platform charges across endpoints, tenants, or products instead of assigning all spend to the container runtime.
Dedicated plan costs and workload profiles
Dedicated plan capacity changes the unit of analysis. Rather than adding up individual app replicas, forecast capacity across workload profiles to meet capacity, availability, and scaling targets.
Management fees and provisioned resources
Microsoft lists official meters for management fees, vCPU-hours, memory GiB-hours, and GPUs where applicable. Environment-level charges are official meter or calculator outputs, not guaranteed totals. A management fee applies when the environment contains Dedicated workload profiles, whether one API uses all the capacity or not.
Profile instances also create a practical utilization question. A team may request several replicas across multiple APIs, yet pay for provisioned capacity those applications don’t fully use. Compare measured utilization with a pay as you go baseline during reviews instead of inventing a system-overhead percentage.
Savings plans and regional estimates
Microsoft presents pay as you go, one-year savings plan, and three-year savings plan options for Dedicated compute. A savings plan can lower a steady eligible baseline, but it won’t correct overprovisioning, low utilization, management fees, or unused provisioned capacity.
Use the Azure Pricing Calculator for current official list pricing in the deployment region and under the agreement you actually buy. Validate savings plan coverage and term length there. Prices vary by region, currency, offer type, and related Azure services.
Why an API may fail to scale to zero
Setting minReplicas: 0 permits zero scaling, but it doesn’t guarantee a particular replica count at runtime. Autoscaling must see no work that requires a replica. Continuous HTTP traffic, open or long-lived connections, scheduled jobs, queue messages, and event-driven scale rules can all maintain activity.
Review revisions in Azure Monitor alongside ingress and scaler metrics. Use Azure Monitor to correlate revisions, scaler metrics, health probes, and replica transitions. A worker handling background jobs should use an appropriate event trigger. An ingress-disabled worker needs an event path or appropriate trigger to wake from zero. Conversely, an API with active connections may need a nonzero minimum if its latency objective rules out a cold start.
Container health also affects cost behavior. Microsoft notes that all containers in an app must be running and healthy for idle-pricing eligibility. A failing sidecar, misconfigured health probe, or poorly sized resource requests can cause restarts and prevent the stable idle usage assumed in a forecast.
A cost optimization checklist for production APIs
Treat cost control as part of API operations, not a quarterly billing exercise. The following checks expose most avoidable Container Apps spend:
- Right-size CPU and memory resource requests using observed CPU, memory, latency, and restart data rather than development defaults.
- Set
minReplicas: 0only for endpoints that tolerate cold start latency. Keep background jobs on a separate scaling strategy, then use Azure Monitor to validate actual replica count, latency, memory consumption, and scaling behavior, including whether replicas scale to zero. - Cap
maxReplicasto a tested concurrency limit so autoscaling during a traffic spike cannot create uncontrolled downstream database or API costs. - Review CPU and memory settings against production observations, adjusting resource requests alongside runtime and replica usage because they don’t determine the bill alone.
- Keep HTTP scale rules aligned with real concurrency and request duration. A slow downstream dependency can inflate replica time even at modest request volume.
- Sample high-volume logs, set practical retention, and remove verbose debug telemetry outside incident windows.
- Export cost and usage data on a schedule. Azure Cost Exports for FinOps can support chargeback analysis across subscriptions and cost centers.
- Review eligible savings plan coverage only after measuring a steady baseline. It isn’t a substitute for right-sizing.
- Tag environments and resource groups by service, owner, and product so shared gateway, registry, and observability charges have an accountable destination.
Budgets and anomaly alerts should cover the full resource group or application platform, not only Container Apps. Include logs, egress, gateways, registries, data, and dependent Azure services in that view. A sudden increase in logging or egress can exceed the runtime charge for a lightly used API.
Azure Container Apps, AWS Fargate, and Cloud Run
These services solve similar deployment problems, but their billing models reward different operating patterns. Azure App Service and serverless containers offer other deployment paths for APIs. Normalize each platform’s scaling unit, autoscaling behavior, and resource requests before comparing costs.
When Container Apps has an economic edge
Consumption plan free grants and scale-to-zero can work well for intermittent HTTP APIs. Container Apps also provides revisions, traffic splitting, managed ingress, Dapr integration, and KEDA-style scale behavior within Azure’s broader identity and networking model.
A Dedicated plan can suit steady traffic, but its provisioned capacity changes the comparison. For a cluster-based alternative, Azure Kubernetes Service may offer more control with different operational overhead.
For an enterprise platform, the stronger question is whether surrounding Azure services already meet the API’s database, observability, policy, and private-connectivity requirements. Dynamic sessions may also introduce separate service and session costs. Migration savings can disappear if those dependencies move poorly.
How Fargate and Cloud Run differ
AWS Fargate generally bills for provisioned task CPU and memory while tasks run. Google Cloud Run bills request-based services using instance CPU and memory time, requests, and network-related charges, with its own free tier and configuration choices. Review Cloud Run’s current pricing model before comparing estimates.
Don’t compare an Azure savings plan directly with another provider’s on-demand estimate. Compare equivalent list-price assumptions or equivalent commitment assumptions instead.
Google’s serverless container service comparison is useful for mapping terms such as tasks, services, revisions, and scaling units. For shared Azure Kubernetes Service estates, use workload-level allocation methods rather than comparing only cluster invoices.
FAQ
How does the Consumption plan calculate monthly resource charges?
Azure measures allocated vCPU-seconds and GiB-seconds for replicas while they run, then bills HTTP requests after the relevant monthly grants. Active and qualifying idle replicas use different rates. Your total depends on regional prices and how long replicas remain in each state. Use Azure Monitor to verify active and idle replica behavior instead of relying only on a forecast.
What is the exact idle billing rate?
There is no single universal idle percentage for a 2026 estimate. Microsoft documents a reduced idle rate, but teams should confirm the current regional rate and agreement in official pricing tools before approving a budget. Test the estimate against observed replica activity when possible.
Does minReplicas: 0 always produce zero cost?
No. It removes resource-consumption charges only after the revision reaches zero replicas. Events, open connections, scheduled work, failed containers, and dependent Azure services can still produce charges or keep the app active.
Does a savings plan change a Dedicated estimate?
A savings plan is a separate eligibility and commitment scenario that must be validated for your region and agreement. It can change eligible pricing, but it doesn’t eliminate utilization or dependency costs.
Final cost decision
The most useful Azure Container Apps estimate starts with vCPU-seconds, GiB-seconds, replica count, requests, and traffic patterns. Then it adds the services around the API that production systems depend on.
For intermittent endpoints, scale to zero can make Consumption highly efficient. Cost optimization depends on matching the plan to traffic and latency. For steady capacity needs, Dedicated workload profiles may offer a better operating fit. A cold start may justify a nonzero minimum, while a savings plan should be shown separately from official list pricing.
Use pay as you go as the neutral baseline. Validate assumptions in the regional pricing calculator, then check actual runtime and scaling behavior in Azure Monitor.
