11/04/2025
𝗠𝘆 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻 𝗳𝗼𝗿 𝘁𝗵𝗲 𝗔𝘇𝘂𝗿𝗲 𝗙𝗿𝗼𝗻𝘁 𝗗𝗼𝗼𝗿 𝗢𝘂𝘁𝗮𝗴𝗲
Last week, Azure Front Door had a global outage that affected many services.
The suggestion was to use Azure Traffic Manager in front of Front Door which is actually just one part of the puzzle.
We might think of bypassing Front Door and connecting directly to the origin, but in some architectures, the origin might be private.
For example, a private AKS cluster or an app backend sitting behind a private IP address.
So I wanted to find a way to still use Traffic Manager as the failover mechanism without exposing the origin to the internet.
𝗔𝗱𝗱𝗶𝗻𝗴 𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗚𝗮𝘁𝗲𝘄𝗮𝘆
The solution that came to mind was to add an Azure Application Gateway in front of the private origin.
This way, Traffic Manager routes traffic to the Application Gateway instead of directly to the backend.
The Application Gateway can have both a public and private IP address and can be deployed inside your VNET (or in a peered one).
From there, it connects privately to the backend. In my case, a private Load Balancer in front of a private AKS cluster.
The main tradeoff compared to Front Door is that we lose the global edge benefits (like caching and the worldwide presence), but we keep the 𝗪𝗔𝗙 𝗽𝗿𝗼𝘁𝗲𝗰𝘁𝗶𝗼𝗻 and 𝗽𝗿𝗶𝘃𝗮𝘁𝗲 𝗰𝗼𝗻𝗻𝗲𝗰𝘁𝗶𝘃𝗶𝘁𝘆 𝘁𝗼 𝘁𝗵𝗲 𝗼𝗿𝗶𝗴𝗶𝗻.
𝗧𝗵𝗲 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲
Check the diagram below for a visual overview of the setup 👇
• Traffic Manager handles the global failover logic
• Application Gateway acts as the regional WAF and routes traffic privately
• AKS remains private and accessible only within the network
So even if Front Door goes down again, Traffic Manager can redirect traffic to the Application Gateway endpoint, and everything keeps running securely.
If you’re using private endpoints and private links behind Front Door, this setup might be helpful.
It’s a simple way to improve resiliency without compromising on network isolation.
Would love to hear if anyone else approached it differently.