Case #
By design the Azure Application Gateway supports HTTP, HTTPS, HTTP/2 and WebSocket. You need to configure the Azure Application Gateway as an HTTPS reverse proxy for publishing an HTTPS service running on any of the following backend pool types:
This article provides high-level guidance on how to configure Azure Application Gateway for HTTPS workloads.
Solution #
First off, you need to consult the Microsoft documentation on the Azure Application Gateway features, design considerations and system requirements. A good place to start is the FAQ article which is available at: https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-faq. You can also review my article on Front Door design considerations, which provides a good foundation when thinking about design considerations for Application Gateway as well.
Configuration overview #
The following configuration options are available for Application Gateway in the Azure management portal.
Step 1 - Create backend pool object #
A backend pool is a configuration object which includes information about the backend targets and associated rules, as shown in the example below.
Step 2 - Create backend HTTP setting object #
A backend HTTP settings object includes various configuration settings of a backend pool, as shown in the example below.
More details about the configuration options in an Application Gateway backend HTTP settings object can be found at: https://learn.microsoft.com/en-us/azure/application-gateway/configuration-http-settings.
The custom probe assumes that you have a health probe already configured, see steps below.
Step 3 - Create a listener object #
When incoming HTTP requests reach the application gateway, it needs to determine a unique service endpoint which the request must be mapped to. The following levels are used, in order of priority, to differentiate one unique HTTP request from another.
- IP address / FQDN
- TCP port (a unique IP/port combination is called a socket)
- Host header (header1.domain.com vs header2.domain.com) and SNI (for TLS)
A listener object links the Application Gateway frontend IP address/FQDN to a backend settings object and defines the usage of a TLS certificate (.pfx file including the private key) if needed, as shown in the example below. A frontend IP, a TCP port, a certificate and an associated rule must be linked.
A listener can be either of type basic or multi-site. If you want all of your requests (for any domain) to be accepted and forwarded to backend pools, choose basic. If you want to forward requests to different backend pools based on the host header or host names, choose multi-site listener, where you must also specify a host name that matches with the incoming request. This is because Application Gateway relies on HTTP 1.1 host headers to host more than one website on the same public IP address and port.
Step 4 - Create a routing rule #
A routing rule defines a listener and one or more backend targets, as shown in the example below.
It is possible to create standard basic rules or path-based rules. For a path-based rule, you need to click on the "Add multiple targets to create a path-based rule" link, as shown below.
Another option is to implement redirection logic instead of linking to one or more backend pools.
One common case in which you can configure redirection logic is when you need to enable HTTP to HTTPS redirection in Azure Application Gateway.
Mention standard basic rules vs path-based rules and redirection rules instead of backend pool routing.
Step 5 - Create a health probe and link it to a backend setting object #
The health probe object includes the host /FQDN, the HTTP path and various timeout and probe matching parameters, as shown below. This defines what you regard as healthy in the HTTP response (by status code).
After creating the health probe, you link it to an backend settings object by using the "Custom probe" option.
Closing words #
A similar configuration approach can be taken with Azure Front Door. Azure Front Door does not support WebSocket, in contrast to Application Gateway. You can find more details about Azure load balancing and quick comparison of application delivery controller services in a separate blog post.
