Application gateway Components

Application gateway Components

An application gateway serves as the single point of contact for clients. It distributes incoming application traffic across multiple backend pools, which include Azure VMs, virtual machine scale sets, Azure App Service, and on-premises/external servers. To distribute traffic, an application gateway uses several components.

Frontend IP address 

A frontend IP address is the IP address associated with an application gateway. You can configure an application gateway to have a public IP address, a private IP address, or both. An application gateway supports one public or one private IP address. Your virtual network and public IP address must be in the same location as your application gateway. After it's created, a frontend IP address is associated with a listener.

Listeners

A listener is a logical entity that checks for incoming connection requests. A listener accepts a request if the protocol, port, hostname, and IP address associated with the request match the same elements associated with the listener configuration.

Before you use an application gateway, you must add at least one listener. There can be multiple listeners attached to an application gateway, and they can be used for the same protocol.

After a listener detects incoming requests from clients, the application gateway routes these requests to members in the backend pool configured in the rule.

Listeners support the following ports and protocols.

Ports: 

A port is where a listener listens for the client request. You can configure ports for v1 and v2 SKUs as per below.

• For V2 SKU port range from 1 to 64999 with 22 Exceptions
• For V1 SKU port range from 1 to 65502 with 3389 Exceptions

Protocols 

Application Gateway supports four protocols: HTTP, HTTPS, HTTP/2, and WebSocket:

Custom error pages

Application Gateway lets you create custom error pages instead of displaying default error pages. Application Gateway displays a custom error page when a request can't reach the backend.

Type of Listeners

There are two types of listeners:

• Basic. This type of listener listens to a single domain site, where it has a single DNS mapping to the IP address of the application gateway. This listener configuration is required when you host a single site behind an application gateway.
• Multi-site. This listener configuration is required when you want to configure routing based on hostname or domain name for more than one web application on the same application gateway. Each website can be directed to its own backend pool. For example, three domains, dclessons.com, abc.com, and xyz.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.You can also define wildcard host names in a multi-site listener and up to 5 hostnames per listener.

After you create a listener, you associate it with a request routing rule. This rule determines how the request received on the listener should be routed to the backend. The request routing rule also contains the backend pool to be routed to and the HTTP setting where the backend port, protocol, etc. are mentioned.

Request Routing Rules

A request routing rule is a key component of an application gateway because it determines how to route traffic on the listener. The rule binds the listener, the backend server pool, and the backend HTTP settings.

When a listener accepts a request, the request routing rule forwards the request to the backend or redirects it elsewhere. If the request is forwarded to the backend, the request routing rule defines which backend server pool to forward it to. The request routing rule also determines if the headers in the request are to be rewritten. One listener can be attached to one rule.

There are two types of request routing rules:

• Basic. All requests on the associated listener (for example, blog.contoso.com/*) are forwarded to the associated backend pool by using the associated HTTP setting.
• Path-based. This routing rule lets you route the requests on the associated listener to a specific backend pool, based on the URL in the request. If the path of the URL in a request matches the path pattern in a path-based rule, the rule routes that request. It applies the path pattern only to the URL path, not to its query parameters. If the URL path on a listener request doesn't match any of the path-based rules, it routes the request to the default backend pool and HTTP settings.

Redirection Support

The request routing rule also allows you to redirect traffic on the application gateway.You can choose the redirection target to be another listener (which can help enable automatic HTTP to HTTPS redirection) or an external site. You can also choose to have the redirection be temporary or permanent, or to append the URI path and query string to the redirected URL.

HTTP settings

An application gateway routes traffic to the backend servers (specified in the request routing rule that include HTTP settings) by using the port number, protocol, and other settings detailed in this component.