Azure – Networking – Part 5 – Basics of Azure Application Gateway

Hello Friends,

Let’s continue with Azure Network in this articles. Today in this article we will start with a very important topic of Networking is Azure Application Gateway. In this article we will discuss more on basics of Azure Application Gateway components. If you have missed our last articles, please check it in following links.

Part 1 – Basics of Azure Networking

Part 2 – Azure Virtual Network (VNet)

Part 3 – Subnet in Azure Network

Part 4 – Network Security Group (NSG) in Azure

Azure Application Gateway :

Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications.(Referenced: Official Docs)

We can consider Application Gateway as an advance version of Load balancer which, comes with some extra useful features. The traditional load balancer supports OSI layer 4 with the TCP/UDP. But Application Gateway, supports OSI layer 7 and it works only with http/https protocols (port 80 and 443). With Application Gateway we can be more specific about the route to be followed and the destination to be reached. we can route the traffic based on the incoming URl. For example consider one scenario, where our environment configured two different destination to handle to different requests like one will address Image file request and the other one will handle Video file request . So here Application Gateway is smart enough, by taking the help of Listener and rules, route the traffic to the correct and accurate destination.

Figure 1 : Azure – Application Gateway components

Application Gateway limits

The following table applies to v1, v2, Standard, and WAF SKUs unless otherwise stated. (Referenced: Official Docs)

ResourceDefault/maximum limitNote
Azure Application Gateway1,000 per subscription
Front-end IP configurations21 public and 1 private
Front-end ports1001
Back-end address pools1001
Back-end servers per pool1,200
HTTP listeners1001
HTTP load-balancing rules1001
Back-end HTTP settings1001
Instances per gateway32
SSL certificates10011 per HTTP listeners
Maximum SSL certificate sizeV1 SKU – 10 KB
V2 SKU – 16 KB
Authentication certificates100
Trusted root certificates100
Request timeout minimum1 second
Request timeout maximum24 hours
Number of sites10011 per HTTP listeners
URL maps per listener1
Maximum path-based rules per URL map100
Redirect configurations1001
Concurrent WebSocket connectionsMedium gateways 20k
Large gateways 50k
Maximum URL length8,000
Maximum file upload size, Standard2 GB
Maximum file upload size WAFMedium WAF gateways, 100 MB
Large WAF gateways, 500 MB
WAF body size limit, without files128 KB
Maximum WAF custom rules100

In case of WAF-enabled SKUs, we recommend that you limit the number of resources to 40 for optimal performance.

Core Components of Azure Application Gateway :

Front-End IP :
Front-End IP is the entry point to an Application Gateway. Application Gateway can be configured with two front-end IP. It can be  configured with an Internet-facing VIP or with an internal endpoint that is not exposed to the Internet (by using a private IP for the front-end IP address), also known as an internal load balancer (ILB) endpoint.

Figure 2 : Azure – Application Gateway FrontEnd IP

Listener :
A listener is the most important part of Application Gateway. It listen to the traffic comes for a particular domain.The application gateway has capability to listen to multiple traffic . every traffic will be handle by a separate Listener . We can add multiple listener for a host to support traffics from different protocol (HTTP/HTTPS) and for different port. At the time of creation , we should upload certificate, if listener has created to listen HTTP traffic.

When Listener receive the traffic, it try to communicate with the associated rule, to decide, where to redirect the traffic. If listener doesn’t find any custom rule associated with it then it will use the default rule.One Application Gateway has following two types of Listener.

Basic: A listener which listens to a single domain site where it has a single DNS mapping to IP address of the Application Gateway.
Multi-site:
A listener which listens to a specific domain site(host). e.g production.mstech.in ,development.mstech.in ,QA.mstech.in etc.

Figure 3 : Azure – Application Gateway Listener

Backend Pool :
Backend Pool is one or collection of resources which will serve the incoming traffic/requests. It refer to the host name or public IP of our app, which will address traffics. Backend shouldn’t be confused with our database tier, storage tier, and so on. It should be viewed/considered as the public endpoint of our application.

Figure 4 : Azure – Application Gateway Backend pool 1
Figure 5 : Azure – Application Gateway Backend pool 2

HTTP Settings :
Http Settings helps in validating the request if it is going to the correct backend pool or not. When we are creating a new Http Settings, we need to provide input like , Name, protocol,port, if it support cookie base affinity and custom probe etc. At the time of healthy instance selection this information takes a vital role. It is tied up to a custom domain url and the backend pool.When creating HTTPS setting — backend-certificate is required in “.cer”format.

Figure 6 : Azure – Application Gateway Http Settings

Rules :
The most important component of the application gateway ,which decide what do to when. Rules helps Application Gateway to route traffic to correct back-end pool . Rule works as a coordinator/bridge among , Listener, Http settings and Backend pool. It bind all of them in a string. So So that every part of Application Gateway can communicate with each other to sharing required information.

Default Rule:
For a listener (Eg: mstech.KJ.com/*) which backend pool should serve the request with the associated HTTP Setting.
Path Based Routing:
Usually used in case of specific requests(Eg: mstech.KJ.com/Image/*). This rule gives us the flexibility to route the request to a specific backend pool based on the routing url.
Note: One Rule
can be associated with one Listener .

Figure 7 : Azure – Application Gateway Rules
Figure 7 : Azure – Application Gateway Rules 1

Health Probe :
By default Azure Application Gateway monitors the health of all resources in its back-end pool and automatically removes any resource considered unhealthy from the pool. Application Gateway continues to monitor the unhealthy resources and adds them back to the healthy back-end pool once they become available and respond to health probes.

If there is any specific requirement, we can add custom health probe otherwise default health prove can be used. If there is no health prove configured for a Http Settings, then the default health prove will be used. The default health probe configured automatically with the creation of application gateway . Health probe report determine which backed pool instances will receive new flows.

An HTTP/HTTPS request to the back-end server configured for the back-end pool to monitor the health of the servers.

For example: Let’s consider our back-end pull has 3 servers server -1, server-2, and server-3 to receive HTTP network traffic on port 80. The health monitoring tests the three servers every 30 seconds for a healthy HTTP response. A healthy HTTP response has a status code between 200 and 399. If the status code doesn’t fall in between 200 and 399, then the response will be considered as unhealthy and the server will be out of pull till it return a healthy response.

If there is a network security group (NSG) on an application gateway subnet, port ranges 65503-65534 must be opened on the application gateway subnet for inbound traffic. These ports are required for the backend health API to work (Referenced: Official Microsoft Docs)

Figure 8 : Azure – Application Gatewy Health Probe
Figure 89: Azure – Application Gatewy Health Probe 1

SUMMARY :
So What I understood here, After traffic received by Application Gateway, Listener route the incoming traffic to the to the healthy instance from right Backend pool by taking the information from Rule ( Http Setting info) and Http Settings (Health prove ,cookie based infinity,protocol,port etc …). After the application gateway finalize the backend server, it opens a new TCP session with the backend server based on HTTP settings. HTTP settings specify the protocol, port, and other routing-related settings that are required to establish a new session with the backend server ( From MS Doc). Once healthy instance of backend pool receive the traffic, it process the request and send back the response in same way as it came.

Useful Reference : https://docs.microsoft.com/en-in/azure/application-gateway/how-application-gateway-works

I hope this article gives a basic understanding about Application Gateway and In my next article , we will discuss on the features provided by Application Gateway.

Thanks for reading  🙂

Keep reading, share your thoughts, experiences. Feel free to contact us to discuss more. If you have any suggestion / feedback / doubt, you are most welcome.

Stay tuned on Knowledge-Junction, will come up with more such articles.

Advertisements

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.