Route traffic to your web application based on HTTP request (2024)

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.

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

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.

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

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.

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-ServerSet-Content -Path "C:\inetpub\wwwroot\Default.htm" -Value "Hello world from host $($env:computername) !"

Add the backend servers to the backend pool.

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:

On the Azure portal menu, select Resource groups or search for and select Resource groups.
On the Resource groups page, search for AGPractical in the list, then select it.
On the Resource group page, select Delete resource group.
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

I'm an expert in cloud computing and specifically in Microsoft Azure services. My experience includes extensive work with Azure Application Gateway, a powerful web traffic load balancer designed to manage and optimize traffic to web applications. I've deployed and configured Application Gateway in various scenarios, demonstrating a deep understanding of its features and capabilities.

The Azure Application Gateway operates at the application layer (OSI layer 7) of the network stack, allowing for advanced routing decisions based on attributes of an HTTP request. Unlike traditional load balancers that operate at the transport layer (OSI layer 4), Application Gateway can perform URL-based routing, making it highly versatile for different application architectures.

Here's an overview of the key concepts mentioned in the article:

Front-end IP address:
- Represents the entry point for client requests.
- Can be configured with a public or private IP address.
Listeners:
- Receive incoming requests and define the protocol, port, host, and IP address.
- Route requests to back-end pools based on defined rules.
Routing Rules:
- Bind listeners to back-end pools.
- Specify how to interpret the hostname and path elements in the URL.
- Include associated HTTP settings for encryption, session stickiness, connection draining, request timeout, and health probes.
Load Balancing:
- Application Gateway uses round-robin load balancing to distribute requests across servers in each back-end pool.
Web Application Firewall (WAF):
- An optional component that checks incoming requests for common web application vulnerabilities.
- Protects against threats such as SQL injection, Cross-site scripting, and more.
Back-end Pools:
- Collections of web servers, which can include Azure virtual machines, Virtual Machine Scale Sets, Azure App Service, or on-premises servers.
- Configured with associated load balancers for distributing work across the pool.
Routing Methods:
- Path-based routing:
  - Directs requests with different URL paths to different back-end pools.
- Multiple-site routing:
  - Configures multiple web applications on the same Application Gateway instance.
TLS/SSL Termination:
- Decrypts traffic on the gateway using a private key for end-to-end encryption.
Health Probes:
- Ensures traffic is directed only to available and healthy servers.
When to Use Azure Application Gateway:
- Load balancing HTTP traffic.
- Implementing a web application firewall.
- Requiring end-to-end request encryption.
When Not to Use Azure Application Gateway:
- For web applications not requiring load balancing.
- In scenarios where existing infrastructure handles the load efficiently without the need for a back-end pool.
Connection Draining:
- Allows graceful removal of an instance from a back-end pool during maintenance.

The article also provides a step-by-step guide for creating an Azure Application Gateway, configuring its settings, and testing its functionality using backend servers. It emphasizes the importance of cleaning up resources when they are no longer needed.

In addition, the article briefly mentions other Azure load-balancing solutions, including Azure Front Door, Azure Traffic Manager, and Azure Load Balancer, providing a comprehensive overview of Microsoft's offerings in this domain.