Overcoming the 40 Frontend Port limitation on Azure Application Gateway

Question

• We present a customer facing application on ourapp.com
• Ourapp.com points to the public IP of our Azure Web Application firewall
• Each of our customers has two dedicated ports that they use to access the application.
• All of those ports are within the range of 49152 to 65535
• Changing the port a customer connects to is not currently possible due to contractual obligations, but we will be approaching new customers with a more scaleable solution, and migrating old customers when they renew their contract.
• Currently, ourapp.com points to an Azure Application Gateway with Web Application firewall.
• The Application gateway listens on the port the customer connects to and passes the connection to the appropriate pool of our backend application servers.
• Within the App Gateway, some routing rules have rewrite rules that append additional headers to the request.
• The Application Gateway with Web Application Firewall has a limit of 40 frontend listening ports, which limits us to 20 customers (with 2 ports exposed) per Application Gateway
• We have far more than 20 customers

My question is this. Can I feasibly split our client base over multiple Application Gateways while maintaining a singular public URL?

Documentation on App Gateway limits: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#application-gateway-limits

Answer 1

One public URL/domain can only point to just one public IP address, which in your case translates to one application gateway. If you're hitting limits on one WAF AppGw, you clearly need to add more of those. Hence, you need to introduce something else on top of the AppGw, that would accept the traffic and distribute it internally to multiple AppGws.

I have a similar setup but in my case I hit the limit of 100 listeners (we have 100s domains listening on 443 only, but it's the same if you had one domain with 100s different URLs listening on different ports) on the AppGw and resorted to increasing the number of AppGws to split it over 5 AppGws.

Since you're looking at scaling, one you need to look at is some sort of Destination NAT on top of the AppGws that would handle the distribution. Consider using an Azure Firewall, creating one NAT rule for each port. I believe one caveat is with that is all the AppGws will have to be listening on private IPs ( You can have both a private IP and a public IP configured).

Two rules would look like this:

Rule1
Source: *
Destination Address: Firewall public IP
Destination Ports: 49152
Translated address: AppGw1 private IP
Translated port: 49152

Rule2
Source: *
Destination Address: Firewall public IP
Destination Ports: 49154
Translated address: AppGw2 private IP
Translated port: 49154

This is not a perfect solution because even the Azure Firewall has some limitations (maximum of 298 DNAT rules, allowing you to serve 149 customers).