Azure Application Gateway enables us to manage traffic to our web applications; basically it is a web traffic load balancer.
Traditional load balancers work 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.
Let us discuss about some Application Gateway features:
1. Secure Sockets Layer (SSL/TLS) termination
Application gateway supports end to end SSL/TLS encryption because of security requirements, compliance requirements, or the application may only accept a secure connection .It also 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.
Application Gateway Standard_v2 supports auto scaling and can scale up or down based on changing traffic load patterns. It also removes the requirement to choose a deployment size or instance count during provisioning.
3. Zone redundancy
A Standard_v2 Application Gateway can extent multiple Availability Zones, offering better fault resiliency and removing the need to provision separate Application Gateways in each zone.
4. Static VIP
The application gateway Standard_v2 SKU supports static VIP type exclusively. This ensures that the VIP associated with application gateway doesn't change even over the lifetime of the Application Gateway.
5. 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.
6. 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.
7. URL-based routing
URL Path Based Routing allows us 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://aita.com/video/* are routed to VideoServerPool, and
http://aita.com/images/* are routed to ImageServerPool. DefaultServerPool is selected if none of the path patterns match.
8. Multiple-site hosting
Multiple-site hosting enables us to configure more than one web site on the same application gateway instance. This feature allows us to configure a more efficient topology for our deployments by adding up to 100 web sites to one Application Gateway. Each web site can be directed to its own pool.
In the past, we used techniques such as dedicated pool creation whose sole purpose is to redirect requests it receives on HTTP to HTTPS. Application gateway supports the ability to redirect traffic on the Application Gateway. Application Gateway redirection support isn't limited to HTTP to HTTPS redirection alone. This is a generic redirection mechanism, so you can redirect from and to any port you define using rules. It also supports redirection to an external site as well.
10. Session affinity
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.
11. Websocket and HTTP/2 traffic
Application Gateway provides native support for the WebSocket and HTTP/2 protocols. There's no user-configurable setting to selectively enable or disable WebSocket support.
12. Connection draining
Connection draining helps you achieve graceful removal of backend pool members during planned service updates. This setting is enabled via the backend http setting and can be applied to all members of a backend pool during rule creation. Once enabled, Application Gateway ensures all deregistering instances of a backend pool don't receive any new request while allowing existing requests to complete within a configured time limit.
13. Custom error pages
Application Gateway allows us to create custom error pages which can be used own branding and layout instead of displaying default error pages.
14. Rewrite HTTP headers
HTTP headers allow the client and server to pass additional information with the request or the response. Rewriting these HTTP headers helps you accomplish several important scenarios, such as:
- Adding security-related header fields like HSTS/ X-XSS-Protection.
- Removing response header fields that can reveal sensitive information.
- Stripping port information from X-Forwarded-For headers.
Application Gateway supports the capability to add, remove, or update HTTP request and response headers, while the request and response packets move between the client and back-end pools. It also provides you with the capability to add conditions to ensure the specified headers are rewritten only when certain conditions are met.
Application Gateway Standard_v2 can be configured for auto scaling or fixed size deployments. This SKU doesn't offer different instance sizes. The Application Gateway Standard is offered in three sizes: Small, Medium, and Large. Small instance sizes are intended for development and testing scenarios.
How does an application gateway work
Now we will explain how an application gateway accepts incoming requests and routes them to the backend.
How does an application gateway accept a request
- Before a client sends a request to an application gateway, it resolves the domain name of the application gateway by using a Domain Name System (DNS) server.
- The Azure DNS returns the IP address to the client, which is the frontend IP address of the application gateway.
- The application gateway accepts incoming traffic on one or more listeners. A listener is a logical entity that checks for connection requests. It's configured with a frontend IP address, protocol, and port number for connections from clients to the application gateway.
- If a web application firewall (WAF) is in use, the application gateway checks the request headers and the body, if present, against WAF rules. This action determines if the request is valid request or a security threat. If the request is valid, it's routed to the backend. If the request isn't valid and WAF is in Prevention mode, it's blocked as a security threat. If it's in Detection mode, the request is evaluated and logged, but still forwarded to the backend server.
Azure Application Gateway can be used as an internal application load balancer or as an internet-facing application load balancer. An internet-facing application gateway uses public IP addresses. The DNS name of an internet-facing application gateway is publicly resolvable to its public IP address. As a result, internet-facing application gateways can route client requests to the internet.
Internal application gateways use only private IP addresses. If you are using a Custom or Private DNS zone, the domain name should be internally resolvable to the private IP address of the Application Gateway. Therefore, internal load-balancers can only route requests from clients with access to a virtual network for the application gateway.
How does an application gateway route a request
If a request is valid and not blocked by WAF, the application gateway evaluates the request routing rule that's associated with the listener.
Based on the request routing rule, the application gateway determines whether to route all requests on the listener to a specific backend pool, route requests to different backend pools based on the URL path, or redirect requests to another port or external site.
When the application gateway selects the backend pool, it sends the request to one of the healthy backend servers in the pool (y.y.y.y). If the backend pool contains multiple servers, the application gateway uses a round-robin algorithm to route the requests between healthy servers.
After the application gateway determines 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.
The port and protocol used in HTTP settings determine whether the traffic between the application gateway and backend servers is encrypted (thus accomplishing end-to-end TLS) or is unencrypted.
When an application gateway sends the original request to the backend server, it honors any custom configuration made in the HTTP settings related to overriding the hostname, path, and protocol. This action maintains cookie-based session affinity, connection draining, host-name selection from the backend, and so on.
Modifications to the request
An application gateway inserts four additional headers to all requests before it forwards the requests to the backend. These headers are x-forwarded-for, x-forwarded-proto, x-forwarded-port, and x-original-host. The format for x-forwarded-for header is a comma-separated list of IP:port.
The valid values for x-forwarded-proto are HTTP or HTTPS. X-forwarded-port specifies the port where the request reached the application gateway. X-original-host header contains the original host header with which the request arrived. This header is useful in Azure website integration, where the incoming host header is modified before traffic is routed to the backend. If session affinity is enabled as an option, then it adds a gateway-managed affinity cookie.