A global, cloud-based front gate for web traffic, run by Microsoft on its own worldwide network.

Starting with how websites are reached

When you type a website name into a browser, your device asks a system called DNS (the Domain Name System) for the numeric address that belongs to that name. DNS works like a phone book for the internet. Your browser then connects to that address, asks for a page using a language called HTTP, and receives the answer. When the page is private or secure, the conversation is wrapped in encryption called TLS, which is what puts the padlock in the address bar.

The computers that actually hold your website and your application logic are called origins (some people say “back ends” or “origin servers”). An origin might be an Azure App Service, a virtual machine, a container app, a storage account serving static files, or even a server in your own office or another cloud.

What Front Door adds

Without Front Door, every visitor connects straight to your origin. If the origin is in Europe and the visitor is in Australia, every message takes a long trip, and the origin must handle every connection and every attack by itself. Azure Front Door places a smart layer between visitors and origins. Visitors connect to a Front Door location close to them. Front Door then talks to your origins on their behalf using Microsoft’s private global network.

In technical words, Azure Front Door is a global, Layer 7 load balancer, application delivery network, and web application firewall platform. “Layer 7” means it understands the actual web request: the website name, the path, the headers, and cookies. That is why it can make decisions like “send everything under /images to the storage account and everything under /api to the application servers”.

The main jobs it does

A short history

Content delivery networks, or CDNs, grew popular in the early 2000s as a way to place copies of images and videos near readers. Microsoft built its own global edge network to serve products such as Microsoft 365 and Xbox, then opened that technology to customers as Azure Front Door around 2019. Later, Microsoft merged ideas from Azure CDN and Front Door into newer Standard and Premium tiers, and has been moving customers away from the older “classic” versions. Always check Microsoft’s official notices for exact retirement dates of older products.

Azure offers several traffic-routing services. They sound alike, so knowing the differences prevents expensive wrong turns.

Azure has four commonly confused services for moving traffic. Each works at a different level and a different distance from the user.

flowchart TD
    U["Users around the world"] --> TM["Traffic Manager: DNS based routing"]
    U --> AFD["Front Door: global HTTP and HTTPS edge"]
    AFD --> AG["Application Gateway: regional web load balancer"]
    AG --> LB["Load Balancer: regional network level distribution"]
    LB --> VM["Virtual machines and apps"]
    AFD --> APP["App Service, storage, container apps"]
    

Understanding the differences

Traffic Manager only answers DNS questions. It says “go to this address”, and then the visitor connects directly. It never touches the traffic itself, so it cannot cache, cannot filter attacks, and cannot speed up connections. Because answers are cached by devices around the internet, failover can be slow.

Application Gateway understands web requests like Front Door does, but it lives in one region, usually inside your own virtual network. It is a great local traffic cop and local firewall. Load Balancer is simpler still. It spreads connections without reading web content.

What about a normal CDN?

A CDN focuses on caching static files such as images, scripts, and videos. Front Door includes that caching ability, but it also adds smart routing between origins, health checking, a web application firewall, and handling of dynamic content such as API calls. If you need only simple static delivery, a CDN may be enough. If you need an entire global entry point, Front Door is the fuller answer.

A handful of building blocks appear in every Front Door setup. Learn their names and jobs and the rest becomes easy.

Profile

A profile is the container for one Front Door setup. It holds your endpoints, origin groups, routes, rule sets, and security policies. You pick the tier (Standard or Premium) at the profile level.

Endpoint

An endpoint is a public name that Front Door gives you, ending in a Front Door domain. Visitors reach your application through it. You usually place your own friendly name, such as www.yourcompany.com, in front of it using a custom domain.

Custom domain

A custom domain is your own website name attached to an endpoint. Front Door can create and renew a managed certificate for it automatically, so the padlock works without you buying or installing anything. You can also bring your own certificate, stored safely in Azure Key Vault.

Origin and origin group

An origin is one back-end server or service. An origin group is a set of origins that can do the same job, for example the same application deployed in West Europe and in East US. Inside the group you set the health check rules and the load-balancing behavior.

Route

A route is the instruction that connects a visitor’s request to an origin group. It says which domains and which paths it applies to, which protocols are allowed, whether to cache, and which rule sets to apply. Think of it as one line in the airport signboard: “Flights to Paris, use gate 12”.

Rule set

A rule set is a collection of small if-then actions, such as “if the path starts with /old, redirect to /new” or “add this header to every response”. You attach rule sets to routes.

WAF policy and security policy

A web application firewall policy (WAF policy) holds the rules that detect and block malicious requests. A security policy attaches that WAF policy to chosen domains. Section by section, this guide will return to this idea in the security chapter.

flowchart TD
    P["Front Door profile"] --> EP["Endpoint"]
    P --> OG["Origin group with health probe"]
    P --> RS["Rule sets"]
    P --> SP["Security policy with WAF policy"]
    EP --> CD["Custom domain with certificate"]
    EP --> R["Route"]
    R --> OG
    R --> RS
    OG --> O1["Origin one"]
    OG --> O2["Origin two"]
    SP -.-> CD
    

Pick the tier by the protection and private connectivity you need, since you pay for the difference.

How tier choice affects design

Standard works well when your origins are public web services protected by simple rules, such as limiting access by country or rate. Premium becomes attractive when you want your origins to have no public address at all, reachable only through a private connection from Front Door, and when you want Microsoft-maintained rules to catch common attacks without writing them yourself.

The magic of “close to the visitor” comes from how addresses and cables are arranged.

Points of presence

Microsoft operates a large number of edge locations, also called points of presence or PoPs, in cities all over the world. Each one is a small group of powerful servers connected to local internet providers and to Microsoft’s private backbone. When a visitor reaches Front Door, they land on the nearest edge location, not on a faraway data center.

Anycast: one address, many places

Normally an address belongs to one place. With anycast, the same address is announced from many locations at once. The internet’s own routing system then carries each visitor’s traffic to the closest announcing location. So visitors in Mumbai and visitors in Madrid both connect to “the same” Front Door address, yet each lands in a different building near them.

The private backbone

After the edge location, traffic does not wander over the public internet to your origin. It rides Microsoft’s own global fiber network, which has fewer crowded paths, fewer unpredictable delays, and fewer dropped packets. The public internet is used for only the short first hop from the visitor, and sometimes for the last hop to an origin outside Azure.

flowchart LR
    V1["Visitor in Asia"] --> E1["Nearby edge location"]
    V2["Visitor in Europe"] --> E2["Nearby edge location"]
    V3["Visitor in Americas"] --> E3["Nearby edge location"]
    E1 --> BB["Microsoft private global backbone"]
    E2 --> BB
    E3 --> BB
    BB --> OA["Origin in Europe region"]
    BB --> OB["Origin in US region"]
    

Why this matters for speed

Setting up a secure connection takes several back-and-forth messages between visitor and server. Each message crosses the distance once. If the server is on another continent, those messages cost a lot of waiting. If the first server is only a few milliseconds away, the setup finishes quickly. Front Door finishes this setup at the edge, then reuses a long-lived, already-warm connection to your origin. This is the heart of why pages feel faster.

The internal layout, seen from a distance, with the control side and the traffic side kept apart.

Front Door has two sides that never get mixed. The control plane is where you and Azure tools create and change your settings. The data plane is the fleet of edge servers that carry real visitor traffic. Keeping them separate means a busy day on the management side does not slow visitors, and a configuration change can be pushed out to all edge locations safely.

flowchart TD
    ADM["You using portal, templates or command line"] --> CP["Control plane: validate and store configuration"]
    CP --> DIST["Configuration distribution to all edge locations"]
    DIST --> E1["Edge server group A"]
    DIST --> E2["Edge server group B"]
    VIS["Visitors"] --> E1
    VIS --> E2
    E1 --> WAF["WAF and routing engine"]
    E2 --> WAF
    WAF --> CACHE["Edge cache"]
    CACHE --> ORG["Origins"]
    E1 --> LOG["Logs and metrics"]
    E2 --> LOG
    

What the edge server does, step by step, in the few milliseconds before your origin even hears about the request.

TLS termination at the edge

When a visitor opens a secure connection, the edge server presents your certificate and completes the encryption handshake right there. This is called TLS termination. The visitor-to-edge connection is encrypted. Front Door then opens a separate connection to the origin, and you can require that this second connection is encrypted too. Keeping both legs encrypted is called end-to-end TLS, and it is the best practice.

Split TCP

A normal connection between a faraway visitor and a server suffers from slow starts and recovery delays whenever any packet is lost along the long path. Split TCP divides one long connection into two shorter ones: visitor to edge, and edge to origin. Each short connection recovers quickly from small problems, and the edge-to-origin leg is kept open and reused for many visitors. The effect is like a relay race, where each runner covers a short stretch at full speed.

HTTP versions and keep-alive

Modern web connections can send many requests at once over a single link. Front Door supports modern HTTP versions with visitors, and keeps persistent, reusable connections toward origins. Reusing a connection avoids repeating the expensive setup every time.

The request pipeline

Inside the edge server, each request passes through ordered stages. Understanding the order helps you explain surprising behavior.

Headers that Front Door adds

Because the origin now sees Front Door as the caller, the original visitor’s details can be lost. To help, Front Door adds extra headers (small labeled notes attached to a request). One tells the origin the visitor’s original address, another tells which website name the visitor used, and another carries a unique Front Door identifier. Origins can read these to log real visitor addresses and to verify that a request truly came from your Front Door profile.

Follow one visit from the moment a person presses Enter to the moment the page appears.

sequenceDiagram
    participant U as Visitor browser
    participant D as DNS
    participant E as Nearest edge location
    participant C as Edge cache
    participant O as Healthy origin
    U->>D: Look up www.yourcompany.com
    D-->>U: Alias to Front Door endpoint address
    U->>E: Secure connection and request
    E->>E: Firewall check and route match
    E->>C: Is a fresh copy stored
    C-->>E: Not found
    E->>O: Forward request over backbone
    O-->>E: Response
    E->>C: Save copy if allowed
    E-->>U: Response delivered
    

Cache hit versus cache miss

A cache hit means the edge already holds a valid stored copy. The response is quick and the origin does zero work. A cache miss means the edge must go to the origin. Dynamic API calls are usually misses by nature. The share of requests served from the edge is called the hit ratio, and raising it is one of the cheapest ways to improve speed and cut costs.

When things go wrong

If the chosen origin is slow or returns errors, Front Door can retry another origin in the group for many types of requests. If no origin is healthy, the visitor receives an error page generated by Front Door itself. Seeing an error code in logs tells you which side failed: a gateway-style error generally points at the origin side, while a refusal or forbidden code often points at your firewall rules or route settings.

How Front Door chooses among your servers, and how it knows which ones are alive.

Health probes

A health probe is a tiny, regular test request that Front Door sends to each origin, for example asking for a simple status page. If the origin answers correctly, it is considered healthy. If it keeps failing, it is taken out of rotation until it recovers. You choose the path, the protocol, the type of request, and how often to probe.

Good probe design matters. A probe path that only returns “OK” without touching the database may report healthy while the app is broken. A probe path that runs a heavy database check on every request may overload your own servers, since many edge locations probe at the same time. A balanced status page that checks the critical dependencies lightly is the usual answer.

Load-balancing settings

Within an origin group you decide how many recent probe samples to examine and how many must succeed for an origin to count as healthy. You also set a latency sensitivity, a small time margin. Origins whose response times are within this margin of the fastest one are treated as roughly equal, so traffic can spread among them instead of piling on the single fastest.

Origin priority and weight

Each origin has two knobs.

flowchart TD
    R["Request at edge"] --> PR{"Any healthy origin at priority 1"}
    PR -->|"yes"| P1["Choose among priority 1 origins"]
    PR -->|"no"| P2["Choose among priority 2 origins"]
    P1 --> LAT["Keep origins within latency margin of the fastest"]
    LAT --> W["Pick by weight"]
    P2 --> LAT
    W --> OUT["Forward to chosen origin"]
    

Common routing recipes

• Active-active across regions: two or more regions at the same priority, so visitors are served from the nearest healthy one.
• Active-passive: a primary region at priority one and a disaster region at priority two that receives traffic only during failures.
• Gradual rollout: send ten percent of traffic to a new version through a small weight, watch errors, then raise the weight step by step.
• Path-based split: one route for /api to application servers and another for /static to a storage account.

The fastest request is the one your origin never sees.

How caching works

When caching is enabled on a route, the edge stores copies of responses for a time. How long depends on instructions from the origin, usually in a header called Cache-Control, or on a time you set in a rule. While a copy is fresh, later visitors in that region get it straight from the edge. Each edge location keeps its own cache, so the first visitor in a region may see a miss, and the next ones see hits.

What should and should not be cached

Query strings and cache keys

A cache key is the identity used to look up a stored copy. By default it can ignore the part of a web address after a question mark (the query string), or include it. If you ignore it, a page that truly changes by query, such as a search result, could be served wrongly. If you include everything, tiny harmless differences like tracking tags create separate copies and lower the hit ratio. Choose a query-string behavior that matches how your content really varies.

Compression

Front Door can compress text-like files such as pages, style sheets, and scripts before sending, which shrinks the data and speeds up downloads, especially on mobile networks. Already-compressed formats such as most images and videos gain nothing and are skipped.

Purging

If you publish a fix and cannot wait for the old copy to expire, you can purge the cache, telling all edge locations to forget chosen paths. Purges take a short while to spread, and frequent heavy purging defeats the purpose of caching, so prefer versioned file names that naturally avoid stale copies.

The rules engine

A rule set is a list of rules, and each rule has conditions and actions. For example, a condition may check the visitor’s country, the device type, a request header, or the path. Actions can redirect, rewrite the path before it reaches the origin, add or remove headers, override cache time, or even pick a different origin group.

Front Door is a strong place to stop bad traffic, because it sees requests before your servers do.

flowchart TD
    A["Internet traffic including attackers"] --> D["Network level flood absorption at the edge"]
    D --> T["TLS with managed or own certificate"]
    T --> W["Web application firewall"]
    W --> L["Rate limits, geo filters, IP rules"]
    L --> R["Routing to origin"]
    R --> P["Private Link or locked down public origin"]
    P --> S["Origin application with its own checks"]
    

Absorbing floods

A distributed denial of service attack tries to knock a site offline by sending overwhelming traffic from thousands of machines. Front Door’s global edge spreads and absorbs much network-level flooding, so your origin does not face it directly. This is a basic built-in layer, and it complements, but does not replace, a dedicated Azure DDoS protection plan on your own networks when your design requires one.

The web application firewall

A web application firewall, or WAF, reads the content of web requests and blocks ones that look malicious. It targets attacks on the application itself, such as SQL injection (sneaking database commands into form fields) and cross-site scripting (sneaking harmful scripts into pages). Rules come in two flavors.

The WAF has two modes. Detection mode only logs suspicious requests, which is useful for learning what normal traffic looks like. Prevention mode actually blocks them. A wise rollout starts in detection mode, studies the logs for false positives (good requests wrongly flagged), tunes exclusions, and then switches to prevention.

Certificates and encryption

Managed certificates renew themselves, removing a classic cause of surprise outages: the forgotten expiring certificate. You can also set a minimum TLS version to refuse old, weak protocol versions, and require encrypted connections to origins.

Locking the back door

The most common mistake is to protect the front door and forget the back. If your origin still answers anyone on the internet, attackers can bypass Front Door and the WAF by contacting the origin directly. There are three layers of defense.

• Network allow-list: permit only Front Door’s published address ranges, using the Azure service tag for Front Door’s back-end addresses.
• Header check: make the origin require the Front Door identifier header, so requests from other Front Door profiles are refused.
• Private Link (Premium): give the origin no public address at all. Traffic from Front Door arrives through a private connection that you approve.

Staying up when servers, regions, and even parts of the edge have trouble.

Resilience of the edge itself

Front Door is a global service built from many edge locations. If one location has trouble, internet routing sends visitors to another nearby one. You do not choose or manage this. Microsoft publishes an availability promise (an SLA) for the service, and you should read the current version when you need an exact figure.

Resilience of your origins

That part is your design. A single origin is a single point of failure, no matter how good the edge is. The usual pattern places the same application in two or more regions and puts them in one origin group, with health probes watching each.

flowchart TD
    V["Visitors worldwide"] --> FD["Front Door global edge"]
    FD --> OGR["Origin group with health probes"]
    OGR --> R1["Region one: app tier"]
    OGR --> R2["Region two: app tier"]
    R1 --> DB1["Primary data store"]
    R2 --> DB2["Replica data store"]
    DB1 -->|"replication"| DB2
    FD -.->|"if all origins fail"| ST["Static fallback page in storage"]
    

Failure scenarios and responses

Data matters more than traffic

Moving traffic to a second region is the easy half. If the second region has no current copy of the data, or sessions live only in the first region’s memory, failover produces errors rather than recovery. Plan data replication, shared session storage, and capacity at the same time as routing.

A thought about the “single front door”

Using one global service in front of everything means your design depends on it. Some very risk-averse teams prepare a break-glass plan: a documented way to point their domain directly at origins or at an alternative path through DNS, if the front layer ever has a serious incident. This is rarely used, but writing and rehearsing it is cheap compared with improvising in an outage.

Make it faster by moving less data, over shorter distances, with fewer round trips.

Scale without effort at the edge

The edge fleet grows and shrinks on its own with traffic. You do not choose server counts or sizes. What you must scale is your origins, and Front Door helps by absorbing repeated requests through caching, which lowers the load they see during spikes.

The performance toolbox

Measuring what visitors feel

Two numbers matter. Total latency is the time from the edge receiving a request to the visitor getting the whole answer. Origin latency is how long the origin took. The gap between them shows how much time is spent on the edge side and on the network. If origin latency is the large part, tuning the origin application will help more than any edge setting.

Protecting origins from stampedes

When a popular cached item expires, many edge locations may ask the origin for a fresh copy at once. Good cache lifetimes, staggered expiry, and an origin that can handle brief bursts keep this harmless. Front Door also combines identical simultaneous requests for the same cacheable item at one location so that the origin sees fewer duplicates.

You cannot fix what you cannot see, and with a global service you need to see it by region.

Metrics

Metrics are numbers collected over time and shown as charts. The ones to watch from the start are below.

Logs

Metrics tell you that something changed. Logs tell you exactly which request did what. Through diagnostic settings you can send logs to a Log Analytics workspace, a storage account, or an event stream.

• Access logs: one record per request, with the visitor address, the path, the status, the cache result, and timings.
• Health probe logs: every probe result for every origin, so you can see exactly when and why an origin was marked unhealthy.
• WAF logs: which rule matched, which request, and whether it was blocked or only logged.

Keep in mind that busy sites generate a huge amount of log data, which has a storage and analysis cost. Decide which logs you truly need, and set retention accordingly.

Alerts and a simple routine

Setting it up repeatably, moving a live site onto it without a scare, and keeping the bill predictable.

Setting up a new site

The portal is a friendly place to learn, but real projects describe their Front Door setup in text files using infrastructure as code tools such as ARM templates, Bicep, or Terraform. The files say what you want: the profile, tier, endpoints, domains, origin groups, routes, rule sets, and WAF policy. A pipeline then applies them the same way every time, so test and production behave alike and every change can be reviewed like any other piece of work.

Moving a live site safely

The safest path is gradual. First, build the whole Front Door setup and test it using its own endpoint name. Second, lower your DNS record lifetime ahead of time, so a rollback is fast. Third, switch a small slice of traffic if your DNS service supports weighted answers, or switch off-peak. Fourth, watch the metrics closely. Fifth, once stable, restrict the origins and raise the record lifetime again. Always keep a note of the previous DNS values for rollback.

Moving from classic versions

If you use an older classic profile, Microsoft provides migration tools that convert it to a Standard or Premium profile with limited downtime. Start planning early, since official retirement dates are fixed, and test the converted profile before cutting over.

Safe change practice

Because configuration reaches the whole world, treat changes seriously. Review them in a pull request, apply to a test profile first, roll out to production during a quiet hour, and keep the previous version of the files ready for a fast revert.

Understanding and controlling cost

Pricing has several parts, and knowing them helps you predict your bill. Exact rates vary by region and over time, so use Microsoft’s calculator for numbers.

A pattern is a recipe that worked many times. An anti-pattern is a trap that looks tempting and hurts later.

Helpful patterns

flowchart LR
    V["Visitors"] --> FD["Front Door"]
    FD -->|"static path"| ST["Storage account with caching"]
    FD -->|"api path"| API["Regional API services"]
    FD -->|"web path"| WEB["Regional web apps"]
    API --> DB["Data layer"]
    WEB --> DB
    FD -.->|"firewall"| WAF["WAF policy"]
    

Anti-patterns to avoid

A practical checklist to carry into any project.

Mistakes beginners make, and how to dodge them

• Blaming Front Door for origin slowness. Compare total latency and origin latency before touching edge settings.
• Confusing redirect with rewrite. A redirect tells the visitor’s browser to go to a new address. A rewrite quietly changes the path sent to the origin while the visitor’s address stays the same.
• Testing only from one city. Behavior at the edge differs by location, since caches and health views are per location. Test from several places.
• Forgetting the host header. Some origins, especially shared hosting platforms, choose a site based on the host name. Make sure the origin host header is set to what the origin expects.
• Relying only on the edge for security. Keep input checks, authentication, and authorization in the application too.

Four typical situations, described as realistic example setups, showing how the pieces combine.

How to talk about it in an interview

A strong short answer might sound like this: “Azure Front Door is Microsoft’s global Layer 7 entry point. Visitors connect to the nearest edge location through anycast, TLS ends there, and requests ride the Microsoft backbone to the best healthy origin. I use origin groups with priority and weight for failover and canary releases, caching for static content, a WAF for attack protection, and Private Link on Premium to remove public access to origins. I watch total versus origin latency, health probe results, and WAF logs.” Then be ready to explain the reasoning behind each choice using the ideas in this guide.

You have now followed a visitor from the moment of the first name lookup through an anycast edge location, a firewall check, a route match, a cache decision, and a trip over the Microsoft backbone to a healthy origin. The thread through everything is simple: Azure Front Door moves the hard work of speed, protection, and failover to the edge of the network, while you keep responsibility for good origins, honest health checks, careful caching, and locked doors.