Skip to content

Multi-Region Deployment

Use this runbook when the workload needs a cross-region pattern rather than a single regional environment.

Prerequisites

  • Two approved Azure regions
  • Repeatable Bicep or ARM for both environments
  • A global routing layer selected before cutover
export PRIMARY_LOCATION="eastus"
export SECONDARY_LOCATION="centralus"
export PRIMARY_ENVIRONMENT_NAME="aca-env-prod-eastus"
export SECONDARY_ENVIRONMENT_NAME="aca-env-prod-centralus"

When to Use

  • When zone redundancy is not sufficient
  • When you need active-passive or active-active traffic management
  • When you need a repeatable regional failover drill

Procedure

  1. Deploy the Container Apps environment in the primary region.
  2. Deploy the same environment pattern in the secondary region.
  3. Deploy matching app revisions, secrets, ingress, and scale configuration to both regions.
  4. Add both regions to Azure Front Door or Traffic Manager.
  5. Configure health probes and routing policy.
  6. Publish DNS to the global endpoint.

Minimal Bicep placeholder for dual-region composition:

param primaryLocation string = 'eastus'
param secondaryLocation string = 'centralus'

// Deploy one managed environment and one container app per region.
// Add global routing in Front Door or Traffic Manager separately.

Front Door probe-path conventions remain app-specific

Microsoft Learn verifies the multi-region pattern itself: Container Apps is single-region, and multi-region resiliency uses separate regional environments plus Azure Front Door or Azure Traffic Manager. Microsoft Learn also documents that Front Door origin groups use periodic HTTP/HTTPS health probes. However, the cited Container Apps and Front Door pages do not prescribe one origin layout specific to Container Apps or canonical probe path, so keep those details app-specific and validate failover behavior before standardizing them.

flowchart TD
    A[Deploy primary region] --> B[Deploy secondary region]
    B --> C[Apply matching app config]
    C --> D[Configure global routing]
    D --> E[Publish DNS]
    E --> F[Run failover test]

Verification

  • Confirm both regional endpoints are healthy.
  • Confirm the global endpoint routes to a healthy region.
  • Confirm a simulated regional failure removes the failed origin from traffic.

Rollback / Troubleshooting

  • If regions drift, compare environment settings, secrets, and revision config side by side.
  • If failover does not occur, inspect the health probe path and routing policy.
  • If DNS was changed manually, wait for TTL before declaring the cutover failed.

Review Matrix

Review area Page-specific check
Scope Confirm the guidance applies to Multi-Region Deployment.
Source basis Validate the recommendation against the Microsoft Learn sources in this page.
Evidence Capture command output, portal state, metrics, logs, or screenshots before treating the result as proven.

See Also

Sources