Web Traffic Load Balancer — Application Layer (OSI Layer 7)

Published in

CloudTechOffice

17 min readDec 24, 2021

Azure Application Gateway Part-1

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 source IP address and port, to a destination IP address and port.

Here you are going to learn about AAG’s (Azure Application Gateway)Architecture, Features, Where to use, How to use and some differences between its versions and Demo.

What is application Gateway?
Application gateway Network Architecture
Application Gateway Features
Azure Web Application Firewall
Application gateway Bells and Whistles
When to use Application Gateway
Decision Tree for Load Balancing
Application Gateway V1 vs V2
Demo

1. What is Application Gateway

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), whereas the Azure Gateway operates at the application layer (OSI Layer 7).
Application Gateway makes routing decisions based on additional attributes of an HTTP request.
Application gateway supports SSL/TLS termination at the gateway, however, for more secure applications the gateway also supports end to end SSL/TLS encryption (gateway to back-end servers).
Application Gateway Standard_v2 can be configured for autoscaling or fixed size deployments.

Application Gateway can make routing decisions based on additional attributes of an HTTP request, for example URI path or host headers. For example, you can route traffic based on the incoming URL. So if /images is in the incoming URL, you can route traffic to a specific set of servers (known as a pool) configured for images. If /video is in the URL, that traffic is routed to another pool that’s optimized for videos.

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

When user request a website or something public IP and traffic look into the backend and whatever customer configured the backend pool the request is going to be forwarded directly to the VM, and VM going to foresight to the user not the load balancer. This is what happens with the regular load balancer.

When we deploy the application gateway, lot of things happen in the background, and that customer can’t see, there is a group of services that is called PaaS (platform as a service). End of the load balancer VMs are in the backend are created/deployed. In the PaaS multiple things happening and everything is managed by Microsoft. Customer only manages the configuration and customer didn’t manage VM in the backend.

Just now Windows server are running in the back-end. When user send the request and request go to the VM in the backend and VM creates another request to actual backend, and this is the one things here and other things here (backend pool). When you look at the backend you didn’t foresight the users, but your foresight the VMs (IIS). If you want to see what IP is using you must see the logs etc.

User send the request here and another request created here to here. When you see the Backend pool and see which VM is available to send the traffic back to user.

First Load Balancer check the both VMs response. If customer choose the One (IIS) VM then it will provisioned only 1 VM (IIS).

When you look at the probe this VM (IIS) probing to (Backend Pool) and look which VM are available to send the traffic back to user. Actually there is a load balancer in (IIS) which send the probe and check which VM is healthy and send the request to another VM for respond the traffic.

Configurations get more complicated when customers add more Instances in the backend Pool and Application gateway.

Virtual network and dedicated subnet

An application gateway is a dedicated deployment in your virtual network. Within your virtual network, a dedicated subnet is required for the application gateway. You can have multiple instances of a given application gateway deployment in a subnet. You can also deploy other application gateways in the subnet. But you can’t deploy any other resource in the application gateway subnet. You can’t mix Standard_v2 and Standard Azure Application Gateway on the same subnet.

Size of the subnet

Application Gateway uses one private IP address per instance, plus another private IP address if a private front-end IP is configured.

Azure also reserves five IP addresses in each subnet for internal use: the first four and the last IP addresses. For example, consider 15 application gateway instances with no private front-end IP. You need at least 20 IP addresses for this subnet: five for internal use and 15 for the application gateway instances.

Consider a subnet that has 27 application gateway instances and an IP address for a private front-end IP. In this case, you need 33 IP addresses: 27 for the application gateway instances, one for the private front end, and five for internal use.

Application Gateway (Standard or WAF) SKU can support up to 32 instances (32 instance IP addresses + 1 private front-end IP + 5 Azure reserved) — so a minimum subnet size of /26 is recommended

Application Gateway (Standard_v2 or WAF_v2 SKU) can support up to 125 instances (125 instance IP addresses + 1 private front-end IP + 5 Azure reserved). A minimum subnet size of /24 is recommended.

Scaling Application Gateway v2 and WAF v2

Application Gateway and WAF can be configured to scale in two modes:

Autoscaling:

With autoscaling enabled, the Application Gateway and WAF v2 SKUs scale up or down based on application traffic requirements. This mode offers better elasticity to your application and eliminates the need to guess the application gateway size or instance count. This mode also allows you to save cost by not requiring the gateway to run at peak-provisioned capacity for expected maximum traffic load.
You must specify a minimum and optionally maximum instance count. Minimum capacity ensures that Application Gateway and WAF v2 don’t fall below the minimum instance count specified, even without traffic.
The instance counts can range from 0 to 125. The default value for maximum instance count is 20 if not specified.

Manual:

You can also choose Manual mode where the gateway won’t autoscale. In this mode, if there’s more traffic than what Application Gateway or WAF can handle, it could result in traffic loss. With manual mode, specifying instance count is mandatory. Instance count can vary from 1 to 125 instances.

Autoscaling and High Availability

Azure Application Gateways are always deployed in a highly available fashion. The service is made out of multiple instances that are created as configured (if autoscaling is disabled) or required by the application load (if autoscaling is enabled). Note that from the user’s perspective you don’t necessarily have visibility into the individual instances, but just into the Application Gateway service as a whole. If a certain instance has a problem and stops being functional, Azure Application Gateway will transparently create a new instance.

Even if you configure autoscaling with zero minimum instances the service will still be highly available, which is always included with the fixed price.

2. Application Gateway Network Architecture

AAG is a reverse proxy with load balancing capabilities

Backend Support:

Azure VM’s

Azure VMSS

Azure WebApps/Function

IP Address/ FQDN

Cookie-based session affinity

When session affinity is enabled, AAG injects its own session cookie in the responses sent to the client
Every request that carries an AAG session cookie goes to the same instance in the backend pool
AAG session cookies are opaque and not-guessable

TLS offloading/termination

Application gateway supports SSL/TLS termination at the gateway, after which traffic typically flows unencrypted to the backend servers. This feature allows web servers to be unburdened from costly encryption and decryption overhead. But sometimes unencrypted communication to the servers isn’t an acceptable option. This can be because of security requirements, compliance requirements, or the application may only accept a secure connection. For these applications, application gateway supports end to end SSL/TLS encryption.

End-to-End TLS Encryption, Backend Servers’ Certificate Validation

AAG v1: certificates used by backend servers must be uploaded to AAG’s certificate whitelist.
AAG v2 : certificates used by backend servers must be issued by well-known CA.
TLS sessions are negotiated only with backend servers that present trusted certificates.

AAG ingress controller for AKS

The ingress controller runs as a pod within the AKS cluster.
It consumes Kubernetes Ingress Resources and converts them to an Azure Application Gateway configuration.
The AAG can be used to load-balance traffic to Kubernetes pods.

3. Application Gateway Features

SSL Off-Loads/ Secure Sockets Layer (SSL/TLS) termination

Web Application Firewall

Web Application Firewall (WAF) is a service that provides centralized protection of your web applications from common exploits and vulnerabilities. WAF is based on rules from the OWASP (Open Web Application Security Project) core rule sets 3.1 (WAF_v2 only), 3.0, and 2.2.9.

Web applications are increasingly targets of malicious attacks that exploit common known vulnerabilities. Common among these exploits are SQL injection attacks, cross site scripting attacks to name a few. Preventing such attacks in application code can be challenging and may require rigorous maintenance, patching and monitoring at many layers of the application topology. A centralized web application firewall helps make security management much simpler and gives better assurance to application administrators against threats or intrusions. A WAF solution can also react to a security threat faster by patching a known vulnerability at a central location versus securing each of individual web applications. Existing application gateways can be converted to a Web Application Firewall enabled application gateway easily.

URL-Based Routing

URL Path Based Routing allows you to route traffic to back-end server pools based on URL Paths of the request. One of the scenarios is to route requests for different content types to different pool.

For example, requests for http://contoso.com/video/* are routed to VideoServerPool, and http://contoso.com/images/* are routed to ImageServerPool. DefaultServerPool is selected if none of the path patterns match.

Multiple-site hosting

With Application Gateway, you can configure routing based on host name or domain name for more than one web application on the same application gateway.
It allows you to configure a more efficient topology for your deployments by adding up to 100+ websites to one application gateway.
Each website can be directed to its own backend pool.
For example, three domains, contoso.com, fabrikam.com, and adatum.com, point to the IP address of the application gateway.
You’d create three multi-site listeners and configure each listener for the respective port and protocol setting.
With Application Gateway, you can configure routing based on host name or domain name for more than one web application on the same application gateway.
It allows you to configure a more efficient topology for your deployments by adding up to 100+ websites to one application gateway.
Each website can be directed to its own backend pool.
For example, three domains, contoso.com, fabrikam.com, and adatum.com, point to the IP address of the application gateway.
You’d create three multi-site listeners and configure each listener for the respective port and protocol setting.

URL redirect

You can use application gateway to redirect traffic. It has a generic redirection mechanism which allows for redirecting traffic received at one listener to another listener or to an external site. This simplifies application configuration, optimizes the resource usage, and supports new redirection scenarios including global and path-based redirection.
A common redirection scenario for many web applications is to support automatic HTTP to HTTPS redirection to ensure all communication between application and its users occurs over an encrypted path. In the past, customers have used techniques such as creating a dedicated backend pool whose sole purpose is to redirect requests it receives on HTTP to HTTPS. With redirection support in Application Gateway, you can accomplish this simply by adding a new redirect configuration to a routing rule, and specifying another listener with HTTPS protocol as the target listener.
The following types of redirection are supported:

301 Permanent Redirect
302 Found
303 See Other
307 Temporary Redirect

Application Gateway redirection support offers the following capabilities:
• Global redirection
Redirects from one listener to another listener on the gateway. This enables HTTP to HTTPS redirection on a site.
• Path-based redirection
This type of redirection enables HTTP to HTTPS redirection only on a specific site area, for example a shopping cart area denoted by /cart/*.
• Redirect to external site

Session affinity

The cookie-based session affinity feature is useful when you want to keep a user session on the same server. By using gateway-managed cookies, the Application Gateway can direct subsequent traffic from a user session to the same server for processing. This is important in cases where session state is saved locally on the server for a user session.

If session affinity is disable, then same user-1, user-2 request can go to any server randomly.

If session affinity is enabled, then same user type (user-1) request will to server-1 and user-2 request will go to server -2.
It will depend on the application to if they want to maintain the consistency of the application case by case.

Autoscaling, Zone Redundancy & Static IP

Application Gateway is available under a Standard_v2 SKU. Web Application Firewall (WAF) is available under a WAF_v2 SKU. The v2 SKU offers performance enhancements and adds support for critical new features like autoscaling, zone redundancy, and support for static VIPs. Existing features under the Standard and WAF SKU continue to be supported in the new v2 SKU, with a few exceptions listed in comparison section.

Autoscaling: Application Gateway or WAF deployments under the autoscaling SKU can scale out or in based on changing traffic load patterns. Autoscaling also removes the requirement to choose a deployment size or instance count during provisioning. This SKU offers true elasticity. In the Standard_v2 and WAF_v2 SKU, Application Gateway can operate both in fixed capacity (autoscaling disabled) and in autoscaling enabled mode. Fixed capacity mode is useful for scenarios with consistent and predictable workloads. Autoscaling mode is beneficial in applications that see variance in application traffic.
Zone redundancy: An Application Gateway or WAF deployment can span multiple Availability Zones, removing the need to provision separate Application Gateway instances in each zone with a Traffic Manager. You can choose a single zone or multiple zones where Application Gateway instances are deployed, which makes it more resilient to zone failure. The backend pool for applications can be similarly distributed across availability zones.
Static VIP: Application Gateway v2 SKU supports the static VIP type exclusively. This ensures that the VIP associated with the application gateway doesn’t change for the lifecycle of the deployment, even after a restart. There isn’t a static VIP in v1, so you must use the application gateway URL instead of the IP address for domain name routing to App Services via the application gateway.

Ingress Controller for AKS

Application Gateway Ingress Controller (AGIC) allows you to use Application Gateway as the ingress for an Azure Kubernetes Service (AKS) cluster.

The ingress controller runs as a pod within the AKS cluster and consumes Kubernetes Ingress Resources and converts them to an Application Gateway configuration, which allows the gateway to load-balance traffic to the Kubernetes pods. The ingress controller only supports Application Gateway Standard_v2 and WAF_v2 SKUs.

For more information, see Application Gateway Ingress Controller (AGIC).

WebSocket and HTTP/2 Traffic

Application Gateway provides native support for WebSocket across all gateway sizes. There is no user-configurable setting to selectively enable or disable WebSocket support.

WebSocket protocol standardized in RFC6455 enables a full duplex communication between a server and a client over a long running TCP connection. This feature allows for a more interactive communication between the web server and the client, which can be bidirectional without the need for polling as required in HTTP-based implementations. WebSocket has low overhead unlike HTTP and can reuse the same TCP connection for multiple request/responses resulting in a more efficient utilization of resources. WebSocket protocols are designed to work over traditional HTTP ports of 80 and 443.

You can continue using a standard HTTP listener on port 80 or 443 to receive WebSocket traffic. WebSocket traffic is then directed to the WebSocket enabled backend server using the appropriate backend pool as specified in application gateway rules. The backend server must respond to the application gateway probes, which are described in the health probe overview section. Application gateway health probes are HTTP/HTTPS only. Each backend server must respond to HTTP probes for application gateway to route WebSocket traffic to the server.
It’s used in apps that benefit from fast, real-time communication, such as chat, dashboard, and game apps.

How does WebSocket work
To establish a WebSocket connection, a specific HTTP-based handshake is exchanged between the client and the server. If successful, the application-layer protocol is “upgraded” from HTTP to WebSocket, using the previously established TCP connection. Once this occurs, HTTP is completely out of the picture; data can be sent or received using the WebSocket protocol by both endpoints, until the WebSocket connection is closed.

Connection Draining

Connection draining helps you gracefully remove back-end pool members during planned service updates. You can apply this setting to all members of a back-end pool by enabling connection draining on the HTTP setting. It ensures that all deregistering instances of a back-end pool continue to maintain existing connections and serve on-going requests for a configurable timeout and don’t receive any new requests or connections. The only exception to this are requests bound for deregistering instances because of gateway-managed session affinity and will continue to be forwarded to the deregistering instances. Connection draining applies to back-end instances that are explicitly removed from the back-end pool.

Custom error pages

Application Gateway allows you to create custom error pages instead of displaying default error pages. You can use your own branding and layout using a custom error page.

Create Azure Application Gateway custom error pages | Microsoft Docs

Rewrite HTTP headers and URL

Application Gateway allows you to rewrite selected content of requests and responses. With this feature, you can translate URLs, query string parameters as well as modify request and response headers. It also allows you to add conditions to ensure that the URL or the specified headers are rewritten only when certain conditions are met. These conditions are based on the request and response information.

NOTE
HTTP header and URL rewrite features are only available for the Application Gateway v2 SKU

Rewrite HTTP headers and URL with Azure Application Gateway | Microsoft Docs

Sizing

Application Gateway Standard_v2 can be configured for autoscaling or fixed size deployments.

The v2 SKU doesn’t offer different instance sizes. For more information on v2 performance and pricing, see Autoscaling V2 and Understanding pricing.

The Application Gateway Standard (v1) is offered in three sizes: Small, Medium, and Large. Small instance sizes are intended for development and testing scenarios.

For a complete list of application gateway limits, see Application Gateway service limits.

4. Azure Web Application Firewall (WAF)

Azure Web Application Firewall (WAF) on Azure Application Gateway provides centralized protection of your web applications from common exploits and vulnerabilities. Web applications are increasingly targeted by malicious attacks that exploit commonly known vulnerabilities. SQL injection and cross-WAF on Application Gateway is based on Core Rule Set (CRS) 3.1, 3.0, or 2.2.9 from the Open Web Application Security Project (OWASP).site scripting are among the most common attacks.

All of the WAF features listed below exist inside of a WAF Policy. You can create multiple policies, and they can be associated with an Application Gateway, to individual listeners, or to path-based routing rules on an Application Gateway. This way, you can have separate policies for each site behind your Application Gateway if needed. For more information on WAF Policies, see Create a WAF Policy.

Benefits

This section describes the core benefits that WAF on Application Gateway provides.

Protection

Protect your web applications from web vulnerabilities and attacks without modification to back-end code.
Protect multiple web applications at the same time. An instance of Application Gateway can host up to 40 websites that are protected by a web application firewall.
Create custom WAF policies for different sites behind the same WAF
Protect your web applications from malicious bots with the IP Reputation ruleset.

Monitoring

Monitor attacks against your web applications by using a real-time WAF log. The log is integrated with Azure Monitor to track WAF alerts and easily monitor trends.
The Application Gateway WAF is integrated with Microsoft Defender for Cloud. Defender for Cloud provides a central view of the security state of all your Azure, hybrid, and multicloud resources.

Customization

Customize WAF rules and rule groups to suit your application requirements and eliminate false positives.
Associate a WAF Policy for each site behind your WAF to allow for site-specific configuration.
Create custom rules to suit the needs of your application

Features

SQL-injection protection.
Cross-site scripting protection.
Protection against other common web attacks, such as command injection, HTTP request smuggling, HTTP response splitting, and remote file inclusion.
Protection against HTTP protocol violations.
Protection against HTTP protocol anomalies, such as missing host user-agent and accept headers.
Protection against crawlers and scanners.
Detection of common application misconfigurations (for example, Apache and IIS).
Configurable request size limits with lower and upper bounds.
Exclusion lists let you omit certain request attributes from a WAF evaluation. A common example is Active Directory-inserted tokens that are used for authentication or password fields.
Create custom rules to suit the specific needs of your applications.
Geo-filter traffic to allow or block certain countries/regions from gaining access to your applications.
Protect your applications from bots with the bot mitigation ruleset.
Inspect JSON and XML in the request body.

5. Application Gateway Bells and Whistles

6. When to use Application gateway?

7. Decision tree for Load Balancing

8. Application Gateway V1 vs V2

Application Gateway options

You can create an Application Gateway on the Standard tier or the WAF tier. You also have a choice of three sizes with varying performance, pricing, and scalability: Small, Medium, and Large.

The Standard and WAF tiers are available in two versions, V1 and V2. V2 supports Azure availability zones, but is currently in preview.

Application Gateway supports manual scaling and autoscaling. If you select autoscaling, Application Gateway will scale out and in automatically according to the application traffic. You can limit the maximum and minimum number of instances of Application Gateway.