Azure Container Apps
Zone redundancy is a one-time choice made at environment creation — you can't enable or disable it later, and the SLA doesn't change either way. A fully managed, serverless container host with no durable state of its own and no native cross-region failover.
Non-zone-redundant environment
All replicas run without zone spread — either the region doesn't support Availability Zones, or zone redundancy wasn't enabled when the environment was created. The built-in health-probe/restart mechanism still runs regardless.
- Replication
- None
- RPO
- N/A — stateless container platform; state lives in whatever backing service you use
- RTO
- Minutes — the platform still auto-heals failed replicas and restarts unhealthy containers, just without zone protection
- Failover trigger
- Automatic
- Relative cost
- No extra cost
Baseline — same compute/request/vCore-second pricing as zone-redundant.
Zone-redundant environment (2+ replicas)
Replicas are automatically scheduled across every Availability Zone in the environment's region. Requires a minimum replica count of 2 (3 recommended) to actually spread, and must be chosen when the environment is created — it can't be added or removed afterward.
- Replication
- None
- RPO
- 0 — routing/scheduling layer, no durable state of its own
- RTO
- ~30 seconds — health probes detect unreachable replicas and reroute traffic to the remaining healthy zones
- Failover trigger
- Automatic
- Relative cost
- No extra cost
No extra charge — confirmed by Microsoft's own reliability documentation. Same compute rates whether zone-redundant or not.
Migrating an existing non-zone-redundant environment means creating a new zone-redundant one and redeploying every app into it — there's no in-place toggle.
Independent environment + Front Door/Traffic Manager in a second region (customer-built)
Container Apps is a single-region service with no native cross-region failover. Multi-region means a fully separate environment per region (its own VNet), container images replicated via a geo-replicated Container Registry, and Front Door or Traffic Manager steering traffic between them.
- Replication
- N/A
- RPO
- Entirely dependent on the backing data services behind the app — Container Apps itself holds no durable state to lose
- RTO
- Entirely dependent on your regional failover architecture
- Failover trigger
- Automatic
- Relative cost
- High cost premium
A fully separate environment, VNet, and redeployed apps in a second region, plus Front Door/Traffic Manager and a geo-replicated Container Registry — essentially a second production deployment.
Shows Unknown at every tier — there's no fixed RPO/RTO for this option; it depends entirely on an architecture you'd have to design and build.
Gotchas
Zone redundancy is a one-time, environment-creation-only choice
You can't enable zone redundancy on an existing Container Apps environment, and once enabled you can't disable it either. Getting this wrong in production means standing up a new environment and redeploying every app into it — not a setting you can flip later.
The SLA never changes — zone redundancy buys resilience, not a better number
99.95% is the SLA whether or not zone redundancy is enabled. Don't treat the SLA percentage as evidence zone redundancy is actually configured — check the environment setting directly.
Container Apps holds no durable state of its own
It's a stateless container host — any data an app needs to survive a replica loss must live in an external service (Azure Files on ZRS, Cosmos DB, Azure SQL, etc.). Every RPO claim about a Container Apps deployment is really a claim about whatever's behind it.