Azure Front Door - Hands On With Azure Global Application Loadbalancer

Introduction

Most articles cover the configuration of Azure Front Door and do not show a proper integration of it with any application. So I would share that experience here. Please follow the below steps to see it function.

Create Two Active/Active Web App Across Two Different Regions

This is the 1st step. Once these Active/Active Web Apps are running, Front Door can route to either of these Web Apps. I created the below Web Apps each under Central US and Central India. Each of these Web App is of standard size and the run-time stack chosen as .NET Core. Central US Web App has name "FrontDoorApp-1" and Central India Web App has name "FrontDoorApp-2". The routing of these 2 web apps will be handled by a front door service.

Azure Front Door - Hands On With Azure Global Application Loadbalancer

Create and Configure Azure Front Door Service

I created a Front Door Service with the name "jaish-frontend". During this creation, you should set below 3 configurations through Front End designer.

Frontends/domains

This determines the public URL you will access to hit a Front End service. I made it "jaish-frontend.azurefd.net"

Backend Pools

This determines the instances the Front Door service to handle for routing. In our case, 2 Web App instances we created across 2 regions to be chosen here as below. Front Door will do a 50-50 round-robin based routing across selected backend instances. Also, notice the "Path" mentioned as root where Front Door will be sending periodic requests to get an understanding of the instance's health. There's also an interval of 30 seconds has been set as a period to check the health probe.

Routing Rules

This determines how the Front End URL will route the traffic to the backend pools once it receives a request. It will mostly be configured based on URLs/Route Paths. I chose "/*", which means any URL path patterns will be routed to back end pools. Also, notice the selected Front Door URL and Backend pool name we previously set.

Create a Sample .NET Core Web API

Now create a .NET Core Web API to be hosted inside 2 regions (Central US & Central India) under each of the Web Apps instances. I created a Web API to return some JSON data. Below is the result of running it locally. Notice the marked key-value pairs in the result, which will be utilized later to identify under which instance/node this API is running.

Now deploy this API in both Web Apps (Central US & Central India). I used Visual Studio publish feature to directly deploy from my local machine.

Run Sample .NET Core Web API Inside Individual Regions

First, let's run the published Web API inside individual regions. Below are the URLs for the same Web API across each of the individual regions. This step is to identify the machine names across individual regions. After this step, we will run the Web API using the Front Door URL.

Central US - https://frontdoorapp-1.azurewebsites.net/weatherforecast

Central India - https://frontdoorapp-2.azurewebsites.net/weatherforecast

Below are the results. You can notice that the Central US machine name is "RD0003FF628032" and the Central India machine name is "RD0003FFBD72DE".

Run Sample .NET Core Web API Using Common Front Door URL

Now the real testing to confirm that using Front Door URL, is it really routing the traffic across 2 regions in a 50-50 round-robin basis? Front Door URL to test this is "https://jaish-frontend.azurefd.net/weatherforecast". Try this URL inside postman or browser and refresh each time once results appeared. You will notice that the machine name value in the results is changing randomly across refresh events throughout, and the URL is always "https://jaish-frontend.azurefd.net/weatherforecast". This is proving that with Front Door, the traffic is routing across both regions on a round-robin basis.

We needed to find the Front Door routing across regions and it has been proved here. I hope this tutorial will help you to dig further into additional LB services and scenarios in Azure.