Overview:
High availability and fault tolerance are crucial for a well-architected web application. Deploying an application across multiple regions can significantly reduce downtime and maintain service continuity in case of regional outages. This post guides you through creating a highly available multi-region web app using Azure App Service and Azure Front Door.
Key Steps:
- Create Two Instances of a Web App: Set up identical web apps in separate Azure regions. This ensures that if one region goes down, the other can continue serving users.
- Configure Azure Front Door: Use Azure Front Door to manage traffic routing to your web apps. It acts as a global load balancer, directing user requests to the primary region and, if necessary, to the secondary region.
- Implement Access Restrictions: Secure your web apps by blocking direct public access. Only Azure Front Door should be able to route traffic to these apps.
- Testing: Verify the setup by testing Azure Front Door’s routing capabilities and ensuring that failover to the secondary region works as expected.
Routing architecture overview
Azure Front Door traffic routing takes place over multiple stages. First, traffic is routed from the client to the Front Door. Then, Front Door uses your configuration to determine the origin to send the traffic to. The Front Door web application firewall, routing rules, rules engine, and caching configuration can all affect the routing process.
The following diagram illustrates the routing architecture:
Architecture – Create a highly available multi-region app in Azure App Service
In this post, we will explore how to deploy a highly available multi-region web app. This scenario is kept simple by restricting the application components to just a web app and Azure Front Door, but the concepts can be expanded and applied to other infrastructure patterns.
For example, if your application connects to an Azure database offering or storage account, see active geo-replication for SQL databases and redundancy options for storage accounts.
For a reference architecture for a more detailed scenario, see Highly available multi-region web application.
With this architecture:
- Identical App Service apps are deployed in two separate regions.
- Public traffic directly to the App Service apps is blocked.
- Azure Front Door is used route traffic to the primary/active region. The secondary region has an App Service that’s up and running and ready to serve traffic if needed.
Demo (Summary):
Below are the steps covered in below section.
- Create two instances of a web app
- Create App Service plans
- Create an Azure Front Door
- Create an Azure Front Door profile
- Add an endpoint
- Create an origin group
- Add an origin to the group
- Add a route
- Restrict access to web apps to the Azure Front Door instance
- Test the Front Door
Prerequisites
Azure CLI
Demo(Step-by-step)
A. Create two Instances of a Web App
Create two instances of a web app
You need two instances of a web app that run in different Azure regions for this tutorial. You use the region pair East US/West US as your two regions and create two empty web apps
az group create --name myresourcegroup --location eastusCreate App Service plans
Run the following commands to create the App Service plans. Replace the placeholders for <app-service-plan-east-us> and <app-service-plan-west-us> with two unique names where you can easily identify the region they’re in.
az appservice plan create --name <app-service-plan-east-us> --resource-group myresourcegroup --is-linux --location eastus
az appservice plan create --name <app-service-plan-west-us> --resource-group myresourcegroup --is-linux --location westus
Create web apps
Once the App Service plans are created, run the following commands to create the web apps.
az webapp create --name <web-app-east-us> --resource-group myresourcegroup --plan <app-service-plan-east-us> --runtime <runtime>
az webapp create --name <web-app-west-us> --resource-group myresourcegroup --plan <app-service-plan-west-us> --runtime <runtime>B. Configure Azure Front Door
Create an Azure Front Door
A multi-region deployment can use an active-active or active-passive configuration. An active-active configuration distributes requests across multiple active regions. An active-passive configuration keeps running instances in the secondary region, but doesn’t send traffic there unless the primary region fails. Azure Front Door has a built-in feature that allows you to enable these configurations. For more information on designing apps for high availability and fault tolerance, see Architect Azure applications for resiliency and availability.
How to deploy a highly available multi-region web app – Azure App Service
Create an Azure Front Door profile
You now create an Azure Front Door Premium to route traffic to your apps.
Run az afd profile create to create an Azure Front Door profile.
az afd profile create --profile-name myfrontdoorprofile --resource-group myresourcegroup --sku Premium_AzureFrontDoorAdd an endpoint
Run az afd endpoint create to create an endpoint in your profile. You can create multiple endpoints in your profile after finishing the create experience.
az afd endpoint create --resource-group myresourcegroup --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabledfrontdoordemo-b7erfsescedxc8e9.z03.azurefd.net
frontdoordemo-b7erfsescedxc8e9.z03.azurefd.net
Create an origin group
Run az afd origin-group create to create an origin group that contains your two web apps.
az afd origin-group create --resource-group myresourcegroup --origin-group-name myorigingroup --profile-name myfrontdoorprofile --probe-request-type GET --probe-protocol Http --probe-interval-in-seconds 60 --probe-path / --sample-size 4 --successful-samples-required 3 --additional-latency-in-milliseconds 50
Add an origin to the group
Run az afd origin create to add an origin to your origin group. For the --host-name parameter, replace the placeholder for <web-app-east-us> with your app name in that region. Notice the --priority parameter is set to 1, which indicates all traffic is sent to your primary app.
az afd origin create --resource-group myresourcegroup --host-name <web-app-east-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name primaryapp --origin-host-header <web-app-east-us>.azurewebsites.net --priority 1 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443
Add a route
Run az afd route create to map your endpoint to the origin group. This route forwards requests from the endpoint to your origin group.
az afd route create --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --forwarding-protocol MatchRequest --route-name route --https-redirect Enabled --origin-group myorigingroup --supported-protocols Http Https --link-to-default-domain Enabled| Setting | Description |
| Name | Enter a name to identify the mapping between domains and origin group. |
| Domains | A domain name has been auto-generated for you to use. If you want to add a custom domain, select Add a new domain. This example will use the default. |
| Patterns to match | Set all the URLs this route will accept. This example will use the default, and accept all URL paths. |
| Accepted protocols | Select the protocol the route will accept. This example will accept both HTTP and HTTPS requests. |
| Redirect | Enable this setting to redirect all HTTP traffic to the HTTPS endpoint. |
| Origin group | Select Add a new origin group. For the origin group name, enter myOriginGroup. Then select + Add an origin. For the first origin (primary region), enter the name of one of the web apps you’re using for this tutorial for the Name and then for the Origin Type select App Services. For the Host name, select the hostname you queried/found in the portal earlier. Leave the rest of the default values the same. Select Add to add the origin to the origin group. Repeat the steps to add the second web app as an origin, however when adding the second origin, set the Priority to “2”. This will direct all traffic to the primary origin unless the primary goes down. Once both web app origins have been added, select Add to save the origin group configuration. |
| Origin path | Leave blank. |
| Forwarding protocol | Select the protocol that will be forwarded to the origin group. This example will match the incoming requests to origins. |
| Caching | Select the check box if you want to cache contents closer to your users globally using Azure Front Door’s edge POPs and the Microsoft network. |
| Rules | Once you’ve deployed the Azure Front Door profile, you can configure Rules to apply to your route. |
https://azure.github.io/AppService/2022/12/02/multi-region-web-app.html#front-door-configuration
Create a Front Door Profile
Add Security Policy
Front Door Profile
Validate urls
https://frontdoordemo-b7erfsescedxc8e9.z03.azurefd.net
web-app-east-us.azurewebsites.net
web-app-west-us.azurewebsites.net
You are able to access both the URLs, we will now restrict these URL and see how can we access the app only using Front door.
C. Access Restriction implementation
Restrict access to web apps to the Azure Front Door instance.
Traffic from Azure Front Door to your application originates from a well known set of IP ranges defined in the AzureFrontDoor.
Backend service tag. By using a service tag restriction rule, you can restrict traffic to only originate from Azure Front Door.
From <https://azure.github.io/AppService/2022/12/02/multi-region-web-app.html#front-door-configuration>
Front Door’s features work best when traffic only flows through Front Door. You should configure your origin to block traffic that hasn’t been sent through Front Door. Otherwise, traffic might bypass Front Door’s web application firewall, DDoS protection, and other security features.
Front Door provides several approaches that you can use to restrict your origin traffic.
| Private Link origins | When you use the premium SKU of Front Door, you can use Private Link to send traffic to your origin. From <https://learn.microsoft.com/en-us/azure/frontdoor/origin-security?tabs=app-service-functions&pivots=front-door-standard-premium> |
| Public IP address-based origins | When you use public IP address-based origins, there are two approaches you should use together to ensure that traffic flows through your Front Door instance: Configure IP address filtering to ensure that requests to your origin are only accepted from the Front Door IP address ranges. Configure your application to verify the X-Azure-FDID header value, which Front Door attaches to all requests to the origin, and ensure that its value matches your Front Door’s identifier. From <https://learn.microsoft.com/en-us/azure/frontdoor/origin-security?tabs=app-service-functions&pivots=front-door-standard-premium> |
| IP address filtering | Configure IP address filtering for your origins to accept traffic from Azure Front Door’s backend IP address space and Azure’s infrastructure services only. The AzureFrontDoor.Backend service tag provides a list of the IP addresses that Front Door uses to connect to your origins. You can use this service tag within your network security group rules. You can also download the Azure IP Ranges and Service Tags data set, which is updated regularly with the latest IP addresses. From <https://learn.microsoft.com/en-us/azure/frontdoor/origin-security?tabs=app-service-functions&pivots=front-door-standard-premium> |
| Front Door identifier | IP address filtering alone isn’t sufficient to secure traffic to your origin, because other Azure customers use the same IP addresses. You should also configure your origin to ensure that traffic has originated from your Front Door profile. Azure generates a unique identifier for each Front Door profile. You can find the identifier in the Azure portal, by looking for the Front Door ID value in the Overview page of your profile. From <https://learn.microsoft.com/en-us/azure/frontdoor/origin-security?tabs=app-service-functions&pivots=front-door-standard-premium> |
Before setting up the App Service access restriction, take note of the Front Door ID which can be found on the Overview page for the Front Door instance in the Essentials section.
This will be needed to ensure traffic only originates from your specific Front Door instance by further filtering the incoming requests based on the unique http header that your Azure Front Door sends.
For your first web app, navigate to the Access restriction (preview) page.
Front Door ID: 8fa71331-31b1-4e45-a76e-f8ed5564874a
Enable with no access restrictions
Add rule
Access Restrictions
Validate
After Save, it will show as below!
Repeat for Second website!
Test the Front Door
D. Testing
Validate with Frontdoor
Congratulations, your apps can only be reached through Azure Front Door!
Clean up Resources:
Conclusion
Deploying a multi-region web app on Azure App Service with Azure Front Door enhances your application’s resilience and availability. By following the steps outlined in the tutorial, you can ensure that your application remains operational even during regional disruptions. This setup is not only crucial for maintaining a high-quality user experience but also for adhering to service level agreements (SLAs) that demand consistent uptime. The tutorial provides a straightforward approach to achieving a robust deployment, which can be expanded to include other Azure services like databases and storage accounts for a more comprehensive solution.
References:
https://learn.microsoft.com/en-us/azure/app-service/tutorial-multi-region-app
https://learn.microsoft.com/en-us/azure/app-service/tutorial-multi-region-app