Azure application gateway as a shared resource in a hub & spoke network topology

Question

According to the Microsoft Cloud Adoption Framework, it is not recommended to deploy an application gateway in a hub vnet to be used as a shared resource for applications living in peered spoke vnets. Can anyone explain why this is the case?

I am looking at the potential cost and private IP address savings from deploying a central application gatway to be used with multiple public facing web apps on a multisite listener.

For reference, the article can be viewed here: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/traditional-azure-networking-topology

Answer 1

Hello @Matthew Josephs ,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

I understand that you would like to get clarification on the following statement which is mentioned in Microsoft Cloud Adoption Framework Traditional Azure networking topology documentation - "Don't deploy Layer 7 inbound NVAs, such as Azure Application Gateway, as a shared service in the central-hub virtual network. Instead, deploy them together with the application in their respective landing zones".

You can find the reasons in the below documentation on why it is usually best to treat Application Gateway as an application component and deploy it in a spoke virtual network:

https://learn.microsoft.com/en-us/azure/architecture/example-scenario/gateway/application-gateway-before-azure-firewall#hub-and-spoke-example

• It can be difficult to troubleshoot Web Application Firewall alerts. You generally need in-depth knowledge of the application to decide whether the messages that trigger those alarms are legitimate.
• If you treat Application Gateway as a shared resource, you might exceed Azure Application Gateway limits.
• You might face role-based access control problems if you deploy Application Gateway in the hub. This situation can come up when teams manage different applications but use the same instance of Application Gateway. Each team then has access to the entire Application Gateway configuration.

However, this is just a recommendation considering a few specific conditions, which might change depending upon your need and requirement. If the above conditions don't affect your setup, you can also deploy the Application gateway in your Hub Vnet without any issues.

An application gateway can communicate with instances outside of the virtual network that it's in, as long as there's IP connectivity. If you use internal IPs as backend pool members, you must use virtual network peering or a VPN gateway. Virtual network peering is supported and beneficial for load-balancing traffic in other virtual networks.

Refer: https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-faq#can-application-gateway-communicate-with-instances-outside-of-its-virtual-network-or-outside-of-its-subscription

https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-components#backend-pools

Kindly let us know if the above helps or you need further assistance on this issue.

---

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.