Bird
Raised Fist0
Azurecloud~10 mins

Multi-region deployment patterns in Azure - Commands & Configuration

Choose your learning style10 modes available
LearnWhyDeepVisualTryChallengeProjectRecallTime

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Introduction
Deploying applications in multiple regions helps keep them running even if one region has problems. It also makes apps faster for users far away by placing copies closer to them.
When you want your app to stay online even if one data center fails.
When users are spread across different continents and need fast access.
When you want to meet legal rules that require data to stay in certain countries.
When you want to balance traffic so no single region gets overloaded.
When you want to reduce delays by serving users from the nearest location.
Config File - main.bicep
main.bicep
param location1 string = 'eastus'
param location2 string = 'westeurope'

resource appServicePlan1 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: 'myAppServicePlanEastUS'
  location: location1
  sku: {
    name: 'P1v2'
    tier: 'PremiumV2'
  }
}

resource appServicePlan2 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: 'myAppServicePlanWestEurope'
  location: location2
  sku: {
    name: 'P1v2'
    tier: 'PremiumV2'
  }
}

resource webApp1 'Microsoft.Web/sites@2022-03-01' = {
  name: 'myWebAppEastUS'
  location: location1
  properties: {
    serverFarmId: appServicePlan1.id
  }
}

resource webApp2 'Microsoft.Web/sites@2022-03-01' = {
  name: 'myWebAppWestEurope'
  location: location2
  properties: {
    serverFarmId: appServicePlan2.id
  }
}

resource trafficManager 'Microsoft.Network/trafficManagerProfiles@2021-02-01' = {
  name: 'myTrafficManagerProfile'
  location: 'global'
  properties: {
    trafficRoutingMethod: 'Performance'
    dnsConfig: {
      relativeName: 'myapptraffic'
      ttl: 30
    }
    monitorConfig: {
      protocol: 'HTTP'
      port: 80
      path: '/'
    }
    endpoints: [
      {
        name: 'endpointEastUS'
        type: 'Microsoft.Network/trafficManagerProfiles/azureEndpoints'
        properties: {
          targetResourceId: webApp1.id
          endpointStatus: 'Enabled'
          endpointLocation: location1
        }
      }
      {
        name: 'endpointWestEurope'
        type: 'Microsoft.Network/trafficManagerProfiles/azureEndpoints'
        properties: {
          targetResourceId: webApp2.id
          endpointStatus: 'Enabled'
          endpointLocation: location2
        }
      }
    ]
  }
}

This Bicep file creates two App Service plans and web apps in two different Azure regions: East US and West Europe.

It also creates a Traffic Manager profile that routes users to the closest web app based on performance.

The trafficRoutingMethod set to 'Performance' ensures users connect to the fastest endpoint.

The monitorConfig checks app health to avoid sending traffic to unhealthy apps.

Commands
This command deploys the Bicep template to create the multi-region web apps and Traffic Manager profile in the specified resource group.
Terminal
az deployment group create --resource-group myResourceGroup --template-file main.bicep
Expected OutputExpected
{ "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myResourceGroup/providers/Microsoft.Resources/deployments/deploymentName", "name": "deploymentName", "properties": { "provisioningState": "Succeeded", "outputs": {} } }
→
--resource-group - Specifies the Azure resource group to deploy resources into
→
--template-file - Points to the Bicep file with the deployment configuration
This command checks the details of the web app deployed in East US to confirm it is created and running.
Terminal
az webapp show --name myWebAppEastUS --resource-group myResourceGroup
Expected OutputExpected
{ "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myResourceGroup/providers/Microsoft.Web/sites/myWebAppEastUS", "location": "eastus", "name": "myWebAppEastUS", "state": "Running", "type": "Microsoft.Web/sites" }
→
--name - Specifies the name of the web app to show
→
--resource-group - Specifies the resource group where the web app exists
This command shows the Traffic Manager profile details to verify the multi-region routing setup.
Terminal
az network traffic-manager profile show --name myTrafficManagerProfile --resource-group myResourceGroup
Expected OutputExpected
{ "name": "myTrafficManagerProfile", "location": "global", "properties": { "trafficRoutingMethod": "Performance", "dnsConfig": { "relativeName": "myapptraffic", "ttl": 30 }, "endpoints": [ { "name": "endpointEastUS", "properties": { "endpointStatus": "Enabled", "endpointLocation": "eastus" } }, { "name": "endpointWestEurope", "properties": { "endpointStatus": "Enabled", "endpointLocation": "westeurope" } } ] } }
→
--name - Specifies the Traffic Manager profile name
→
--resource-group - Specifies the resource group where the profile exists
Key Concept

If you remember nothing else from this pattern, remember: use Traffic Manager to route users to the closest healthy app instance in different regions for better availability and speed.

Common Mistakes
Deploying apps in multiple regions but not setting up Traffic Manager or DNS routing.
Users will not be directed to the closest or healthy region, losing the benefits of multi-region deployment.
Always configure Traffic Manager or a similar routing service to manage user traffic across regions.
Not monitoring app health in Traffic Manager configuration.
Traffic Manager may send users to an app instance that is down, causing errors.
Set up health probes in Traffic Manager to check app status and avoid routing to unhealthy endpoints.
Using the same app name in different regions without unique names.
Azure requires unique names for web apps, so deployment will fail or overwrite.
Use unique names for each regional app instance.
Summary
Deploy web apps in multiple Azure regions using App Service plans.
Use Azure Traffic Manager with performance routing to direct users to the closest healthy app.
Verify deployments and routing setup with Azure CLI commands.

Practice

(1/5)
1. What is the main benefit of deploying an application in multiple Azure regions?
easy
A. Improves application speed and availability worldwide
B. Reduces the cost of Azure services
C. Simplifies the application code
D. Limits the number of users who can access the app

Solution

  1. Step 1: Understand multi-region deployment purpose

    Deploying in multiple regions helps serve users faster by placing resources closer to them.

  2. Step 2: Identify the key benefit

    This setup also increases availability by providing backups if one region fails.

  3. Final Answer:

    Improves application speed and availability worldwide -> Option A

  4. Quick Check:

    Multi-region deployment = better speed and availability [OK]
Hint: Think about user experience worldwide for multi-region [OK]
Common Mistakes:
  • Confusing cost reduction with performance improvement
  • Assuming code changes are needed for multi-region
  • Believing multi-region limits users
2. Which Azure service is used to route users automatically to the best performing region?
easy
A. Azure Traffic Manager
B. Azure Blob Storage
C. Azure Virtual Network
D. Azure Functions

Solution

  1. Step 1: Identify routing service for multi-region

    Azure Traffic Manager directs user requests to the fastest or healthiest region.

  2. Step 2: Exclude unrelated services

    Blob Storage stores data, Virtual Network manages networking, Functions run code; none route traffic.

  3. Final Answer:

    Azure Traffic Manager -> Option A

  4. Quick Check:

    Traffic Manager routes users to best region [OK]
Hint: Traffic Manager controls user routing in multi-region setups [OK]
Common Mistakes:
  • Choosing storage or compute services instead of routing
  • Confusing Virtual Network with Traffic Manager
  • Assuming Functions handle traffic routing
3. Given this Azure Traffic Manager profile configuration snippet:
{
  "name": "myTrafficManager",
  "type": "Microsoft.Network/trafficManagerProfiles",
  "properties": {
    "trafficRoutingMethod": "Performance",
    "endpoints": [
      {"name": "eastUS", "type": "Microsoft.Network/trafficManagerProfiles/azureEndpoints", "properties": {"targetResourceId": "/subscriptions/.../eastUSApp"}},
      {"name": "westEurope", "type": "Microsoft.Network/trafficManagerProfiles/azureEndpoints", "properties": {"targetResourceId": "/subscriptions/.../westEuropeApp"}}
    ]
  }
}

What does the Performance routing method do?
medium
A. Routes users to the endpoint with the highest CPU usage
B. Routes users randomly to any endpoint
C. Routes users to the endpoint with the oldest deployment
D. Routes users to the endpoint with the lowest network latency

Solution

  1. Step 1: Understand Performance routing method

    Performance routing sends users to the endpoint with the lowest network latency for faster response.

  2. Step 2: Eliminate incorrect options

    Random routing is 'Weighted' or 'Priority', CPU usage and deployment age are not routing criteria.

  3. Final Answer:

    Routes users to the endpoint with the lowest network latency -> Option D

  4. Quick Check:

    Performance routing = lowest latency endpoint [OK]
Hint: Performance routing means fastest response endpoint [OK]
Common Mistakes:
  • Confusing Performance with random or priority routing
  • Thinking CPU usage affects routing
  • Assuming deployment age affects routing
4. You deployed your app in two Azure regions but users report slow failover when one region goes down. What is the most likely cause?
medium
A. You used Performance routing with health probes enabled
B. Azure Traffic Manager is set to Priority routing but no health probes are configured
C. You deployed the app only in one region
D. Azure Traffic Manager is disabled

Solution

  1. Step 1: Analyze failover issue with Priority routing

    Priority routing requires health probes to detect endpoint health and failover quickly.

  2. Step 2: Identify missing health probes impact

    Without health probes, Traffic Manager cannot detect failure and delays failover.

  3. Final Answer:

    Azure Traffic Manager is set to Priority routing but no health probes are configured -> Option B

  4. Quick Check:

    Priority routing needs health probes for fast failover [OK]
Hint: Priority routing needs health probes to detect failures [OK]
Common Mistakes:
  • Assuming Performance routing causes slow failover
  • Thinking single-region deployment causes failover delay
  • Ignoring health probe configuration
5. You want to deploy a global web app with low latency and high availability. Which multi-region deployment pattern should you choose in Azure to achieve this?
hard
A. Deploy app in one region and rely on Azure Virtual Network peering
B. Deploy app in one region and use Azure CDN only
C. Deploy app instances in multiple regions and use Azure Traffic Manager with Performance routing
D. Deploy app in multiple regions but disable Traffic Manager

Solution

  1. Step 1: Identify deployment for low latency and high availability

    Deploying app instances in multiple regions places resources closer to users and provides redundancy.

  2. Step 2: Use Azure Traffic Manager with Performance routing

    This routes users to the fastest region automatically, improving speed and availability.

  3. Step 3: Exclude less effective options

    Single region with CDN or VNet peering does not provide true multi-region failover or latency benefits; disabling Traffic Manager prevents routing.

  4. Final Answer:

    Deploy app instances in multiple regions and use Azure Traffic Manager with Performance routing -> Option C

  5. Quick Check:

    Multi-region + Traffic Manager Performance = best global deployment [OK]
Hint: Combine multi-region deployment with Traffic Manager Performance routing [OK]
Common Mistakes:
  • Relying on CDN alone for global app availability
  • Disabling Traffic Manager in multi-region setup
  • Using single region for global low latency