Microsoft Azure Application Gateway | Step-By-Step Process with REAL-TIME Examples
Last updated on 27th Dec 2021, Blog, General
Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications. Application Gateway can make routing decisions based on additional attributes of an HTTP request, for example URI path or host headers.
- What is Azure Application Gateway?
- Azure Application Gateway features
- How an application gateway accepts a request
- How an application gateway routes a request
- Modifications to the request
- What types of logs does Application Gateway provide?
- How is Azure Application Gateway used?
- Create an application gateway
- Azure Application Gateway is a web traffic load balancer that enables you to manage traffic on your web applications. Traditional load balancers operate at the transport layer (OSI Layer 4 – TCP and UDP) and route traffic to the destination IP address and port based on the source IP address and port.
- The application gateway can make routing decisions based on additional characteristics of the HTTP request, for example the URI path or the host header. For example, you can route traffic based on an incoming URL. So if /images is in the incoming URL, you can route the traffic to a specific set of servers (known as a pool) configured for the images. If /video is in the URL, that traffic is routed to another pool optimised for the video.Azure provides a suite of fully managed load-balancing solutions for your scenarios.
- If you want to perform DNS-based global routing and do not have Transport Layer Security (TLS) protocol termination (“SSL offload”), per-HTTP/HTTPS requests, or application-layer processing requirements, review Traffic Manager.
- If you need to optimise the global routing of your web traffic and optimise top-level end-user performance and reliability through accelerated global failover, check out Front Door.
- To perform network layer load balancing, review the load balancer. Your entire scenario can benefit from combining these solutions as needed. For a comparison of Azure load-balancing options, see Overview of load-balancing options in Azure.
What is Azure Application Gateway?
- Secure Sockets Layer (SSL/TLS) termination
- Auto scaling
- Field redundancy
- Static VIP
- Web application firewall
- Access Controller for AKS
- URL-Based Routing
- Multi-site hosting
- Session affinity
- Websockets and HTTP/2 traffic
- Connection drainage
- Custom error page
- Rewrite HTTP Headers and URLs
Azure Application Gateway features:
Azure Application Gateway is a web traffic load balancer that enables you to manage traffic on your web applications.
Application gateway conceptual:
Application Gateway includes the following features:
Secure Sockets Layer (SSL/TLS) termination:
The application gateway supports SSL/TLS termination at the gateway, after which the traffic usually flows unencrypted to the backend server. This feature allows web servers to be free of expensive encryption and decryption overhead. But sometimes unencrypted communication from the server is not an acceptable option. This may be due to security requirements, compliance requirements, or the application can only accept a secure connection. For these applications, the Application Gateway supports end-to-end SSL/TLS encryption.
Application Gateway supports Standard_v2 autoscaling and can scale up or down based on changing traffic load patterns. Autoscaling also removes the need to choose deployment size or instance count during provisioning.
A Standard_v2 application gateway can span multiple availability zones, providing better fault resilience and eliminating the need to provision a separate application gateway in each zone.
The Application Gateway Standard_v2 SKU exclusively supports the static VIP type. This ensures that the VIP attached to the application gateway does not change over the lifetime of the application gateway.
Web application firewall
Web Application Firewall (WAF) is a service that provides centralised protection to your web applications from common exploits and vulnerabilities. WAF is based on the OWASP (Open Web Application Security Project) core rule set 3.1 (WAF_v2 only), rules 3.0 and 2.2.9.
Access Controller for AKS
Application Gateway Ingress Controller (AGIC) allows you to use Application Gateway as the input for Azure Kubernetes Service (AKS) clusters. The ingress controller runs as a pod within the AKS cluster and consumes Kubernetes Ingress resources and converts them into an Application Gateway configuration, which allows the gateway to load-balance the traffic in the Kubernetes pod. The Access Controller only supports the Application Gateway Standard_v2 and WAF_v2 SKUs.
URL path based routing allows you to route traffic to a back-end server pool based on the URL paths of the request. One of the scenarios is to route requests for different content types to different pools.
With Application Gateway, you can configure routing based on host name or domain name for multiple web applications on the same application gateway. It allows you to configure a more efficient topology for your deployment by connecting 100+ websites to a single 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 will create three multi-site listeners and configure each listener for the respective port and protocol setting.
A common scenario for many web applications is to support automatic HTTP to HTTPS redirection to ensure that all communication between an application and its users occurs over an encrypted path.
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 the user session to the same server for processing. This is important in cases where session state is saved locally on the server for the user session.
Websockets and HTTP/2 traffic
Application Gateway provides native support for WebSocket and HTTP/2 protocols. There is no user-configurable setting to selectively enable or disable WebSocket support.
Connection draining helps you gracefully remove backend pool members during planned service updates. This setting is enabled through the backend http setting and can be applied to all members of the backend pool during rule creation.
Custom error page
Application Gateway allows you to create custom error pages instead of displaying default error pages. You can use your own branding and layout by using a custom error page
Rewrite HTTP Headers and URLs
HTTP headers allow the client and server to pass additional information along with the request or response. Rewriting these HTTP headers helps you meet a number of important scenarios, such as:
Application Gateway Standard_v2 can be configured for auto scaling or fixed-size deployment. The V2 SKU does not provide different instance sizes. For more information on v2’s performance and pricing, see Understanding Autoscaling v2 and Pricing. Application Gateway Standard (v1) is offered in three sizes: small, medium and large. Small example sizes are intended for development and testing
- Before a client sends a request to an application gateway, it resolves the application gateway’s domain name using a domain name system (DNS) server. Azure controls DNS entry because all application gateways are in the azure.com domain.
- Azure DNS returns the IP address to the client, which is the frontend IP address of the application gateway. The application gateway intercepts incoming traffic on one or more listeners. A listener is a logical entity that examines connection requests. It is configured with the frontend IP address, protocol and port number for the connection from the client to the application gateway.
- If a Web Application Firewall (WAF) is in use, the Application Gateway checks the request header and body, if present, against the WAF rules. This action determines whether the request is a valid request or a security threat. If the request is valid, it is forwarded to the backend. If the request is not valid and the WAF is in containment mode, it is blocked as a security threat. If it is 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 a public IP address. 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 and from the Internet.
- Internal application gateways only use private IP addresses. If you are using a custom or private DNS zone, the domain name must be internally resolvable to the application gateway’s private IP address. Therefore, internal load-balancers can only route requests from clients with access to the virtual network to the application gateway.
How an application gateway accepts a request:
Develop Your Skills with Advanced windows Azure Certification TrainingWeekday / Weekend BatchesSee Batch Details
- If a request is valid and is not blocked by the WAF, the application gateway evaluates the request routing rule that is attached to the listener. This action determines which backend pool to route the request to.
- Based on the request routing rule, the application gateway determines whether to route all requests on the listener to a specific backend pool, to make requests to different backend pools based on the URL path, or to another port or external site Redirect requests.
How an application gateway routes a request:
- The Application Gateway inserts five additional headers into all requests before forwarding the requests to the backend. These headers are X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port, X-Origin-Host and X-APGW-Trace-ID. The format of the x-forwarded-for header is a comma-separated list of IP: ports.
- Valid values for x-forwarded-proto are HTTP or HTTPS. X-Forwarded-Port Specifies the port where the request arrived at the application gateway. The X-Origin-Host header contains the original host header the request came with. 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, it adds a gateway-managed affinity cookie.
- x-appgw-trace-id is a unique guid generated by the Application Gateway for each client request and presented in the request forwarded to the backend pool member. The guide consists of 32 alphanumeric characters without dashes (for example: ac882cd65a2712a0fe1289ec2bb6aee7). This guide can be used to correlate the request received by the application gateway and initiated to the backend pool member via the TransactionID property in the diagnostic log.
- You can configure Application Gateway to modify request and response headers and URLs to rewrite HTTP headers and URLs, or to modify the URI path by using the path-override setting. However, unless configured to do so, all incoming requests are proxied to the backend.
Modifications to the request:
- The Application Gateway v1 SKU supports high-availability scenarios when you deploy two or more instances. Azure distributes these instances across update and fault domains to ensure that all instances do not fail at the same time. The V1 SKU supports scalability by connecting multiple instances of the same gateway to share the load.
- The V2 SKU automatically ensures that new instances are spread across the fault domain and update domain. If you choose zone redundancy, the latest instances to offer zonal failure resilience are also spread across availability zones.
How does Application Gateway support high availability and scalability?
What types of logs does Application Gateway provide?
Application Gateway provides three logs:
ApplicationGatewayAccessLog: The access log contains each request submitted to the Application Gateway frontend. Data includes the caller’s IP, requested URL, response latency, return code, and bytes in and out. It has one record per application gateway.
Application gateway performance log: The performance log captures the performance information for each application gateway. Information includes throughput in bytes, total requests served, failed request numbers, and healthy and unhealthy backend instance counts.
Application gateway firewall log: For the application gateway you have configured with WAF, the firewall log contains requests that are logged either through detection mode or prevention mode.All logs are collected every 60 seconds. For more information, see Backend health, diagnostics logs and metrics for Application Gateway.
- Deliver and manage load balancing solutions for websites, web applications or Internet based services.
- Provide load balancing for internal web enabled/powered services.
- Provide cookie based session affinity service.
- Enable SSL Offloading service which removes the encryption/decryption burden from the primary web server.
How is Azure Application Gateway used?
It primarily provides a complete, cloud based, secure and scalable load balancing solution for web applications and services. Some of the ways to use it include:
Create an application gateway:
You will create an application gateway by using the tab on the Create Application Gateway page.
On the Azure portal menu or from the home page, select Create a resource. New window appears.
Select Networking and then select Application Gateway in the select list.
Basics Tab:On the Basic tab, enter these values for the following Application Gateway setting:
Resource Group: Select myResourceGroupAG for the resource group. If it doesn’t exist, select Create New to create it.
Application Gateway Name: Enter myAppGateway for the name of the Application Gateway.
For Azure to communicate between the resources you’ve created, it needs a virtual network. You can either create a new virtual network or use an existing network. In this example, you would create a new virtual network at the same time that you would create the Application Gateway. Application Gateway instances are created in separate subnets. You create two subnets in this example: one for the application gateway, and one for the backend server.
Virtual Network Service endpoint policies are not currently supported in an Application Gateway subnet.
Under Configure virtual network, create a new virtual network by selecting Create new. In the Virtual Network window that opens, enter the following values to create a virtual network and two subnets:
Name: Enter myVNet for the name of the virtual network.
Subnet Name (Application Gateway Subnet): The Subnet Grid will show the subnet named Default. Rename this subnet to myAGSubnet.
Subnet Name (Backend Server Subnet): In the second row of the Subnet grid, enter myBackendSubnet in the Subnet Name column.
Address Range (Backend Server Subnet): In the second row of the Subnet grid, enter an address range that does not overlap with the address range of myAGSubnet. For example, if the address range of myAGSubnet is 10.0.0.0/24, enter 10.0.1.0/24 for the address range of myBackendSubnet.Select OK to close the Create Virtual Network window and save the virtual network settings.
Create a new Application Gateway: Virtual Network. On the Basics tab, accept the default values for other settings, and then select Next: Frontend.
- Azure Application Gateway is a web traffic load balancer that enables us to manage traffic to your web applications. Typically a traffic load balancer, the transport layer uses TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) to route users’ requests (traffic) based on the source IP and port to destination.
- On top of this Azure Application Gateway has an added advantage, like we can route the request based on additional parameters like HTTP request and its URI path. This type of routing is known as Application Layer (OSI Layer 7) load balancing.
- Azure Application Gateway supports SSL/TLS termination on the gateway. This allows for the additional overhead of encryption and an alternative option for decryption of the request. However, it is not recommended if we are implementing a secure application.