Back in May, we talked about Azure Application Gateway.
In this article, we’re going to look at its anatomy, i.e. its internal component as exposed in the Azure Resource Manager (ARM) model.
A lot of Azure Resource has an internal structure. For instance, a Virtual Network has a collection of subnets.
Azure Application Gateway has a very rich internal model. We will look at this model in order to understand how to configure it.
What is Azure Application Gateway
Application Gateway is a layer-7 load balancer. It provides failover, performance-routing HTTP requests between different servers, whether they are on the cloud or on-premises. Application Gateway provides many Application Delivery Controller (ADC) features including HTTP load balancing, cookie-based session affinity, Secure Sockets Layer (SSL) offload, custom health probes, support for multi-site, and many others.
I like to say that it is at time a Reverse Proxy, a Web Application Firewall (WAF) and a layer 7 load balancer.
Internal Resource Model
Let’s start with a summary diagram. Each box represent a sub resource (except Application Gateway, which represents the main resource) and each of the bullet point within the box represent a property of that sub resource.
We can now look at each sub resource.
Key properties of the gateway itself are
- The SKU, i.e. the tier (Small, Medium, Large) & the number of instances (1 to 10)
- A list of SSL certificates (used by HTTP Listeners)
SSL Certificates are optional if the Gateway exposes only HTTP endpoints but are required for HTTPS endpoints.
The SKU can be anything, although in order to have an SLA, it must be of tier medium or large and have at least 2 instances.
Gateway IP Configuration
The Gateway IP Configuration has a 1:1 relationship with the Application Gateway (trying to register a second configuration results in an error) and can therefore be conceptually considered as properties of the Gateway directly.
It simply defines in which subnet does the Application Gateway live.
Frontend IP Configuration
This sub resource defines how the gateway is exposed.
There can be either one or two of those configuration: either public or private or both.
The same configuration can be used by more than one HTTP listener, using different port.
Frontend ports describe which ports on the Application Gateway are exposed. It simply is a port number.
This is a key component. It combines a frontend IP configuration and port ; it also include a protocol (HTTP or HTTPS) and optionally an SSL certificate.
An HTTP listener is what the Application Gateway is listening to, e.g.:
- Public IP X.Y.Z.W on port 443, HTTPS with a given SSL
- Private IP 10.0.0.1 on port 80, HTTP
Backend Address Pool
The real compute handling requests.
Typically it’s going to be stand-alone VMs or VMs from a VM Scale Set (VMSS) but technically only the addresses are registered. It could therefore be some public web site out there.
Backend HTTP Setting
This component describe how to connect to a backend compute: port#, protocol (HTTP / HTTS) & cookie based affinity.
The frontend & backend can be different: we can have HTTPS on 443 on the frontend while routing it to HTTP on port 12345 in the backend. This is actually a typical SSL termination scenario.
A probe, actually a custom probe, probes a backend for health. It is described by a protocol, a URL, interval, timeout, etc. . Basically we can customize how a backend is determined to be healthy or not.
A custom probe is optional. By default, a default probe is configured probing the backend using the port and protocol specified in the backend http setting.
A rule binds an HTTP Listener, a backend address pool together & a backend setting. It basically binds and endpoint in the frontend with an endpoint in the backend.
There are two types of rules: basic rules & path rules. The former simply binds the aforementioned components together while the later adds the concept of mapping a URL pattern to a given backend.
We covered the anatomy of Application Gateway and articulated how different components relate to each others.
In future articles we will build on this anatomy in order to address specific scenarios.