Deploying an app to multiple regions sounds straightforward just route traffic, right? That’s what I thought… until I spent 2 whole days chasing a 404.
Here’s what happened, and why choosing the right layer matters more than just picking a tool.
🎯 The Scenario
I had 3 App Services deployed in:
- US
- UK
- India
My goal was simple: users should hit the nearest backend.
So naturally, I picked Azure Traffic Manager after all, it’s literally called “Traffic Manager.”
I added all 3 App Service endpoints, configured health probes, and expected everything to just work.
Spoiler alert: it didn’t.
🐛 The Problem
When I opened the Traffic Manager URL:
https://myapp.trafficmanager.net
I got… 404.
I checked everything:
- Endpoints were online ✅
- Health probes passed ✅
- DNS resolved correctly ✅
Still nothing. Hours went by, trying to fix custom domains, host headers, and SSL bindings.
🔍 The Real Issue
Here’s the key: Traffic Manager works at the DNS layer (OSI Layer 3–4)
- It resolves the user to an endpoint based on latency, priority, or geography.
- It does not handle HTTP(S) traffic (OSI Layer 7).
- It does not rewrite host headers or terminate SSL.
So my App Services were receiving requests with the host header:
Host: myapp.trafficmanager.net
…and they didn’t recognize it. Result? 404 every time.
Even after adding the traffic manager domain to custom domains on each App Service, it sometimes still fails due to SSL/host binding propagation and internal routing quirks.
💡 This is a very common issue in multi-region deployments many developers face it the first time they try Traffic Manager.
⚡ The Solution: Azure Front Door
After losing 2 days, I switched to Azure Front Door:
- Added my 3 App Services as origins
- Accessed
https://<myfrontdoor>.azurefd.net
…and it worked instantly.
Why? Because Front Door operates at the HTTP application layer (OSI Layer 7):
- Handles host header rewrites automatically
- Terminates HTTPS
- Provides WAF, caching, and edge acceleration
- Performs real-time load balancing and failover
In short, Front Door doesn’t just route it actually handles your traffic properly.
🧠 When to Use Traffic Manager vs Front Door
| Scenario | Tool | OSI Layer | AWS Equivalent |
|---|---|---|---|
| DNS-level failover (multi-region) | Traffic Manager | Layer 3–4 (DNS / network) | Route 53 |
| Web apps / HTTP(S) traffic with global load balancing, caching, SSL, WAF | Front Door | Layer 7 (Application) | CloudFront + Global Accelerator + ALB |
| Non-HTTP workloads (DB endpoints, APIs not exposed via HTTP) | Traffic Manager | Layer 3–4 | Route 53 |
| Edge acceleration + application-layer routing | Front Door | Layer 7 | CloudFront + ALB / Global Accelerator |
✅ For most web apps with multi-region deployments, Front Door (or CloudFront/Global Accelerator in AWS) is the better choice.
✅ Traffic Manager (or Route 53 weighted/geolocation routing) is mostly for DNS-level failover.
✅ Key Takeaways
- Understand the OSI layer your tool operates on — DNS/Network (3–4) vs Application (7).
- Traffic Manager ≠ Front Door — don’t confuse names with capabilities.
- Host headers matter — App Services won’t respond to unknown domains.
- Edge acceleration, SSL, and WAF are often just as important as routing.
- This 404 issue is common — you’re not alone if it happens.
👏 Final Thoughts
Sometimes, the simplest goal “just route users to the nearest region” can turn into a multi-day headache if you pick the wrong layer.
Azure Front Door saved me hours, but the lesson stuck: understand what your tool actually does, not just what it sounds like.
Top comments (0)