Increase listener limit for Application Gateway
Application gateway has a very low listener limit (20 listeners / certificates). This severely limits it's usefulness for multi-tenant/domain applications where a web farm / service hosts many endpoints. IIS itself has no such small limit, but due to constraints on certificate deployment in cloud services, Application Gateway is the only clear path to wide scale SNI based SSL hosting. With it's low limit, it does not come close to meeting our use case. I would suggest the limit be removed or set to a very high limit like 10k+ so many certificates could be bound to host many different domains.
We have raised the limit to 100 recently. We are regularly reviewing the limits and will continue to look for opportunities to raise the limits even further. If you have scenarios requiring limits higher than what is supported, please add your scenario details here (if you are comfortable with that) or raise an issue with Azure support and we will get back to you.
Gonzalo Parra commented
We host 100's of sites and having such a low limit makes this service practically useless, the limit needs to be exponentially higher, in the 1000's for it to be really useful. Not sure if this would require a separate idea but allowing multiple host names (unlimited or very high limit) per listener would really help, wildcards solves the problem for some cases but not most.
Also, if the problem is performance related, how come the limit is fixed and not size dependent? shouldn't the Large AG be able to handle a lot more than the Medium or Small?
Dynamics 365 IFD deployments require a listener (host) per tenant. With a limit of 100, 40 in WAF mode, it does not scale well for an enterprise system. Multiple gateways cannot be used as it is balancing the same servers which is not allowed.
Hi team, we have a requirement where we need to publish almost 250 web farm behind the application gateway but because of this 100 listeners/gateway limitations now we need to use multiple application gateways to support this configuration.
We are working on supporting wildcard listeners in the near term. As mentioned before, if you need more than 100 listeners you can open a support ticket with your specific scenario details. The current limit of 100 is set based on performance tests and we are unable to set it to a much higher value for all customers at this time as it may degrade performance depending on individual scenarios. That being said, we continue to review periodically and optimize our data plane so that higher limits may be possible.
I didn't realize in my previous message that we also need www and root level listeners for each of those (since we don't have wildcard listeners yet). This means the current limit is only working for 25 URLs max (http/https/www/non-www)... Please raise this higher asap.
Jared Borgerding commented
So the recommended WAF limit is 40 but can go up to 100.
Is there any documentation on what kind of degradation begins to happen upon breaking the 40 limit?
And is there any way currently to increase the limit higher than 100 on your end? Like I stated in my original ticket opener our situation will eventually require us to proceed past 100 Listeners due to http to https redirection and additional vanity domains being configured that will require both www and non www entries due to the lack of wildcard support.
Benjamin Mitchell commented
100 is still way too few to be useful for larger platforms. Why not just make it 1000? Is there a technical reason this isn't allowed that we are not aware of? Give us a reason for these low numbers.
Even with 100 listeners/gateway, this still only allows for 50 tenants in a multi-tenant app if you're doing http -> https redirection. In order for us to use AppGateways, we have to create multiple app gateways per subscription. Then, because of other limits (such as service buses per subscription), we have to have multiple subscriptions. It makes tenant provision automation a nightmare. What's the issue with raising the number of listeners to 1000 or even higher?
Also note, I voted for wildcard support which could solve this problem for a lot of people: (https://feedback.azure.com/forums/217313-networking/suggestions/19527121-application-gateway-support-wildcard-hosts-in-lis)
Thank you, thank you, thank you!
It's good to be able to say that rather that just moaning :D
Frederik Bruneel commented
For a multilanguage site we currently need to add around 150 domain names (4-5 different brand names, 20-25 countries). Please upgrade this, it would make life so much easier.
Michel Zehnder commented
Apparently the limit is 40 now. Would still like to have more:
Michel Zehnder commented
Please make this happen... this is severly crippling the usefulness of this!
How can this not be "Under Review"?
The current limitation makes it virtually unusable.
Lefty Righty commented
This is causing a major problem. I wanted to use it for internal facing APIs, but can only do this with multiple App Gateways. This would mean arbitrarily splitting them up and expecting clients to use different sub domains for different APIs depending on which App Gateway they're on which would be completely non-intuitive.
20 is really too low. It should also support wildcard rule. For multiple sub-domains we are forced to configure separately for each sub-domain. IIS allows binding to *.mydomain.com, an app gateway should also support the same as optional setting.
David Schlum commented
Definitely need this. It just so happens that the project I'm working on with a client has exactly 10 unique domains so with http to https redirects and the https listener, I'm able to make it work. However, if the client wants to add even one more site on their multisite CMS, we'll have to spin up a whole new Application Gateway to the tune of $200/month. This seems like an artificial limitation as I've never seen another firewall strictly limit what amounts to reverse proxies behind it. I come from a Microsoft TMG world and it would be unthinkable to only be able to add 20 sites behind one.
In another month when the client is planning to move another site over to Azure and into their multisite CMS, this becomes a problem. Can support at least punch a number in on the backend to lift this limitation?
I agree with this. Given that most sites will require a HTTP listener to redirect to HTTPS, this limits you to only publishing 10 sites behind each application gateway. If your sites are relatively low traffic, this is a waste of resources to have many application gateways that are mostly idle. There should be no limit on this and it should be up to administrators to decide how many application gateways are needed to support the workload.
Is what you call 'Application Gateway' the same thing as 'Azure Active Directory (AD) Application Proxy' (see https://azure.microsoft.com/en-us/roadmap/pingaccess-for-azure-active-directory/)?
If so, then to go beyond the limit of 20 you would have to purchase a license from PingIdentity.
Jake Edwards commented
This is this the same issue as in the Application Gateway category;
This request should be merged into the above request.
We are also looking to for the same functionality. Is there an ETA on this, or can a listener limit increase be requested?