Azure Front Door - Simply Explained

So imagine you've got a website. Maybe it's an online store, a blog, or a business site. You host it in one place, say a data center in Virginia. That works fine for customers in New York or Chicago. But what about someone in Tokyo, or in London, or in Sydney? Every time that person visits your site, their request has to cross oceans and continents just to reach your server. Each image, each page load, each API call makes the same long journey, and that delay adds up quickly. Actually, studies show that even a one-second delay in page load time can cost you conversions and drive frustrated visitors away. But here's the thing, what happens when your site goes viral, or a botnet decides to attack? Your single server in Virginia gets hammered. It slows down and it can even crash entirely. You're stuck with no backup plan. You can fix the availability problem by building copies of your site in different regions, Tokyo, London, São Paulo. That helps. But now you have a new problem. How do you send each visitor to the right location? You don't want someone in Japan hitting your US server by accident. You need a smart way to route traffic, and that's exactly where Azure Front Door comes in. Meet the global traffic cop, what Azure Front Door is. Think of Azure Front Door as a global traffic cop, not just one at a single intersection, but thousands of them stationed at major intersections all over the world. Every time someone visits your website, the nearest cop steps in and says, you're in Tokyo. The fastest store for you is in Singapore. Let me take you there. So how is this different from a regular load balancer? Most load balancers work at layer four, looking at IP addresses and ports to route traffic. That's fine for basic needs. But Azure Front Door works at layer seven, meaning it understands HTTP and HTTPS traffic. It can look at the URL someone typed, check their browser headers, see what kind of content they're asking for, and make smart routing decisions based on all of that. Instead of just saying, this IP goes to that server, Front Door can say this request for API users goes to your US back end, but this request for images goes to the cashed copy in Tokyo. Now here's what makes this possible behind the scenes. Azure Front Door runs on Microsoft's global network with over 210 points of presence across more than 130 metro locations worldwide. Think of each point of presence as a small traffic booth, a local office in every major city that can handle the initial request quickly. When a user visits your site, they connect to the nearest booth instead of traveling all the way to your origin server in Virginia. That booth then routes their request over Microsoft's private backbone to your back end. This matters because the public internet is unpredictable. Your traffic might take a dozen hops through different networks, each one adding latency and potential packet loss. Microsoft's backbone, on the other hand, is a private high-speed network that connects their data centers directly. So once your request hits that nearest point of presence, the rest of the journey happens on a fast, reliable highway. You get faster load times, lower latency, and a better experience for users everywhere, whether they're in Tokyo, London, or Sao Paulo. And all of this happens automatically without your visitors ever knowing it's there. Three layers of resiliency, how AFD stays up. Now, you might be thinking, this whole global traffic cop idea sounds great, but what happens if the cop itself crashes? If Azure Front Door is the single entry point for your entire app, that's a pretty big single point of failure, right? Microsoft thought about that, they built three layers of resiliency into Front Door, so it almost never goes down. Let me walk you through them. First layer, the Front End. Remember those 210 plus points of presence I mentioned? Each one is a fully independent traffic booth. These pop sit in more than 130 metro locations worldwide, running inside Microsoft data centers and partner location facilities. Every single pop holds multiple racks of servers with edge controllers on top acting as a built-in load balancer. If one server inside a pop fails, the edge controller re-route traffic to a healthy one inside that same pop. And if an entire pop goes down, that's where any cast IP addressing kicks in, your visitors request automatically routes to the next closest pop. No disruption and no manual intervention, it just happens. Second layer, the fallback. But what if a pop he gets overwhelmed? Say there's a massive traffic spike or multiple pops in a region go down at once. The remaining pops might not be able to handle the load. That's when the fallback layer steps in. This is a separate set of pops, tens of them, not hundreds, running the exact same software and architecture. They live only in Microsoft data centers, not partner facilities. When a Front End pop needs to shed some traffic, it shifts requests to this fallback layer, same caching, same routing, same security. Your visitors never notice the difference. They just get their content a little slower, maybe. But they still get it. Third layer, the traffic shield. This is the overseer. Think of it as a global command center that watches the entire front door network. It monitors traffic patterns, load levels, and health across all pops. When it detects that certain pops are getting overwhelmed, it doesn't just wait for the fallback layer to kick in. It proactively shifts traffic by updating how DNS resolves your front door endpoint. It can switch from a global any cast IP to a regional one, moving clients to different sets of pops entirely. It can even cross continents if needed. The traffic shield is what makes Front Door feel almost magical. It's constantly optimizing behind the scenes, adjusting routes before problems ever happen. Now I should mention something here. In October 2025, Azure Front Door suffered a significant outage. A configuration change skipped the safety validations and caused widespread issues across Microsoft 365, Xbox Live and thousands of customer websites. Microsoft learned from it. They removed all asynchronous processing from the configuration pipeline. Now every code path gets tested during rollout. They reduced the rollback time from four hours to one and they're targeting 10 minutes by March, 2026. They're also introducing microcell segmentation to limit any future impact to less than 1% of tenants. The point is, no system is perfect, but Front Door's three layer architecture is designed to survive regional outages, traffic spikes and even some configuration errors. For most applications, that's more than enough. For truly mission critical systems, you can layer Azure Traffic Manager in front of Front Door as a break-class path, but that's an advanced topic for another day. How it directs traffic, rooting and origin groups. So we've got this global traffic cop with over 210 booths and three layers of backup. But how does it actually decide where to send each visitor? That's where origin groups come in. An origin group is basically a collection of your back-end servers. Think of it as your list of stores, the actual places where your website or app runs. You might have one server in North America, one in Europe and one in Asia. They all go into the same origin group. Now Front Door doesn't just blindly send traffic to all of them, it constantly checks if they're alive. That's called a health probe. Every few seconds, each Front Door pop pings your servers by hitting a specific path, usually the root of your site, or a dedicated health endpoint like health. If a server doesn't respond or responds with an error code, Front Door marks it as unhealthy and stops sending traffic there. It's like the traffic cop checking if a store is actually open before sending customers in. But once you have multiple healthy servers, the question becomes, which one should get the visitor? Front Door uses three factors to decide, priority, latency and weight, and they work together in a specific order. First is priority. You can designate one server as primary and another as backup. Set the primary to priority one, the backup to priority two. Under normal conditions, all traffic goes to the primary. If the primary goes down, traffic shifts to the backup. Simple, right? This is great for active passive setups where you want one region to handle everything unless it fails. But what if you want both servers active? That's where latency comes in. If multiple servers have the same priority, Front Door sends traffic to the one with the lowest latency, the fastest response time from the visitor's location. So a user in London gets rooted to your European server while a user in Tokyo gets the Asian one. There's also a sensitivity setting by default 50 milliseconds. If two servers are within 50 milliseconds of each other, Front Door considers them equally fast. That prevents constant switching between servers that are basically the same speed. And when latency is tied, that's where weight comes in. You can assign weights to split traffic between servers. Say you want to test a new version of your app. You could give your current server a weight of 90 and the new one a weight of 10. That means roughly nine out of 10 visitors go to the old version and one out of 10 goes to the new one. This is perfect for gradual roll outs, A, B testing or just balancing load across servers with different capacities. Here's the important thing. All of this happens automatically. You configure the origin group once and Front Door handles the rest. It probes your servers, measures latency, respects priorities and distributes traffic based on weight. And it does all of this at the edge before the request even reaches your back end. That means your servers don't have to figure out where traffic came from or how to root it. They just serve content. Security at the edge, the WAF and beyond. So now let's talk about security. Because Front Door sits at the very edge of Microsoft's network, it's the perfect place to stop attacks before they ever reach your servers. Think of it as a security checkpoint at the entrance to a building. Anyone who wants in has to pass through first. That checkpoint is called the web application firewall or WAF and it's built into both Front Door standard and premium. It blocks common web attacks automatically. Things like SQL injection, where an attacker tries to sneak malicious database commands into a form field or cross-site scripting, where they inject scripts into your pages or de-doss attacks, where they try to overwhelm your servers with traffic. The WAF catches all of this at the edge and drops it before your origin ever sees a thing. Beyond automatic protections, you can also create custom rules. For example, if your site is only meant for customers in Europe, you can block traffic from other regions entirely. Or maybe you've noticed a specific IP range that keeps probing your site, you can block that too. You can also filter based on request headers, URL patterns, or even the browser someone is using, the WAF gives you very specific control over who gets in and who doesn't. Here's where the pricing tears matter. Standard gives you custom WAF rules where you define what to block and allow. Premium goes further by adding managed rule sets powered by Microsoft threat intelligence, which are constantly updated based on real-world attack patterns, Microsoft sees across its entire network. Premium also includes bot protection that blocks automated scrapers, credential stuffers, and other bots automatically. And it adds private link support, which lets you connect to your origins over a private network connection instead of the public internet. That means your backend servers can be completely hidden from the outside world. Only front door can reach them. This is a big deal for security. A lot of attacks don't target the front door. They try to find the back door. If your origin server has a public IP address, attackers can probe it directly and bypass all your front door protections. With private link, that's not possible because the origin has no public endpoint and is only accessible through front door. So even if someone discovers your server's IP, they can't reach it. The result is defense in depth. The Waffblocks application layer attacks, custom rules handle your specific requirements, bot protection stops automated threats, and private link keeps your origins invisible. All of this happens at the edge before traffic even reaches your infrastructure, so your servers stay focused on serving content, not fighting off attacks. Caching, making things even faster. So we've covered routing and security, but there's another feature that makes front door really useful. Caching. Here's the idea, a lot of your website content doesn't change very often. Images, CSS files, JavaScript libraries, product photos, maybe even some HTML pages. If every single visitor has to fetch those from your origin server, your wasting time and bandwidth because the server has to process the same request over and over, sending the same bytes across the internet each time. Caching fixes that by keeping a copy of static content at the edge pop. The next time someone requests that same file, the pop serves it instantly without ever contacting your origin. It's like having a small warehouse next to every traffic booth. Instead of sending every customer back to the main factory, you just hand them what's already on the shelf. The performance difference is dramatic. Instead of a round trip across the ocean, the response comes from a server in the same city. Milliseconds instead of seconds. And your origin server gets a break because it handles fewer requests and can focus on the dynamic stuff that actually needs processing. Now, caching isn't automatic for everything. You control what gets cached and for how long. Front door respects standard cache control headers from your origin, like max-age or smax-age. And you can also configure caching rules directly, overriding your origin's headers if needed. When you update content, you can purge the cache and tell front door to throw away the old copies and fetch fresh ones. That's important for things like product launches or price changes where the new version needs to be visible immediately. Here's the thing. Front door isn't just for static content. Even for dynamic content like APIs, personalized pages, or shopping carts, it still accelerates delivery because once that request hits the nearest pop, it travels to your origin over Microsoft's private backbone instead of the public internet. That private backbone is faster and more reliable than the open web. So even uncached requests get a speed boost. This is one of the key differences between front door and a traditional CDN. A CDN caches static content and that's about it. Front door caches static content and accelerates everything else. It's a two for one deal. Pricing tiers. Which one to choose? All right, let's talk money because that's the big question. How much does this cost? And which tier should you actually pick? Before we get into the numbers, here's why this matters. The tier you choose doesn't just affect the price tag. It also determines the security and features available to protect your application. As your front door comes in three versions, classic is the old one. It still works, but Microsoft recommends against using it for new projects. Classic is on its way out. No new resources after 2025 and full retirement by 2027. So if you're starting fresh, you're looking at standard or premium. Here's the simplest breakdown. Standard costs $35 per month as a base fee. Premium costs $330 per month. That's a big jump. But here's the interesting part. The per gigabyte data transfer rates are identical between both tiers. In North America and Europe, outbound traffic runs about 8.25 cents per gigabyte for the first 10 terabytes. Edge to origin transfer is about 2 cents per gigabyte, same pricing on both. So what does that extra $300 buy you? Features? Premium ads managed waft rules powered by Microsoft threat intelligence, rules that update automatically based on real attack patterns. You also get bot protection, private link support, so your origins stay hidden from the public internet and deeper security analytics. Standard gives you global load balancing, caching, dynamic acceleration, and custom waft rules. You can block IP ranges, countries, or request patterns. You just don't get the managed rule sets or private link. The request charges are different too. Standard costs about $9 per 10,000 requests for the first $250 million. Premium cost about $15 per 10,000. At scale, that difference adds up. So how do you choose? Here's my rule of thumb. If you're running a typical website or API, something that needs global performance and basic security, start with standard. The $35 base fee is affordable, and the custom waft rules handle most common threats. You can always upgrade later if your security needs grow. If you're in a regulated industry, healthcare, finance, government, or if you handle sensitive customer data, premium is worth the extra cost. The managed waft rules catch threats you might not think to block. Private link keeps your origins invisible and bot protection stops automated attacks that standard wouldn't catch. One last thing, if you're only serving static content and don't need routing or security features, a traditional CDN might be cheaper, as your CDN from Microsoft still exists, and for pure static delivery, it's often more cost-effective. But for most real-world applications, where you need routing, security, caching, and acceleration, front door standard is the sweet spot. Putting it all together, a real-world example. Let me walk you through a real-world scenario so you can see exactly how all these pieces work together. Imagine you run an e-commerce site. You have servers in three regions, North America, Europe, and Asia. Your customers are everywhere from Japan to Brazil to South Africa. Without front door, a customer in Tokyo connects directly to your US server. Every image, product page, and checkout request has to cross the Pacific Ocean, that's slow. And if your US server goes down, that customer just sees an error. Now add front door. The customer in Tokyo opens your site. Their browser hits the nearest Azure location. Let's call it Tokyo. That location checks the health of your three servers, all healthy, it measures latency. The Asian server responds fastest. So it routes the request there over Microsoft's private backbone. The page loads in under a second instead of three. Now imagine the Asian server gets overloaded during a flash sale. Front door's health probes detect the increased latency. It starts shifting traffic to the European server, the next best option. Customers still get a fast experience, maybe not quite as fast as the Asian server, but still faster than going all the way to the US. The whole failover happens automatically without anyone touching a configuration. Meanwhile, the wafer runs at the edge. It blocks a SQL injection attempt from a botnet probing your checkout form. It blocks traffic from known malicious IP ranges. And it rate limits requests from an IP that's scraping your product catalog. None of these attacks ever reach your origin servers. Your backend team doesn't even know they happened. And the static content, product images, CSS files, JavaScript libraries, those get cashed at the Tokyo location. The first visitor loads them from the Asian origin. The second visitor gets them from the edge cash instantly. Repeat visitors see near instant load times because everything they need is already sitting at the edge location near them. All of this, faster routing, automatic failover, edge security and cashed content, works together seamlessly. Your customers never know it's there. They just see a fast, reliable site. Here's what to remember. Azure Front Door acts as a global traffic cop rooting users to the fastest server, caching content at the edge and blocking attacks before they reach you. It's built on three layers of resiliency. So even if a region goes down, your site stays up. For most projects, the standard tier at just $35 a month is the sweet spot between performance and cost. Upgrade to premium when you need advanced security or private link. Start small with a single origin and grow from there. Front door scales with you. If your web app has users spread across regions, set up a front door profile today. Even a single server gets global acceleration and security benefits. Subscribe on your favorite podcast platform and share this with someone starting their cloud journey.