Azure Application gateway and APIM. confusing guidance

AndyC3838 6 Reputation points
2024-01-05T17:41:02.3+00:00

Hopefully someone can offer some guidance here that puts this to bed as there seems to be a plethora of articles (within the 'learn.microsoft.com' articles) and the Internet in general, and some seem on the face of it to be contradictory.

This relates to App Gateway, but more specifically with APIM too.

For the most part, I see hub/spoke deployment of vNETs. Sometimes vWAN.. Placing an App Gateway in the Hub seems to make sense to me and is an approach I see most frequently. Traffic comes in, hits the PIP of the APPGW, which has a backend configured of an App service in one of the spokes. vNET peering is already configured (because a decision on Hub/Spoke has already been made and deployed).

But reading the CAF guidance, and various articles it suggests App GW should be deployed with the APP, in the same vNET as the App. Which seems counter-intuitive to me (happy to be told otherwise).

So if you have a hub network, lets say with an Azure firewall in the Hub, and your reason for the AZFW is to force all traffic through it (which is the point of a hub I guess) then you'd have traffic incoming to the APPGW at the spoke ----> AZFW ----> Back to the App in the Spoke... This seems odd to me. Why would you want incoming traffic from the Internet to ingress at a spoke? Doesn't that become a manageability nightmare?

Now, if we add in vWAN, then the articles seem to suggest a different approach (I get that all vNETs are effectively spokes with vWAN). But as you see from the attached diagram, the suggestion is clear that App gateway is a 'shared Service', not a 'dedicated service'. This is what I would expect for something like App gateway, which does seem to fit in with what a makes a good 'shared service (just like APIM).

Screenshot 2024-01-05 at 17.30.19

Another article that suggests this approach is here too https://techcommunity.microsoft.com/t5/azure-architecture-blog/example-reference-network-topologies-for-api-management-in/ba-p/3932001

That link was an article written in September 2023, and is referencing architectures for Medium and large and global deployments of APIm with an APP Gateway (no vWAN). All state adding the App gateway to the Hub alongside the APIM and AZFW.

But then we have the several other docs that state the guidance is to place the AppGw in the spoke. So which is it?

If having the AppGWs in the spoke with each App is the guidance, what are the key design decisions that led to this being the recommendation? I'm happy to modify my general approach, but I don't just follow 'best practice' blindly and need to see the justification.

Thanks in advance all..

Azure API Management
Azure API Management
An Azure service that provides a hybrid, multi-cloud management platform for APIs.
1,801 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.
970 questions
{count} votes

1 answer

Sort by: Most helpful
  1. ChaitanyaNaykodi-MSFT 23,421 Reputation points Microsoft Employee
    2024-01-05T23:14:31.5566667+00:00

    @AndyC3838

    Thank you for reaching out.

    The different architectures you described can be used for different purposes and deploying Azure Application Gateway in the Hub or in the spoke will depend on your requirements.

    For example, as documented here: In most systems, Azure Firewall Premium is a shared resource. But Web Application Firewall can be a shared network device or an application-specific component. For the following reasons, it's 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.

    Based on your question above

    So if you have a hub network, lets say with an Azure firewall in the Hub, and your reason for the AZFW is to force all traffic through it (which is the point of a hub I guess) then you'd have traffic incoming to the APPGW at the spoke ----> AZFW ----> Back to the App in the Spoke... This seems odd to me. Why would you want incoming traffic from the Internet to ingress at a spoke? Doesn't that become a manageability nightmare?

    I understand your concern here, although based on some common customer scenarios I have come across - A organization has a centralized firewall deployment using which they apply certain firewall policies and rules for the whole organization. Now suppose a specific team wants to deploy Web Application and expose it via Azure Application Gateway as mentioned in the 3rd point above it will be beneficial for them to deploy the Application Gateway in a spoke Vnet so that it is easier for them to maintain the Application Gateway and analyze the WAF alerts and as they will send the traffic via centralized Azure Firewall it will also help satisfy the organizational requirements.

    User's image

    I understand this will not be a requirement for every customer and it is completely fine to deploy an Azure Application Gateway in the Hub Network if that satisfies the requirement.

    Additional Architecture references for Azure Application Gateway and Azure Firewall

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

    Hope this helps! Please let me know if you have any additional questions or need any information for APIM service. Thank you!


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

    0 comments No comments