A little bit of time to write about technology while confined at home so that here is a brief summary about Azure Application Gateway component, one of the solutions Azure provides to load balance traffic.

What is Azure Application Gateway?

Simply put, Azure Application Gateway is an HTTP/HTTPs (L7) web load balancer to distribute traffic among one or several backends with very powerfull features such as:

• URL-based routing: Traffic can be load-balanced based on URL paths.
• SSL termination: Communication with clients can make use of HTTPs until Application Gateway and then, HTTP can be used for connecting Application Gateway with backends (Virtual Machines, Applications, etc.). This frees up resources at backend side.
• Session persistence: The Application Gateway can use cookies to keep a user session on the same server at backend level if needed.
• Web application firewall (WAF): It provides centralized protection of web applications from common exploits and vulnerabilities (SQL-injection, Cross-site scripting, etc.). You can see here all the advantages this feature provides. To summarize, it offers multiple benefits about Protection (common centralized protection without modifications in code for all the websites hosted behind), Monitoring and Security Customization (based on custom policies and rules).

What is an Application Gateway Backend pool?

A backend pool is a collection of resources to which Azure Application Gateway can send HTTP/HTTPs traffic. A backend pool can contain virtual machines, virtual machines scale sets, IP addresses, FQDN (Fully Qualified Domain Names) or App Services. So, not only servers or virtual machines (VMs) can be used to load balance traffic.

List of sample backends as you can see them in Azure Portal

Configuration for the above backend in Azure Portal

What is the main difference from classic Azure Load Balancer?

Classic Azure Load Balancers works on OSI Layer 4 (L4), that is, at transport level while Azure Application Gateway works on OSI layer 7 (L7), at application layer, even more specifically with HTTP/HTTPs protocols.

It means that Application Gateway is able to route traffic based on URI. For example, based on URL path, Azure Application Gateway can load-balance traffic and then, retrieve data from different backends or pool of servers. That selection of backends based on URL paths is not possible by using Azure Load Balancer as it works at transport layer so that it is only able to forward traffic based on a five-tuple hash calculated from protocol type, origin port, origin IP, destination port and destination IP.

Azure Load Balancer

Azure Application Gateway

Azure Application Gateway URL-based Distribution Sample

So, Azure Application Gateway, working on OSI Level 7 (L7) can load-balance traffic based on URL path. For the above picture, HTTP/HTTPs requests will be redirected to ImageServerPool or VideoServerPool based on URL Path. This way, URL paths containing "/Images/*" will be served by ImageServerPool and the same for requests including "/Videos/*" that will be served by VideoServerPool. Finally, paths not matching "/Images/*" or "/Videos/*" can be served by another default backend or pool of servers holding the rest of data (not present in the picture above)| More info

On the other hand, Application Gateway can make use of Web Application Firewall (WAF) to provide further common centralized security as needed. To use this feature, a WAF tier must be selected in main Azure Application Gateway Configuration settings.

What about other Azure load balancing options?

First of all, we can say both Application Gateway and Load Balancer are regional options to distribute traffic across backends supported within a specific region, with or without zone redundancy.

However, other options such as Azure Traffic Manager or Azure Front Door work at global scale, they are meant to distribute traffic across multiple regions.

For more information and a very useful guide to choose among them, visit Overview of Azure Load Balancing Options

Are several backends mandatory?

In the previous example, multiple backends were configured (Image backend and Videos backend holding several servers each one). However, are always several backends needed? No, it is not mandatory.

Application Gateway can load-balance traffic just working with one backend holding multiple servers. HTTP/HTTPs traffic will be forwarded and distributed equally among all the servers that are up and running (healthy state) present in the backend.

However, if you want to distribute traffic based on URL, you will have to create several backends. You can not select a given server within only one backend to send traffic based on URL. As commented, in order to do that you need several backends. In any case, you can leverage the rest of the aforementioned features of Application Gateway.

Sample: Direct web traffic creating Application Gateway with Azure Portal

Is there some requirement that we must know in advance?

Yes, you have to create a dedicated subnet as the Application Gateway subnet can contain only Application Gateways. No other resources are allowed.

Please, don't confused Application Gateways with VPN Gateways. They have nothing to do. The latter is employed to communicate different networks, nothing concerning load-balance traffic.

What else do we need to configure in Application Gateway?

HTTP Settings

HTTP Settings are used to configure the communication between the application gateway listeners and the backends. So, traffic will be routed based on these settings. You can create a list of HTTP Settings items and then, pick one of them to assign to a given rule as we will see later. Each HTTP Setting item let you configure the following elements altogether in a set:

• Backend Protocol: HTTP or HTTPs.
• Backend Port.
• Cookie-based affinity:The Application Gateway can use cookies to keep a user session on the same server. You can enable this feature if the client supports the use of cookies.
• Connection draining:Connection draining helps gracefully remove backend pool members during planned service updates. When this feature is enabled, unregistering instances of a backend pool won’t receive new requests. This applies to backend instances that are explicitly removed from the backend pool via an API call as well as instances reported unhealthy by health probes.
• Request time-out: The request timeout is the number of seconds that the Application Gateway will wait to receive a response from the backend pool before it returns a “connection timed out” error message.
• Override backend path: This feature allows you to override the path in the URL so that the requests for a specific path can be routed to another path. For example, if you intend to route requests for contoso.com/images to default, then enter ‘/’ in this textbox and subsequently attach this HTTP setting to the rule associated with contoso.com/images.
• Override with new host name: No / Yes. In case of Yes, new specific domain name is mandatory.
• Use Custom Probe: No / Yes.

Frontend IP Configurations

Frontend IP addresses are the ones on which Application Gateway listens to incoming HTTP/HTTPs traffic. IP addresses can be public or private and you can associate multiple listeners for each one.

The DNS name associated with an application gateway does not change over the lifecycle of the gateway. As a result, you should use a CNAME alias (RFC 1034, RFC 2181 Section 10) and point it to the DNS address of the application gateway.

Listeners

Listeners are the logical entities used to check for incoming HTTP/HTTPs requests from the Frontend IPs. A listener accepts an HTTP/HTTPs request if the protocol, port, host name and IP address associated with the request match the same elements associated with the listener configuration.

See below a screenshot with the form you will have to fill out to create a new one:

• Frontend IP: Frontend IP planned to associate to the listener. It will be listening to incoming HTTP/HTTPs requests at that IP.
• Port: Port for the listener. You can use well known ports, such as port 80 or 443, or any port ranging from 1 to 65502 (v1 SKU) or 1 to 65199 (v2 SKU).
• Listener type: 
  • If you are hosting a single site behind the application gateway, choose a basic listener.
  • If you are configuring more than one web application or multiple sub-domains of the same parent domain, choose a multiple-site listener and then, enter the host name to match. Application Gateway relies on HTTP 1.1 host headers to host more than one website on the same public IP address and port.

Rules

Rules are the core logic entity that manages traffic from listeners to one or more backend targets. In other words, after a listener detects incoming requests from clients, the application gateway routes these requests to members in the backend pool configured in the rule. A routing rule must contain one listener and at least one backend target. For each backend target you can select one HTTP Settings item. Here are the steps to configure a rule:

1) Select Listener

2) Configure default Backend target

As displayed in the picture above, you can select Backend pool or Redirection as target type. For redirection there are also multiple options. You can redirect to other internal listeners or even external sites. You can even select whether to include paths and query strings, that's really cool. So, let's take a look at different configuration options:

• Target type -> Backend pool 
  • backend target must be selected first to route traffic as default backend. If there are no URL-based routes, there are but without specifying other backends or there are but not matching the URL-based paths, this backend will be used as target.
  • HTTP settings let you select the set of rules for connecting the previous backend.

• Target type -> Redirection with Listener as Target
  • This case, there is no backend to select as traffic will be redirected. By selecting Listener as Redirection target, traffic will be sent to the listener you specify by default.

• Target type -> Redirection with External Site as Target
  • There is no backend to select as traffic will be redirected as well. By selecting External site as Redirection target, traffic will be sent to the Target URL by default.

3) Configure Path-based routing Options:

• If you want to use Path-based rules, you have to click in the "Add multiple targets to create a path-based rule" and select Backend pool as target type. The settings below Path field will be applied to requests matching the URL path you define. If URL path does not match, the request will be sent to the default backend. Prior to do that, several backends must be present. When clicking, you will see the following form:

• If you want to use Redirect rules, you have to click in the "Add multiple targets to create a path-based rule" and select Redirection with Listener or External Site as target type:

Redirection to Internal Listener from URL-based routing

Redirection to External Site from URL-based routing

In any case, if there are no URL-based routes matching the requests, the default backend or redirection setting will be used to process those requests as explained in step 2.

So, based on URL you can process HTTP/HTTPs traffic by using pool of servers, redirection to internal listeners or redirection to external sites.

Health Probes

In order all of this work fine, Application Gateway keeps tracking of each server in the backend by using Health Probes. If a server does not respond to health probe requests accordingly, within a given time-out period and retry counts, it will be marked as unhealthy and then not traffic will be sent to it.

Health probes are automatically created by Azure Application Gateway, but you can create custom probes by configuring protocol to be used in backend zone (HTTP/HTTPs), URL to be requested, timeout periods, retry count threshold, HTTP response matching criteria, etc. See picture below.

References

This is all so far. Not sure if all of this took you 10 minutes. However, I hope this helps you remember next time you visit this post. In the meantime you can get much more information about all of this at:

What is Azure Application Gateway?

How an Application Gateway works

Application Gateway Components

Recommended Related Posts 

How Azure Traffic Manager works

What is Azure Front Door?

Host multiple web sites with Azure Application Gateway