Reliability in Azure Container Apps
This article describes reliability support in Azure Container Apps, and covers both regional resiliency with availability zones and cross-region resiliency with disaster recovery. For a more detailed overview of reliability in Azure, see Azure reliability.
Availability zone support
Azure availability zones are at least three physically separate groups of datacenters within each Azure region. Datacenters within each zone are equipped with independent power, cooling, and networking infrastructure. In the case of a local zone failure, availability zones are designed so that if the one zone is affected, regional services, capacity, and high availability are supported by the remaining two zones.
Failures can range from software and hardware failures to events such as earthquakes, floods, and fires. Tolerance to failures is achieved with redundancy and logical isolation of Azure services. For more detailed information on availability zones in Azure, see Regions and availability zones.
Azure availability zones-enabled services are designed to provide the right level of reliability and flexibility. They can be configured in two ways. They can be either zone redundant, with automatic replication across zones, or zonal, with instances pinned to a specific zone. You can also combine these approaches. For more information on zonal vs. zone-redundant architecture, see Recommendations for using availability zones and regions.
Azure Container Apps uses availability zones in regions where they're available to provide high-availability protection for your applications and data from data center failures.
By enabling Container Apps' zone redundancy feature, replicas are automatically distributed across the zones in the region. Traffic is load balanced among the replicas. If a zone outage occurs, traffic is automatically routed to the replicas in the remaining zones.
Note
There is no extra charge for enabling zone redundancy, but it only provides benefits when you have 2 or more replicas, with 3 or more being ideal since most regions that support zone redundancy have 3 zones.
Prerequisites
Azure Container Apps offers the same reliability support regardless of your plan type.
Azure Container Apps uses availability zones in regions where they're available. For a list of regions that support availability zones, see Availability zone service and regional support.
SLA improvements
There are no increased SLAs for Azure Container Apps. For more information on the Azure Container Apps SLAs, see Service Level Agreement for Azure Container Apps.
Create a resource with availability zone enabled
Set up zone redundancy in your Container Apps environment
To take advantage of availability zones, you must enable zone redundancy when you create a Container Apps environment. The environment must include a virtual network with an available subnet. To ensure proper distribution of replicas, set your app's minimum replica count to three.
Enable zone redundancy via the Azure portal
To create a container app in an environment with zone redundancy enabled using the Azure portal:
- Navigate to the Azure portal.
- Search for Container Apps in the top search box.
- Select Container Apps.
- Select Create New in the Container Apps Environment field to open the Create Container Apps Environment panel.
- Enter the environment name.
- Select Enabled for the Zone redundancy field.
Zone redundancy requires a virtual network with an infrastructure subnet. You can choose an existing virtual network or create a new one. When creating a new virtual network, you can accept the values provided for you or customize the settings.
- Select the Networking tab.
- To assign a custom virtual network name, select Create New in the Virtual Network field.
- To assign a custom infrastructure subnet name, select Create New in the Infrastructure subnet field.
- You can select Internal or External for the Virtual IP.
- Select Create.
Enable zone redundancy with the Azure CLI
Create a virtual network and infrastructure subnet to include with the Container Apps environment.
When using these commands, replace the <PLACEHOLDERS> with your values.
Note
The Consumption only environment requires a dedicated subnet with a CIDR range of /23 or larger. The workload profiles environment requires a dedicated subnet with a CIDR range of /27 or larger. To learn more about subnet sizing, see the networking architecture overview.
az network vnet create \
--resource-group <RESOURCE_GROUP_NAME> \
--name <VNET_NAME> \
--location <LOCATION> \
--address-prefix 10.0.0.0/16
az network vnet subnet create \
--resource-group <RESOURCE_GROUP_NAME> \
--vnet-name <VNET_NAME> \
--name infrastructure \
--address-prefixes 10.0.0.0/21
Next, query for the infrastructure subnet ID.
INFRASTRUCTURE_SUBNET=`az network vnet subnet show --resource-group <RESOURCE_GROUP_NAME> --vnet-name <VNET_NAME> --name infrastructure --query "id" -o tsv | tr -d '[:space:]'`
Finally, create the environment with the --zone-redundant parameter. The location must be the same location used when creating the virtual network.
az containerapp env create \
--name <CONTAINER_APP_ENV_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--location "<LOCATION>" \
--infrastructure-subnet-resource-id $INFRASTRUCTURE_SUBNET \
--zone-redundant
Verify zone redundancy with the Azure CLI
Note
The Azure Portal does not show whether zone redundancy is enabled.
Use the az container app env show command to verify zone redundancy is enabled for your Container Apps environment.
az containerapp env show \
--name <CONTAINER_APP_ENV_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--subscription <SUBSCRIPTION_ID>
The command returns a JSON response. Verify the response contains "zoneRedundant": true.
Safe deployment techniques
When you set up zone redundancy in your container app, replicas are distributed automatically across the zones in the region. After the replicas are distributed, traffic is load balanced among them. If a zone outage occurs, traffic automatically routes to the replicas in the remaining zone.
You should still use safe deployment techniques such as blue-green deployment. Azure Container Apps doesn't provide one-zone-at-a-time deployment or upgrades.
If you have enabled session affinity, and a zone goes down, clients for that zone are routed to new replicas because the previous replicas are no longer available. Any state associated with the previous replicas is lost.
Availability zone migration
To take advantage of availability zones, enable zone redundancy as you create the Container Apps environment. The environment must include a virtual network with an available subnet. You can't migrate an existing Container Apps environment from nonavailability zone support to availability zone support.
Cross-region disaster recovery and business continuity
Disaster recovery (DR) is about recovering from high-impact events, such as natural disasters or failed deployments that result in downtime and data loss. Regardless of the cause, the best remedy for a disaster is a well-defined and tested DR plan and an application design that actively supports DR. Before you begin to think about creating your disaster recovery plan, see Recommendations for designing a disaster recovery strategy.
When it comes to DR, Microsoft uses the shared responsibility model. In a shared responsibility model, Microsoft ensures that the baseline infrastructure and platform services are available. At the same time, many Azure services don't automatically replicate data or fall back from a failed region to cross-replicate to another enabled region. For those services, you are responsible for setting up a disaster recovery plan that works for your workload. Most services that run on Azure platform as a service (PaaS) offerings provide features and guidance to support DR and you can use service-specific features to support fast recovery to help develop your DR plan.
In the unlikely event of a full region outage, you have the option of using one of two strategies:
Manual recovery: Manually deploy to a new region, or wait for the region to recover, and then manually redeploy all environments and apps.
Resilient recovery: First, deploy your container apps in advance to multiple regions. Next, use Azure Front Door or Azure Traffic Manager to handle incoming requests, pointing traffic to your primary region. Then, should an outage occur, you can redirect traffic away from the affected region. For more information, see Cross-region replication in Azure.
Note
Regardless of which strategy you choose, make sure your deployment configuration files are in source control so you can easily redeploy if necessary.
More guidance
The following resources can help you create your own disaster recovery plan: