Azure Container Apps - avoid downtime caused by Microsoft Maintenance

Hi nico,
Welcome to the Microsoft Q&A Platform! Thank you for asking your question here. As per the reference document, Replica quantities are a target amount, not a guarantee. Azure Container Apps run on a fully managed control plane plus underlying node pools that Microsoft updates and patches during scheduled maintenance. Even with zone redundancy and multiple replicas, when the platform vacates or reboots nodes to apply updates, there can be a short period where no healthy host is available for scheduling or rescheduling your replica (assigningReplicaFailed). Currently, Azure Maintenance Control (AMC) supports VMs, VM Scale Sets, and Dedicated Hosts, but not Container Apps directly, so you cannot shift maintenance timing or orchestrate rolling updates at the Container Apps layer itself.

Suggestions:

1. Evaluate whether multi-region active/active or active/passive deployment is required for zero-downtime:
   • Deploy a second Container Apps environment in a secondary Azure region.
   • Use Azure Front Door or Azure Traffic Manager to route traffic and fail over between regions.
2. If you prefer a single-region solution but need granular maintenance control:
   • Consider migrating to Azure Kubernetes Service (AKS) or to VMSS-backed workloads where AMC can orchestrate node drain and rolling updates.
   • On AKS you can register the Maintenance Resource Provider, assign maintenance configurations to node pools, and leverage “kubectl drain” as part of your update process.
3. Improve readiness/failover responsiveness:
   • Add readiness probes in your Container Apps to ensure only healthy containers receive traffic.
   • Increase minimum replica count to 3+ if your budget and quotas allow, further smoothing out brief unavailability windows.
4. Deploy multi-region failover (recommended for strict zero downtime):
   • Create a secondary Container Apps environment in a paired region.
   • Deploy identical container apps (same image, configuration, secrets).
   • Provision an Azure Front Door (or Traffic Manager) profile in “Priority” (active-passive) or “Weighted” (active-active) mode with backends pointing to each environment’s ingress FQDN.
   • Configure health probes on Front Door/Traffic Manager to detect real downtime and seamlessly fail over.

Examples

Active-Passive failover with Azure Front Door:

• Primary backend: westus3 container app FQDN
• Secondary backend: eastus container app FQDN
• Priority label: Primary=1, Secondary=2
• Health probe path: /health (mapped to your container app readiness endpoint)

Code Snippets

Azure CLI to create Front Door and add backends:

az network front-door create \
--resource-group MyRG \
--name MyFDP \
--backend-address westus3-myapp.azurecontainerapps.io

az network front-door backend-pool backend add \
--resource-group MyRG \
--front-door-name MyFDP \
--pool-name default \
--address eastus-myapp.azurecontainerapps.io \
--priority 2 \
--weight 50

az network front-door routing-rule create \
--resource-group MyRG \
--front-door-name MyFDP \
--name routeAll \
--frontend-endpoints default \
--accepted-protocols Http Https \
--patterns-to-match '/*' \
--route-type Forward \
--backend-pool default

Enable health probe:

az network front-door health-probe create \
--resource-group MyRG \
--front-door-name MyFDP \
--name appProbe \
--path /health \
--protocol Https \
--interval 30

Additional Information

• Performance implications: front-door routing adds minimal latency (~10–20 ms).
• Costs: additional regional environments and Azure Front Door/TM charges.
• Best practices: implement health/readiness probes, use blue-green or canary releases within Container Apps for app-level resiliency.
• Alternative: migrate to AKS node pools with Maintenance Control for in-region zero-downtime maintenance scheduling.
• Prerequisites: proper RBAC rights for Front Door, DNS CNAME to Front Door endpoint, quotas for multi-region environments.

References

• Reducing cold-start time on Azure Container Apps
• Health probes in Azure Container Apps
• Create a private link to an Azure Container App with Azure Front Door
• Update and deploy changes in Azure Container Apps

Hi @nico , following up to see if you have a chance to check my previous response and if it was helpful. Do let me know if you have any further questions on this.

Dear @Rakesh Mishra - thanks a lot for your reply.

a) If i read you correctly are you basically suggesting that we either:

1. Should do multi-region deployments with Azure Front Door or
2. Migrate to AKS

i.e. in both cases use solutions with significantly increased costs and/or complexity, and there is no possibility to ensure zero downtime in a single region dedicated work profile ACA environment?

b) I am not sure how i should read 'Increase minimum replica count to 3+ (...) further smoothing out brief unavailability windows.' - this sounds very unspecific.

c) We are already using readiness probes for our apps (on startup, we are seeing system logs suggesting port mismatches as we are not using the same port for the probes as for normal ingress - might this be another issue?). We currently only have minimum node count at 1 - will it help to increase that?

d) Also we have experienced short downtimes in the last days outside of our maintenance window - why is that?

Thanks in advance!

Hi nico, please find below and let me know if you have any questions.

a) Is zero-downtime in a single-region ACA environment impossible without multi-region or AKS?

Yes. Azure Container Apps (ACA) is a fully managed, serverless container platform. Under the covers, Microsoft may cordon and reboot entire host nodes (for critical security patches or infrastructure updates) outside of your chosen maintenance window. During those brief node-eviction cycles, there’s no built-in “rolling upgrade” of the underlying nodes within a single-region ACA environment. As a result:

• Multi-region with Azure Front Door or AKS with Maintenance Control are the only supported patterns for true single-region zero-downtime.
  • Multi-region + Front Door gives you an active-active or active-passive failover across regions.
  • AKS Maintenance Control lets you orchestrate node-by-node draining/upgrade yourself.

b) “Increase minimum replica count to 3+”—what does that actually mean?

When you configure your Container App’s minReplicas, you’re telling ACA how many container instances to keep warm at all times. In a zone-redundant environment (three AZs), setting means ACA will keep at least one replica in each of the three availability zones. If one zone’s node goes down for patching, you still have replicas in the other two zones serving traffic, so your overall service remains up. Without three replicas spread across zones, you risk all your instances being evicted simultaneously when that zone is drained.

Reference: Availability zone support

c) Readiness-probe port mismatch and bumping your min-node count from 1

1. Readiness probe port mismatch:
   • Your probe must target the same port that your app actually listens on, or else each new replica will be marked “NotReady” and never receive live traffic. Check the port: in your probe YAML against the container’s ports[].port setting.
   • Reference: Health probes in Azure Container Apps
2. Min node count = 1:
   • With one node, if that node is cordoned (for patching) or suffers an infrastructure issue, all replicas go down together—even if you have minReplicas > 1. The ACA control plane then schedules new replicas elsewhere, but traffic will briefly fail.

d) Why downtimes outside of your maintenance window?

Even with a maintenance window set, ACA still reserves the right to apply critical security patches or platform fixes outside your window. Additionally:

• Underlying host failures or unexpected hardware/network issues can trigger forced re-scheduling of your containers on new hosts.
• Control-plane updates may also briefly pause scheduling while rolling through the pool.

Since ACA is fully managed model, you won’t see those events surfaced as “planned maintenance" - they just show up as a short lapse in your app’s availability.

Thanks for the clarification @Rakesh Mishra !

Another follow-up: If i read you correctly you are saying that:

• a) in one region with zone-redundancy, min node count 2, min replica 2 these outages should be less
• b) in one region with zone-redundancy, min node count 3, min replica 3 these outages should be even more less (what does this mean in actual figures?)
• c) but a) and b) still do not garantuee anything, only multi-region deployments (ACA) or AKS can guarantee zero-downtime?

Thanks in advance!