Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications. Traditional load balancers operate at the transport layer (OSI layer 4 - TCP and UDP) and route traffic based on a source IP address and port, to a destination IP address and port. While Application Gateway can make routing decisions based on additional attributes of an HTTP request.

For example, if /teckbakers/devops is in the incoming URL, you can route traffic to a specific set of servers (known as a pool) configured for DevOps. If /teckbakers/microsoftazure is in the URL, that traffic is routed to another pool that's optimized for microsoftazure.

This type of routing is known as application layer (OSI layer 7) load balancing. Azure Application Gateway can do URL-based routing and more.

It manages the requests that client applications (browsers) send to web apps that are hosted on a pool of web servers. The pool of web servers can be Azure virtual machines, Azure Virtual Machine Scale Sets, Azure App Service, and even on-premises servers. Application Gateway provides features such as load balancing HTTP traffic, web application firewall, and support for TLS/SSL encryption of traffic between users and an application gateway and between application servers and an application gateway.

Application Gateway uses a round-robin process to load balance requests to the servers in each back-end pool. Session stickiness ensures client requests in the same session are routed to the same back-end server. Session stickiness is particularly important with e-commerce applications where you don’t want a transaction to be disrupted because the load balancer bounces it around between back-end servers.

Azure Application Gateway includes the following features:

• Support for the HTTP, HTTPS, HTTP/2, and WebSocket protocols

• A web application firewall to protect against web application vulnerabilities

• End-to-end request encryption

Image by Microsoft Learn

How Azure Application Gateway works

Azure Application Gateway has a series of components that combine to securely route and load balance requests across a pool of web servers.

Image by Microsoft Learn

• Front-end IP address: Client requests are received through a front-end IP address. You can configure Application Gateway to have a public IP address, a private IP address, or both. Application Gateway can't have more than one public IP address and one private IP address.

• Listeners: Application Gateway uses one or more listeners to receive incoming requests. A listener accepts traffic arriving on a specified combination of protocol, port, host, and IP address. Each listener routes requests to a back-end pool of servers following routing rules that you specify.

• Routing rules: A routing rule binds a listener to the back-end pools. A rule specifies how to interpret the hostname and path elements in the URL of a request and direct the request to the appropriate back-end pool. A routing rule also has an associated set of HTTP settings. These HTTP settings indicate whether (and how) traffic is encrypted between Application Gateway and the back-end servers. Other configuration information includes Protocol, Session stickiness, Connection draining, Request timeout period, and Health probes.

• Load balancing in Application Gateway

  Application Gateway will automatically load balance requests sent to the servers in each back-end pool using a round-robin mechanism.

• Web Application Firewall

  The web application firewall (WAF) is an optional component that handles incoming requests before they reach a listener. The web application firewall checks each request for many common threats based on the Open Web Application Security Project (OWASP). Common threats include SQL injection, Cross-site scripting, Command injection, HTTP request smuggling, HTTP response splitting, Remote file inclusion, Bots, crawlers, and scanners, and HTTP protocol violations and anomalies.

• Back end pools

  A back-end pool is a collection of web servers. This pool can be made up of a fixed set of virtual machines, a virtual machine scale set, an app hosted by Azure App Services, or a collection of on-premises servers. Each back-end pool has an associated load balancer that distributes work across the pool. When configuring the pool, you'll provide the IP address or name of each web server. All the servers in the back-end pool should be configured in the same way, including their security settings.

Application Gateway routing

When the gateway routes a client request to a web server in the back-end pool, it uses a set of rules configured for the gateway to determine where the request should go. There are two primary methods of routing this client request traffic: path-based routing and multiple-site routing.

Path-based routing

Image by Microsoft Learn

Path-based routing sends requests with different URL paths to different pools of back-end servers. For example, you could direct requests with the path /video/* to a back-end pool containing servers that are optimized to handle video streaming, and direct /images/* requests to a pool of servers that handle image retrieval.

Multiple-site routing

Image by Microsoft Learn

Multiple-site routing configures more than one web application on the same Application Gateway instance. In a multi-site configuration, you register multiple DNS names (CNAMEs) for the IP address of the application gateway, specifying the name of each site. Application Gateway uses separate listeners to wait for requests for each site. Each listener passes the request to a different rule, which can route the requests to servers in a different back-end pool. For example, you could direct all requests for http://contoso.com to servers in one back-end pool, and requests for http://fabrikam.com to another back-end pool.

TLS/SSL termination

Image by Microsoft Learn

If you need end-to-end encryption, Application Gateway can decrypt the traffic on the gateway by using your private key, then re-encrypt again with the public key of the service running in the back-end pool.

When to use Azure Application Gateway

• The health-probe functionality of Azure Application Gateway ensures that traffic isn't being directed to any server that may have become unavailable.

• Azure Application Gateway allows you to use a web application firewall to block cross-site scripting and SQL injection traffic before it reaches servers in the back-end pool.

When not to use Azure Application Gateway

Azure Application Gateway isn’t appropriate if you have a web application that doesn’t require load balancing. For example, if you have a web application that only receives a small amount of traffic and the existing infrastructure already competently deals with the existing load, there's no need to deploy a back-end pool of web apps or virtual machines, and no need for Application Gateway.

Connection draining allows you to deregister an instance in a back-end pool so that it doesn't receive any new traffic. Connection draining is useful in maintenance scenarios during which you want to gracefully remove traffic from a node.

For example consider this scenario: You have a back-end pool made up of eight Azure IaaS virtual machines. You need to install a new framework on each of these virtual machines. You don't want the virtual machine to participate in the back-end pool while you do this maintenance operation. You want to stop new connections from occurring on the VM that you'll do maintenance on, and you also want to allow any existing connections that are present to complete naturally.

Azure provides other load-balancing solutions, including Azure Front Door, Azure Traffic Manager, and Azure Load Balancer.

Now let's start by creating an Application Gateway

1. Login into your azure portal. For Azure to communicate between the resources that you create, a virtual network is needed. Let's start by creating a Resource Group AGPractical. Now Create a Virtual Network and select AGPractical the Resource Group. Enter the name and region.

In the IP addresses tab, specify an address space and create two subnets as shown below, one for Application Gateway, call it AGSubnet and the other one for backend targets which are nothing but servers, call this subnet as BackendSubnet. Keep all the settings in other tabs as it is, then click on review and create and your virtual network will be deployed.

1. Now we will be creating an Application Gateway search for this service and click on create. Keep the settings in the basic tab as follows:

In Configure Virtual Network Settings choose the Virtual Network we had created and select AGSubnet .

In the Frontends tab, select Frontend IP address type as Public and create a new IP address let's say publicIP.

In the Backends tab, add a backend pool as shown below

In the Configuration tab, Add a routing rule

1. Create two new VMs, myVM and myVM2, to be used as backend servers.

myVm

myVM2

While creating both VMs, in the networking tabs, select the virtual network AGVnet we created in the first step and select backendpoolSubnet as the subnet.

1. Install IIS on the virtual machines to verify that the application gateway was created successfully. Go to each VM -> Operations -> Run Command -> RunPowerShellScript -> paste the following command to install IIS to convert the VM into a server.

Add-WindowsFeature Web-Server
Set-Content -Path "C:\inetpub\wwwroot\Default.htm" -Value "Hello world from host $($env:computername) !"

1. Add the backend servers to the backend pool.

1. Test the Application Gateway

Although IIS isn't required to create the application gateway, you installed it to verify if Azure successfully created the application gateway.

Copy the public IP of the Application gateway and paste it into the browser.

Refresh the browser multiple times and you should see connections to both myVM and myVM2.

Clean up resources

When you no longer need the resources that you created with the application gateway, delete the resource group. When you delete the resource group, you also remove the application gateway and all the related resources.

To delete the resource group:

1. On the Azure portal menu, select Resource groups or search for and select Resource groups.

2. On the Resource groups page, search for AGPractical in the list, then select it.

3. On the Resource group page, select Delete resource group.

4. Enter AGPractical under TYPE THE RESOURCE GROUP NAME and then select Delete

That's all for this blog and stay tuned for more networking services tutorials and more such tech. Make sure to subscribe to our newsletter.

Thank you for Reading:)

#Happy Reading!👏

If you have any doubts or suggestions please comment down below - Gayatri Barhate