Below is my personal opinion and is not endorsed in any way by my former, current or any potential future employers :)
Why share Application Gateway?
One reason is cost. As of March 1st, 2019 the lowest monthly price for Application Gateway with Web Application Firewall is ~$110.38 as per https://azure.microsoft.com/en-us/pricing/details/application-gateway/. This is before taking into the account the traffic cost. If your applications do not generate much traffic there is a good reason to consider them sharing the same Application Gateway
Application Gateway constraints
Azure Application Gateway uses one private and one public IP address on which it listens for traffic. Therefore if several applications share Application Gateway you need ensure your applications can be accessed via the same Application Gateway front-end port.
Multiple Applications sharing one Application Gateway
Following are the options to allow multiple applications to be deployed and share the same port on Azure Application Gateway.
Multi-site hosting
Path-based routing rules
Multi-site Hosting
Application Gateway configured with multi-site hosting determines the back-end pool that will serve the request received by Application Gateway based on the value of Host header in http request.
To enable multi-site hosting configure multi-site listeners (rather than basic listeners) on application gateway. Essentially specify host that every listener will serve. PowerShell snippet is below.
Add-AzureRmApplicationGatewayHttpListener -ApplicationGateway $AppGW -Name $appGwHttpsListenerName -Protocol Https -FrontendIPConfiguration $AGFEIPConfig ` -FrontendPort $AGFEPort -SslCertificate $AGFECert -HostName $appFQDN
The full example of adding back-end endpoint (Azure App Service or IaaS) with multi-site listener to Application Gateway is available here.
The screenshot of what to expect in Azure portal is shown below.
Microsoft documentation: Application Gateway multiple site hosting
Limit: Up to 100 websites to one application gateway
Authentication certificates and back-end default SSL binding.
Following is rather important and can be a pain to debug so think it is good to note here.
The default probe gets the public key from the default SSL binding on the back-end's IP address and compares the public key value it receives to the public key value you provide here.
If you are using host headers and Server Name Indication (SNI) on the back end, the retrieved public key might not be the intended site to which traffic flows. If you're in doubt, visit https://127.0.0.1/ on the back-end servers to confirm which certificate is used for the default SSL binding. Use the public key from that request in this section. If you are using host-headers and SNI on HTTPS bindings and you do not receive a response and certificate from a manual browser request to https://127.0.0.1/ on the back-end servers, you must set up a default SSL binding on the them. If you do not do so, probes fail and the back end is not whitelisted.
https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-end-to-end-ssl-powershell
Path-based routing rules
URL Path Based Routing allows you to route traffic to Azure Application Gateway back-end server pools based on URL Paths of the request.
To enable path-based routing configure path-based routing rules in Application Gateway.
The full example of adding back-end endpoints (Azure App Service or IaaS) with path-based routing rule is available here.
Note: this one works for me but is still very much work-in-progress.. so please use at your own risk.
The screenshot of what to expect in Azure portal is shown below.
Note: For Azure applications that are to serve as back-end endpoints for Application Gateway with path-based routing make sure you configure virtual path like below
Now we can test our Application Gateway
Microsoft documentation: URL Path Based Routing overview and Create an application gateway with path-based routing rules using the Azure portal
