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

Matthew Josephs 21 Reputation points

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:

Azure Virtual Network
Azure Virtual Network
An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.
2,278 questions
Azure Application Gateway
Azure Application Gateway
An Azure service that provides a platform-managed, scalable, and highly available application delivery controller as a service.
1,006 questions
0 comments No comments
{count} votes

Accepted answer
  1. GitaraniSharma-MSFT 49,356 Reputation points Microsoft Employee

    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:

    • 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.


    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.

1 additional answer

Sort by: Most helpful
  1. Jessie 85 Reputation points

    Hello @GitaraniSharma-MSFT

    Thank you for the clarifications.

    We are considering setting up multiple Listeners for the application gateway in our environment.

    The document below bellow describes the pricing system for application gateway but not regarding listeners.

    Hence, the reason for my questions.

    1.Are there costs associated with listeners?

    If yes, please provide a document that helps understand its pricing.

    1. Can the same SAN license be applied to different listeners?