Startups at Microsoft

11 MIN READ

Understanding Azure Container Apps Costs: From Replica Reservations to Running Nodes - Part 1

srinman

Microsoft

Sep 25, 2026

Low CPU utilization does not necessarily mean a low Azure Container Apps bill. Learn how resource allocations, replicas, revisions, and workload-profile nodes interact and how Azure Monitor and Grafana can help you identify right-sizing opportunities without compromising reliability.

Welcome to Part 1 of our three-part blog series, where we begin exploring the topic in depth.

This part is all about Concepts, Scaling, and Dedicated profile cost. It does not cover Consumption profile cost details.

The second section covers ACA compute, metrics, and cost observability.

The third part introduces an Azure Container Apps cost optimizer tool that analyzes CPU and memory utilization to identify underutilized apps and potential right-sizing opportunities. It provides recommendations without modifying Azure resources.

ACA Dedicated object and cost hierarchy

1. Object hierarchy

Construct	What it is	Directly billed?	Scale behavior	Cost implication
Container Apps environment	Secure and networking boundary containing apps, jobs, and workload profiles.	Yes, conditionally	Does not autoscale or scale to zero.	One Dedicated plan management fee applies while the environment has one or more Dedicated workload profiles. Some environment features can also trigger this charge.
Dedicated workload profile	A named pool of single-tenant nodes of one size, such as D4, D8, or E4. Multiple apps and jobs can share an application profile.	No separate meter beyond its nodes.	Node count scales between minimumCount and maximumCount.	Profile size chooses the vCPU and GiB purchased each time a node runs. Separate profiles can create separate unused-capacity pools.
Flexible workload profile (preview)	Single-tenant compute with nodes abstracted from the customer. It supports larger per-replica sizes, dedicated networking, and planned maintenance windows.	Yes, per replica	App replicas autoscale but cannot scale to zero.	Billed like a Consumption profile plus the Dedicated plan management fee
Workload profile instance (node)	One running VM-sized unit in a Dedicated profile. For example, a D4 provides 4 vCPU and 16 GiB before platform reservations.	Yes	ACA adds/removes nodes as aggregate replica reservations require, within profile limits.	This is the main Dedicated compute cost unit: billing is per running profile instance (node), not per app or replica. The node’s full provisioned vCPU and memory are billed per second while it runs, whether busy or idle.
Container app	Long-running service definition and stable application endpoint.	No	The app does not scale; its active revision or revisions do.	App count alone is not a meter. Its configuration creates revisions and determines replica reservations.
Revision	Immutable snapshot of an app template: images, containers, CPU/memory, and scale rules.	No direct revision charge	An active revision scales replicas independently. An inactive revision has no running replicas.	An inactive revision costs no compute. An active revision costs capacity only through its running replicas. Multiple active revisions can multiply the minimum replica floor.
Replica	One running copy of a revision. All main and sidecar containers in that copy run together.	Dedicated: indirectly.	Horizontal app autoscaling adds/removes replicas between minReplicas and maxReplicas, subject to profile rules.	On Dedicated, reservations can force another billed node.
Container / sidecar	A process image inside each replica. Sidecars share the replica lifecycle and network.	Indirectly	Scales only with its replica.	Every container’s CPU and memory allocation contributes to the replica total. A sidecar is repeated in every replica.
Container Apps job	Finite manual, scheduled, or event-driven task. Each execution can have one or more replicas.	Dedicated: indirectly.	Executions and their parallel replicas start and stop; event jobs can autoscale executions.	n/a
Ingress proxy	Environment edge proxy for TLS termination, routing, load balancing, and revision traffic splitting.	Default: No proxy compute charge. Premium: Yes, through dedicated nodes.	Default and premium proxy instances scale independently from app replicas.	Premium ingress uses an exclusive Dedicated profile with at least two nodes. Those nodes cannot host apps or jobs.

Resource terms that are easy to confuse

Allocated CPU and memory: the cpu and memory configured on every container. In ACA these values reserve capacity and act as the container’s limit. There is no separate lower Kubernetes-style request that allows denser scheduling.
Reserved capacity: the sum of CPU and memory allocations for all running replicas. Scheduling must fit both dimensions; spare CPU cannot compensate for exhausted memory, or vice versa.
Actual utilization: CPU and memory the process really uses. Low utilization does not reduce a Dedicated node’s bill. It indicates an opportunity to right-size or reduce replicas.
System reservation: ACA reserves part of every node for platform components. Do not plan to place replicas against 100% of the advertised profile vCPU and memory.
Scale rule: HTTP, TCP, CPU, memory, or KEDA-supported event criteria used to calculate replica count. Rules are revision-scoped.
Minimum and maximum replicas: bounds applied per active revision, not a pooled limit across all revisions.
Minimum and maximum nodes: bounds applied to a workload profile. They are distinct from replica limits.

2. What actually appears on the Dedicated bill

For a non-GPU Dedicated profile, the approximate hourly ACA charge is:

N_p is the number of running nodes in profile p.
V_p and M_p are the advertised vCPU and GiB in one node of that profile.
R_vCPU and R_GiB are the regional Dedicated rates.
C_management is charged once for the Dedicated plan in the environment, not once per app or profile.

The monthly estimate below uses 730 hours. Network egress, Log Analytics, Azure Monitor, Azure Files, Container Registry, NAT Gateway, private endpoints, and other attached Azure services are separate meters.

Illustrative public-price example

The ACA pricing page displayed these WestUS pay-as-you-go USD rates when this document was updated on 2026-09-14:

Meter	Example rate
Dedicated plan management	$0.10/hour
Dedicated vCPU	$0.0571/vCPU-hour
Dedicated memory	$0.0050/GiB-hour

For one D4 node (4 vCPU, 16 GiB):

One environment with one continuously running D4 node is therefore approximately:

Prices vary by region, currency, agreement, and savings plan. Use the Azure Container Apps pricing page and Azure Pricing Calculator for a current customer-specific estimate.

Cost attribution: meter versus cause

Item	Separate bill line?	How to explain its cost
Environment	Management meter	Adding the first Dedicated profile creates the fixed management cost. Adding more app profiles does not multiply that fee within the same environment.
Profile instance/node	Compute meter	Every running node bills its full profile vCPU and memory. This is the direct variable Dedicated charge.
App	No	It is a logical owner of revisions and replicas. Attribute a share of node cost to it using reserved CPU/memory, but ACA does not bill the app separately.
Active revision	No	Its replicas reserve node capacity. Two active revisions commonly mean two independent replica floors.
Inactive revision	No	Stored configuration only; it has no running replicas and no compute charge.
Replica	No, on Dedicated	It consumes node capacity. The economic effect is stepwise: extra replicas are free only while they fit in already-paid spare capacity; the next node creates a full-node cost step.
CPU and memory allocation	No per-replica meter on Dedicated	These values control bin packing and node count. Oversizing wastes purchased capacity and causes earlier scale-out.

3. Replica reservations and node packing

For revision r, its running reservation is:

The profile must have enough usable capacity for the sum across all active revisions, apps, and running jobs assigned to it. Node scale-out is constrained independently by CPU, memory, and placement requirements.

Example: one app on a D4 profile

Assume each replica contains:

main container: 1.0 vCPU and 2 GiB
sidecar: 0.25 vCPU and 0.5 GiB
total per replica: 1.25 vCPU and 2.5 GiB

Running replicas	Reserved by the app	Cost effect
0	0 vCPU / 0 GiB	No app capacity, but profile nodes remain billed if minimumCount > 0.
1	1.25 vCPU / 2.5 GiB	Fits on an existing D4 if sufficient usable capacity remains.
2	2.5 vCPU / 5 GiB	Still may fit on one node.
3	3.75 vCPU / 7.5 GiB	Likely requires another D4 because ACA keeps some node capacity for the platform.
4	5 vCPU / 10 GiB	Requires at least two D4 nodes on CPU capacity alone.

The exact packing boundary is not simply advertised node size divided by replica size. Platform reservation, other workloads, deployment overlap, health, and placement can require more nodes.

Why right-sizing matters

Changing a replica from 1 vCPU / 2 GiB to 0.5 vCPU / 1 GiB does not instantly halve the invoice if node count stays unchanged. It creates room to pack more replicas and can prevent or remove a whole node. The saving appears when the profile crosses a node boundary.

Monitor both:

NodeCount, split by workload profile, for the billed compute count.
CoresQuotaUsed or TotalCoresQuotaUsed for reserved app cores.
UsageNanoCores and CpuPercentage for actual CPU use.
WorkingSetBytes and MemoryPercentage for actual memory use.
Replicas, split by revision, to explain changes in reservation.

See Monitor Azure Container Apps metrics.

4. Single versus multiple revisions

Single revision mode

Single revision mode is the default. ACA brings up the new revision, waits for it to become ready, moves traffic, and deactivates the old revision. During a deployment, old and new replicas can overlap temporarily for zero downtime, so short-lived capacity and node-count spikes are expected.

Use single revision mode when only one production version needs to stay active. It reduces the chance of forgotten replicas consuming profile capacity.

Multiple revision mode

Multiple revision mode supports traffic splitting, labels, A/B tests, and blue-green deployment. Each active revision retains its own template and scaling configuration.

Suppose two active revisions each specify minReplicas: 2, and each replica reserves 1 vCPU / 2 GiB:

That reservation exists before traffic-driven scale-out. A revision receiving little or even zero percent of normal traffic can still retain its minimum replicas while it remains active. After a rollout or test:

Move traffic to the intended revision.
Verify the replacement revision is healthy.
Deactivate revisions no longer required.
Confirm replica and profile node counts fall after scale-in delays.

Important : a revision is not inherently a billed item. An active revision with running replicas consumes paid capacity; an inactive revision does not.

See Revisions in Azure Container Apps and Traffic splitting.

5. What can autoscale or scale to zero?

Objects that autoscale in Azure Container Apps

Scope	Can autoscale?	Can reach zero?	Important cost behavior
App revision replicas (Consumption or Dedicated)	Yes: HTTP, TCP, CPU, memory, and event/KEDA rules	Yes, when minReplicas: 0 and the rule supports activation from zero	Zero replicas reserve no app capacity. CPU and memory rules cannot activate an app from zero because there is no running replica to measure; combine them with an event/HTTP trigger or keep one replica.
Dedicated application-profile nodes	Yes, between profile min/max	Yes, when profile minimumCount is 0 and no workloads require nodes	Node scale follows aggregate reserved capacity and is slower than replica scaling. A nonzero minimum is a permanent compute floor.
Individual container or sidecar	No	No independently	It starts and stops with every replica; its allocation is multiplied by replica count.
Active revision	Its replicas autoscale	Its replicas can reach zero	The revision can remain active at zero and reactivate. Deactivate it when it is no longer needed.
Inactive revision	No	Already has zero replicas	No compute capacity is consumed.
Job execution	Manual, scheduled, or event-triggered; event executions can scale	Stops when complete	n/a
Default ingress proxy	Platform managed	Not user-controlled	Two proxy instances by default, scaling up to 10; proxy compute has no additional billing.
Premium ingress profile	Yes, independently from app scaling	No	Minimum is two dedicated nodes. This is a persistent cost floor even when all app profiles and replicas are at zero.
Environment	No	No	The environment remains, as does any applicable Dedicated management fee.

Replica scaling is reactive and profile-node scaling must then supply enough physical capacity. Set both ceilings deliberately: maxReplicas limits logical concurrency, while profile maximumCount limits available compute and cost. If replica demand exceeds profile capacity or quota, replicas can remain unscheduled or fail to scale as intended.

See Scaling in Azure Container Apps and Workload profiles.

6. Premium ingress and its cost

Every ACA environment already has an edge ingress proxy for TLS termination, load balancing, app routing, and traffic splitting.

Default ingress

Starts with two proxy instances and can scale to 10.
Each proxy receives up to 1 vCPU and 2 GB memory.
There is no additional charge for proxy instances, vCPU, or memory.
Use it unless measurements show sustained ingress saturation or an advanced setting is required.

Premium ingress

Premium ingress is intended for environments where default ingress becomes a high-scale bottleneck or advanced ingress controls are required. It adds:

a selectable D4 through D32 Dedicated workload profile for ingress;
configurable node scale range;
configurable termination grace period, idle request timeout, and request-header count.

Its cost consequences are easy to miss:

The ingress workload profile is exclusive. Apps and jobs cannot use its spare capacity.
It has a minimum of two workload-profile nodes and cannot scale to zero.
It scales independently from app replicas, based on ingress proxy CPU and memory utilization.
It is billed at the selected Dedicated workload profile rate.

Using the illustrative rates above, the minimum premium-ingress footprint on D4 is:

If this environment also has one continuously running D4 application node, the approximate ACA total is:

This example includes one environment management fee, one app-profile node, and two premium-ingress nodes. It excludes all ancillary Azure services.

Before enabling premium ingress, inspect ingress CPU and memory metrics and confirm the default proxy is sustaining its maximum scale. After enabling it, treat the ingress node minimum, maximum, and profile size as production capacity settings with direct cost impact.

See Configure ingress in an ACA environment.

7. Other related cost terms

Feature	Cost consideration
Azure Monitor and Log Analytics	Platform metrics are available automatically, but log ingestion, retention, queries, alerts, managed Grafana, and diagnostic export can add charges. Control noisy console logs and retention.
Azure Files	Persistent mounts are billed by Azure Storage for provisioned/used capacity, transactions, snapshots, and redundancy. Ephemeral container/replica storage is part of the running compute lifecycle.
Networking	Internet or cross-region data transfer, NAT Gateway, Azure Firewall, Application Gateway/WAF, Front Door, private endpoints, and DNS can each add separate charges.
Container registry	ACR tier, storage, builds, geo-replication, and data transfer are separate from ACA.
Dapr and sidecars	A sidecar’s configured resources repeat in every replica. Dapr can also affect scale-to-zero suitability, especially for actors.
Health probes and deployment overlap	Not separate meters, but failed starts, slow readiness, and zero-downtime rollout overlap can hold additional replicas and nodes longer.
Zones and resiliency	Minimum replicas, topology, and spare headroom needed for failure tolerance increase the capacity floor. Optimize cost without removing the capacity required by the service objective.
Quotas	Quotas do not cost money by themselves, but can prevent profile node scale-out. Check general-purpose, memory-optimized, or GPU core quota before relying on a configured maximum.

8. Cost-review checklist

Count running profile nodes with NodeCount; this is the strongest direct indicator of Dedicated compute cost.
Record every profile’s type, minimumCount, maximumCount, and assigned apps/jobs.
Set application profiles to minimumCount: 0 only when node cold-start latency is acceptable.
Find active revisions left behind after blue-green or A/B releases.
Sum main-container and sidecar CPU/memory per replica, then multiply by replicas per active revision.
Compare reserved metrics with actual CPU and memory over representative peak periods.
Right-size both CPU and memory; either dimension can force another node.
Review minReplicas, maxReplicas, scale thresholds, cooldown, job parallelism, and retry limits.
Avoid many lightly used profiles when compatible workloads could share one pool.
Treat premium ingress as at least two dedicated, non-shareable nodes; enable it from measured need.
Include observability, storage, registry, and network services in the complete solution estimate.

9. Microsoft documentation

Updated Sep 25, 2026

Version 1.0