Application Gateway and app services:

Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications. When compared to Azure Front Door that offers global load balancing across regions and is preferred for direct connectivity to the internet, App Gateway is suitable for backends contained within a region or is not open to the public internet. Both provide web application firewall and App Gateway provides features such as SSL/TLS termination, autoscaling, zone-redundancy, static VIP, Ingress controller for Azure Kubernetes Service resources, URL based routing, multiple site hosting, redirection, session affinity, websocket and http/2 traffic, connection draining, custom error pages, rewrite of http headers and URL, and sizing. It is preferable to choose the v2 sku that includes the WAF.

The declaration for this resource takes parameters to describe the backend and its https settings and together the gateway and its backend can fulfill all expectations for load balancing and routing including restricting access to the backend from the internet and making them available to the application gateway. It requires some configuration on both the backend as well as the application gateway and this article calls them out.

First, the application gateway can have a wide variety of backend from sites hosted on Virtual machine scale sets to function applications even though it is primary for application layer load balancing with traffic over http/s. In this case, we take a simple case of an application gateway load balancing between a web application and a function application. The backend can be described by ip addresses as well as fully qualified domain names. The latter is preferable because we do not need to set vnet integration and call out the private link. It will resolve the private link when available and throw an error when accessed via the public when the private link is set up. A private link avoids sending the traffic over the internet and keeps it within the region. The backend should include the full name for the web app and function app for our example.

The backend http settings are described with the port, protocol, path, timeout, and other parameters. It must have cookie-based affinity enabled or disabled and it is preferable to keep it disabled. The http settings also include a reference to a probe which allows us to diagnose the health of the backend services.  The probe takes similar parameters as the http settings to make an http request to a specified path and can even pick the host name from the backend settings. Writing custom probes is preferable when the path is custom or the responses are also meaningful to the health check in addition to the status codes.

As with any firewall, the application gateway must declare the routing rules and the http listener that should be used with the matches. The redirects and rewrite rule sets can also be specified here along with a priority for the ordering of rules. The gateway must have a private address as well as a public address when it is to be reached from both networks.

The applications must specify addresses to accept traffic from as the private address of the application gateway. They must also specify CORS by setting the Access-Control-Allow-Origin response header.  This completes the restriction of traffic to the backend from public internet and permitted only via the application gateway.