Understanding Azure Application Gateway

Azure Application Gateway is a web traffic load balancer that can be used to manage traffic to web applications. This web traffic load balancer operates at the application layer (Layer 7 in the OSI network reference stack). 

It offers web load balancing, which is for HTTP(S) only. Traditional load balancers operate at the transport layer (Layer 4 in the OSI network reference stack), and route traffic—based on the source IP address and a port number—to a destination IP address and a port number. With Azure Application Gateway, traffic can be routed based on the incoming URL as well. For instance, if /pictures is part of the incoming URL, traffic can be routed to a particular set of servers that have been specifically configured for pictures. If /audio is part of the incoming URL, the traffic is routed to another set of servers, configured specifically for audio files. The following diagram shows the workflow of Azure Application Gateway:

Azure Application Gateway

Azure Application Gateway offers the following features and capabilities:

  • Web application firewall: One of the features of the Application Gateway is its web application firewall (WAF). It offers centralized protection of web apps from common vulnerabilities and exploits. It is based on rules from the Open Web Application Security Project (OWASP) 3.0 or 2.2.9. Common exploits include cross-site scripting attacks and SQL injection attacks. With WAF, you can centralize the prevention of such types of attacks, which makes security management a lot easier and gives a better assurance to the administrators than if this is handled in the application code. And, by patching a known vulnerability at a central location instead of in every application separately, administrators can react a lot faster to security threats.
  • URL Path-Based Routing: This allows you to route traffic, based on URL paths, to different backend server pools.
  • Autoscaling: Azure Application Gateway also offers a public preview of a new pricing tier, Standard_V2. This offers Autoscaling, whereby the number of application gateway or WAF deployments can scale based on incoming traffic. It also offers Zone redundancy, whereby the deployment can span multiple availability zones. This way, you don't have to set up multiple application gateway instances in different zones with a traffic manager. It also offers Static VIP, which ensures that the VIP associated with the application gateway does not change after a restart. Additionally, it offers faster deployment and update time, and five times better SSL offload performance than the other pricing tier.
  • Secure Sockets Layer (SSL) termination: Azure Application Gateway offers SSL termination at the gateway. After the gate, the traffic will be transported unencrypted to the backend servers. This will eliminate the need for costly encryption and decryption overheads. End-to-end SSL encryption is also supported for cases that need encrypted communication, such as when an application can only accept a secure connection or for other security requirements.
  • Connection draining: This feature will remove backend pool members during planned service updates. You can enable this setting at the backend HTTP setting and during rule creation. This setting can be applied to all the members of the backend pool. When this feature is enabled, Azure Application Gateway makes sure that all the deregistering instances in the pool do not receive any new requests.
  • Custom error pages: You can create custom error pages using your customer layout and branding, instead of the default error pages that are displayed.
  • Multiple-site hosting: With multiple-site hosting, more than one web app can be configured on the same application gateway. You can add up to 100 web apps to the application gateway, and each web app can be redirected to its own pool of backend servers.
  • Redirection: Azure Application Gateway offers the ability to redirect traffic on the gateway itself. It offers a generic redirection mechanism that can be used for global redirection, whereby traffic is redirected from and to any port you define by using rules. An example of this could be an HTTP to HTTPS redirection. It also offers path-based redirection, where the HTTP to HTTPS is only redirected to a specific site area, and offers redirection to external sites.
  • Session affinity: This feature is useful when you want to maintain a user session on the same server. By using gateway-managed cookies, the gateway can direct traffic from the same user session to the same server for processing. This is used in cases where session states are stored locally on the server for the user session.
  • WebSocket and HTTP/2 traffic: The WebSocket and HTTP/2 protocols are natively supported by Azure Application Gateway. These protocols enable full-duplex communication between the client and the server over a long-running TCP connection, without the need for polling. These protocols can use the same TCP connection for multiple requests and responses, which results in more efficient utilization of resources. These protocols work over the traditional HTTP ports 80 and 443.
  • Rewrite HTTP headers: Azure Application Gateway can also rewrite the HTTP headers for incoming and outgoing traffic. This way, you can add, update, and remove HTTP headers while the request/response packets are moved between the client and the backend pools.

Azure Application Gateway comes in the following tiers:

  • Standard: By selecting this tier, you are going to use the Azure Application Gateway as a load balancer for your web apps.
  • Standard v2 (Preview): In addition to the previous Standard tier, this tier offers autoscaling, zone redundancy, and support for static VIPs.
  • WAF: By selecting this tier, you are going to create a web application firewall.
  • WAF v2 (Preview): In addition to the previous WAF tier, this tier offers autoscaling, zone redundancy, and support for static VIPs.

Azure Application Gateway comes in three different sizes. The following table shows an average performance throughput for each application gateway:

Average backend page response size

Small

Medium

Large

6 KB

7.5 Mbps

13 Mbps

50 Mbps

100 KB

35 Mbps

100 Mbps

200 Mbps

The actual throughput depends on various environment details, such as the location of backend instances, the average page size, and the processing time to serve a page.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset