Availability and Resilience¶
What happens to integration workloads when an availability zone fails, which Azure services they depend on, and what availability you can expect from the patterns you build. This page condenses the availability analysis of the reference design (single region, January 2026). Use it to design your integration and to set realistic objectives.
Reference analysis, not a promise
The figures are theoretical, calculated from the availability commitments Microsoft publishes. They change when Microsoft changes them or when your configuration differs from the reference design. Actual availability is typically higher. They are not the service levels of your agreement. Re-check the Microsoft figures before you use them in a commitment.
Summary¶
| Area | Status in the reference design |
|---|---|
| Landing zone components (virtual WAN, DNS resolver, firewall, application gateway, Key Vault, spoke storage) | Zone-redundant when configured. A spoke storage account defaults to locally redundant storage when no redundancy is configured. The management storage account of the platform is locally redundant, which is not a runtime dependency. |
| Service Bus, Event Hubs | Zone-redundant by default |
| Container Apps environment | Zone redundancy on by default when not set |
| Function App plan | Zone balancing is enabled automatically for the elastic premium, Flex Consumption and premium plans. The worker count defaults to 2. |
| Logic App plan | Zone-balanced with the workflow plan sizes (WS1, WS2, WS3) |
| Logic App storage | The storage account that is deployed with the Logic App defaults to zone-redundant storage |
| Container registry | Zone redundancy is switched off. An outage of the zone with the registry can block image pulls. |
A single zone failure leaves the zone-redundant components working. The weak spot is the container registry, which affects Container Apps and Container Jobs.
Runtime dependencies¶
| Integration component | Storage | Key Vault | Container registry | Application Insights | Log Analytics |
|---|---|---|---|---|---|
| Logic App | Critical (dedicated account) | Optional (secrets) | Not critical | Not critical | |
| Function App | Critical (spoke account) | Critical (secrets) | Not critical | Not critical | |
| Container App | Critical (data access) | Critical (secrets) | Critical (image pull) | Not critical | Not critical |
| Container Job | Critical (event triggers) | Critical (secrets) | Critical (image pull) | Not critical | Not critical |
| API Management | None | Optional (certificates, secrets) | Not critical | Not critical | |
| Data Factory | Critical (data source and sink) | Critical (linked services) | Not critical | Not critical |
Critical: the component fails if the dependency is unavailable. Optional: works with reduced capability. Not critical: only observability is degraded.
Composite availability per pattern¶
A pattern depends on a chain of services. The composite availability is the product of the availability of every service in the chain, including the landing zone services (virtual WAN, private DNS, firewall, application gateway) and the critical dependencies above.
| Integration pattern | Composite availability | Monthly downtime budget |
|---|---|---|
| REST API on a Function App | 99.67% | about 2.4 hours |
| REST API on a Logic App | 99.62% | about 2.8 hours |
| REST API on a Container App | 99.57% | about 3.1 hours |
| Event-driven processing with a Function App | 99.76% | about 1.8 hours |
| Service Bus queue message processing with a Container Job | 99.57% | about 3.1 hours |
| Data Factory ETL | 99.72% | about 2.0 hours |
Every extra service in the chain lowers the composite figure.
Recommendations¶
The analysis names these actions, in order of value for effort:
- Enable zone redundancy on the container registry. It removes the registry as the limiting factor of the Container App pattern. It is a configuration change with a modest cost increase.
- Check the redundancy of the management storage account of the platform, and upgrade it when data loss would matter.
- Reduce dependencies in your design. Cache values to limit Key Vault calls, pool connections to limit storage operations.
- Retry. Use retries with back-off. Service Bus clients have retry built in. For HTTP calls use a resilience library.
- Use the higher tiers where a better guarantee matters, for example Premium for Event Hubs and Service Bus.
Multi-region¶
A second region is a strategic decision, not a default. In the analysis, regional outages in the region happen about once a year and last about six hours. Multi-region designs are complex (active-passive or active-active) and cost roughly 1.5 to 2 times as much. Several services have built-in options (storage with read-access geo-zone-redundancy, Key Vault automatic replication, Service Bus and Event Hubs geo-replication on Premium, registry geo-replication on Premium), but even with all of them the composite figures improve only slightly in the analysis. For most integration workloads a zone-redundant single-region deployment with good retry logic and graceful degradation gives enough availability for the cost. Consider multi-region for mission-critical workloads that need more than about 99.9%. It is also not an option when the landing zone runs in one region only.
Disaster recovery¶
The platform follows the MCP: one region, availability zones, and redeployment from code in another region. The reference design names a recovery time objective of 24 hours and a recovery point objective of 48 hours, which can be met because the platform and workloads that only use platform modules can be redeployed within hours. Both values are set per platform (Architecture).
Backup¶
The Integration Platform itself does not permanently store data, and its configuration is code in a Git repository. Your integrations can store state, for example Function Apps and Logic Apps keep state in a storage account. Backup of that is your decision: either specific to your workload or part of a backup solution for all workloads on the platform. A backup solution for workloads is not part of the MCP landing zone by default.
What you can do as a workload team¶
- Choose the redundancy of the plans and replicas you configure: replicas of a Container App, instances of a Logic App plan. For a zone-balanced plan keep the minimum instance count a multiple of the number of zones in the region.
- Design for the dependency chain: know which services your pattern needs.
- Add retries and a health check to your integration.
- Decide what must survive a regional outage, and tell your platform team early (Operate your workload).