Start with the one-sentence idea, then build up the picture slowly.

Azure Front Door is a managed Azure service that acts as a global, secure, and fast entry point for web applications. Users around the world connect to Front Door first, and Front Door then connects to your actual application servers, which are called origins. Along the way it can speed up delivery, spread the load, protect against attacks, and switch to a healthy origin when another one fails.

Let us define a few words before going on. A web application is a program that people use through a web browser, such as an online shop or a banking site. A request is a message from a browser asking for something, such as a page or a picture, and the response is the answer. HTTP and HTTPS are the standard languages that browsers and web servers use to talk, with HTTPS adding encryption so that outsiders cannot read the messages. An origin is the place where your content really lives, such as a web app, a storage account, or a server.

Front Door works at what is called Layer 7 of the network model. Network communication is often described in layers, from physical cables at the bottom to applications at the top. Layer 7 is the application layer, where web requests live. A Layer 7 service can read the web address, the headers, and the type of request, which lets it make clever decisions such as “send requests for pictures to the storage account, and requests for the shopping basket to the application servers”.

The word global is important. Front Door is not tied to one region. It uses Microsoft’s worldwide network of edge locations, also called points of presence, which are sites placed close to users in many countries. The user connects to the nearest one, and from there traffic travels to your origin over Microsoft’s fast private network instead of the unpredictable public internet.

To see why a global front door helps, look at what goes wrong without one.

When a person opens a website, their browser first turns the website name into an address, then opens a connection to the server at that address, then asks for the page. If the server is in the same city, all this takes a few thousandths of a second. If the server is on the other side of the planet, every step takes much longer, because data must travel through many cables and routers.

Distance adds delay

Data cannot travel faster than light, and in real cables it is slower still. A message crossing an ocean takes a noticeable fraction of a second each way. Opening a secure connection needs several back-and-forth messages before any page content flows, so the delays multiply. A visitor far from your server may wait a second or more before seeing anything, and people leave slow sites.

The public internet is unpredictable

The public internet is a patchwork of networks run by many companies. Routes between two places may be long, congested, or change without warning. A user’s request may take a slow route one minute and a fast one the next. A private, well-managed network between the edge and your origin gives more predictable results.

Attacks arrive from everywhere

Any public website attracts unwelcome visitors. Some send huge floods of fake requests to knock the site over, called denial of service attacks. Others probe for weaknesses, such as sending crafted input that tricks a poorly written program into revealing data. Automated programs, called bots, scrape content, stuff stolen passwords into login pages, or buy up limited stock. Defending each server individually is hard and costly.

Servers fail and regions fail

Servers crash, deployments go wrong, and sometimes a whole region has trouble. If users are tied directly to one server or one region, they see errors until it is fixed. A smart entry point can notice the problem and send users elsewhere.

Repeating the same work

Thousands of users often request the very same image, script, or page. Fetching it from the origin every time wastes time and money. Keeping a copy close to users, called caching, answers repeat requests instantly and shields the origin.

Every service exists because somebody had a painful problem. Here are the main ones.

A sudden global audience

Imagine a small company whose product goes viral overnight. Visitors arrive from dozens of countries. Without a global front door, its one server in one region slows to a crawl. With Front Door, popular content is served from the edge near each visitor, and only the necessary requests reach the origin.

One address, many back ends

Modern applications often consist of several parts: a web front end, an application programming interface, an image store, and perhaps an older system. Users should see one website name, while behind it different parts handle different paths. Front Door can present one name and route each request to the right part.

Safe updates and migrations

When moving an application from one region to another, or from an old system to a new one, Front Door can shift traffic gradually using weights, sending a small share to the new origin first. If something goes wrong, the share is turned back. This reduces the risk of big-bang changes.

Nine building blocks. Learn these and the rest of the topic becomes easy to follow.

Profile and endpoint

A profile is the top-level Azure resource for Front Door, which holds all your settings and has a tier, Standard or Premium. Inside a profile you create one or more endpoints. An endpoint is a named entry point with its own address, which users or your custom domain names point to.

Custom domain

A custom domain is your own website name, such as www.example.com, attached to an endpoint, so that users never see the Azure address. You prove you own the name, and Front Door can provide and renew the secure certificate for it.

Origin and origin group

An origin is one back-end location where your content lives, such as a web app, a storage site, or a server with a public address. An origin group is a set of origins that can serve the same content, together with the settings for health checks and load balancing between them.

Route

A route links endpoints and domains to origin groups. It says, for example, “requests for this domain whose path starts with /images should go to the storage origin group”. It also holds settings for caching, redirects, and which protocols to accept.

Rule set

A rule set is a collection of rules that change requests or responses as they pass through. Rules can add or remove headers, rewrite addresses, redirect users, or override caching behaviour, based on conditions you define.

Health probe

A health probe is a small, regular test sent from Front Door to each origin, asking “are you alive and ready?”. Origins that fail are taken out of rotation.

Web application firewall

A web application firewall, or WAF, is a filter that inspects web requests for signs of attack and blocks or logs them according to rules. Front Door can have a WAF policy attached.

Caching

Caching means keeping copies of responses at the edge so repeat requests are answered without contacting the origin.

Edge location

An edge location, or point of presence, is one of the many sites in Microsoft’s worldwide network where users connect, close to where they live.

How the pieces fit together, from the user’s browser to your origin.

Look at the diagram below from left to right. A user’s browser connects to the nearest Front Door edge location. There, the connection is secured, the request is checked by the WAF, and Front Door decides whether it can answer from its cache or must go to an origin. If it must go to an origin, it chooses one from the origin group according to health and routing settings, and forwards the request over Microsoft’s private network.

flowchart LR
    U["User browser"] --> E["Nearest edge location"]
    E --> W["Web application firewall"]
    W --> R["Route and rule set"]
    R --> C{"Cached copy available?"}
    C -->|"Yes"| A["Answer from the edge"]
    C -->|"No"| OG["Origin group"]
    OG --> O1["Origin in Region 1"]
    OG --> O2["Origin in Region 2"]

A global control plane, a distributed data plane

In networking, the control plane is where you set up and change configuration, and the data plane is where traffic actually flows. You make your changes in one place in Azure, and Microsoft distributes them to the edge locations around the world. The traffic itself is then handled locally at whichever edge location is nearest to each user. Configuration changes take some time to spread, so do not expect them to be instant.

Anycast and the nearest edge

Front Door uses a technique called anycast, in which the same address is announced from many places at once, and the network naturally sends each user to the closest one. Users do not choose an edge location, and you do not either. The internet’s routing does it automatically, and if one edge location has trouble, traffic flows to another.

Split connections

Front Door splits the journey into two connections. One is between the user and the nearby edge, which is short and quick. The other is between the edge and your origin, which travels over the Microsoft network and is reused for many requests. This split means the slow connection setup happens only over a short distance, and the long hop already has a warm, open connection. The result is a faster page even when the content is not cached.

What Microsoft manages and what you manage

Microsoft manages the edge locations, the network, the platform’s capacity, and the protection against large floods. You manage the configuration, which includes the domains, certificates, routes, rules, caching choices, WAF policy, and the origins themselves, including their security, scaling, and updates. This is the shared responsibility model.

What happens between “a request arrives at the edge” and “an origin is chosen”.

When a request arrives, Front Door first finds the matching route. It compares the domain name and the path of the request with the patterns in your routes, and the most specific match wins. The route points to an origin group, and may also apply a rule set that changes the request.

Choosing an origin within the group

Within the origin group, Front Door chooses an origin using three ideas working together: health, priority, and weight, plus a measure of speed called latency.

Measuring latency

Front Door’s health probes also measure how long each origin takes to respond. Using these measurements, it can favour origins that are closer or quicker for the edge location serving the request. A setting called latency sensitivity defines how much slower an origin can be and still count as equally good. Within that band, the load is shared by weight. This lets users be served by nearby regions automatically.

flowchart TD
    REQ["Request needs an origin"] --> H["Remove unhealthy origins"]
    H --> P["Keep origins with the best priority"]
    P --> L["Keep origins within the latency tolerance of the fastest"]
    L --> WGT["Share traffic by weight"]
    WGT --> SEL["Chosen origin receives the request"]

Session affinity

Some applications want a user to keep going to the same origin, for example when the server remembers user information in its own memory. Front Door can set a cookie so that returning requests from a browser go to the same origin as before, as long as that origin stays healthy. As with any stickiness, it can unbalance load, and a better design stores session data in a shared store so any origin can serve any user.

Host headers

Every web request carries a host header, which names the website the user asked for. Front Door can forward the original name, or replace it with the name of the origin. Many Azure web services decide what to serve based on this header, so a mismatch is a common reason for puzzling errors. Check that the origin expects the name you are sending.

The life of a request, and the life of a Front Door project.

The path of one request

Follow one visit. The user types your website name. The domain name lookup directs them, through your DNS settings, to your Front Door endpoint. The browser connects to the nearest edge location and secures the connection using your certificate. The edge location checks the WAF rules. It finds the route, applies any rules, and looks in its cache. If the content is cached and still fresh, it is returned immediately. If not, Front Door forwards the request to a chosen origin, receives the answer, optionally stores a copy in the cache, and returns the response to the user.

flowchart LR
    A["Plan domains and origins"] --> B["Create profile and endpoint"]
    B --> C["Add origin group and health probe"]
    C --> D["Create route and rule sets"]
    D --> E["Add custom domain and certificate"]
    E --> F["Attach WAF policy"]
    F --> G["Lock down the origins"]
    G --> H["Switch DNS and test"]
    H --> I["Operate and monitor"]
    I --> J{"Changes needed?"}
    J -->|"Yes"| D
    J -->|"No"| I

Waiting for changes to spread

After you change settings, there is a delay while the new configuration reaches all edge locations. During this short window, different edge locations may briefly behave differently. When making important changes, wait for the deployment to complete and test before announcing success.

Switching DNS safely

The final step, switching your website name to point to Front Door, is the moment of truth. Lower the lifetime of the old DNS record in advance, so that users move quickly, and keep the old route available until you are confident the new one works. Test the whole application through the Front Door address before switching, including login, uploads, and any special paths.

The fastest request is the one that never reaches your server.

Caching is one of the biggest benefits of Front Door. When a response is cacheable, Front Door stores a copy at the edge location that served it, and later users of that edge location receive the stored copy at once. This cuts delay, saves your origin from repetitive work, and lowers cost. Images, style sheets, scripts, downloads, and pages that are the same for everybody are classic candidates.

How long copies live

The origin tells Front Door how long a response may be kept, usually through headers on the response that give a lifetime. You can also override this in the route or in rules. Short lifetimes keep content fresh but increase trips to the origin, and long lifetimes do the opposite. A common pattern is to give files with a version in their name, such as a script with a build number, a very long lifetime, since a new version gets a new name.

Query strings

A query string is the part of a web address after a question mark, which often carries search terms or tracking tags. You choose whether Front Door treats different query strings as different pages. Ignoring them gives a better hit rate but may serve the wrong content if the page really depends on them. Treating each as different is safer but caches less.

What not to cache

Pages that differ for each user, such as an account page or shopping basket, must not be shared among users. Mistakes here can show one customer’s data to another. Mark such responses as not cacheable, and be careful with rules that force caching. When in doubt, cache only static files and publicly identical content.

Purging

Sometimes you need to remove a cached copy early, for example after publishing a correction. Front Door lets you purge specific paths or everything, which removes cached copies from all edge locations. Plan how you will purge before you set long lifetimes.

Compression and protocols

Front Door can compress text-based files, such as pages and scripts, so they travel in fewer bytes, which speeds up delivery on slow links. It also supports modern protocol versions that load pages more efficiently. These features usually need only a switch to enable them.

Acceleration for dynamic content

Even content that cannot be cached benefits from the split connection and the private network, as described in Chapter 5. This is sometimes called dynamic site acceleration. It will not make a slow database faster, but it removes avoidable network delay.

flowchart TD
    Q["Request arrives at the edge"] --> K{"Cached copy present?"}
    K -->|"No"| F["Fetch from the origin"]
    K -->|"Yes"| FR{"Copy still fresh?"}
    FR -->|"Yes"| S["Serve the cached copy"]
    FR -->|"No"| F
    F --> CA{"Response allowed to be cached?"}
    CA -->|"Yes"| ST["Store a copy at the edge"]
    CA -->|"No"| SV["Pass it through without storing"]
    ST --> SV2["Return the response to the user"]
    SV --> SV2

Choosing the right tier and understanding the bill.

Azure Front Door is offered in tiers. The names, features, and prices change over time, so treat the descriptions below as the general shape, and confirm the current details in Microsoft’s documentation.

What makes up the bill

Front Door is generally billed on several things: a base fee for each profile, charges for the number of requests that come in, and charges for the data that flows from the edge to users and from the edge to origins. The web application firewall adds its own charges for policies, rules, and requests inspected. Prices differ by region and tier. Use the Azure pricing calculator with your real traffic numbers, because costs depend heavily on volume.

Ways to save

• Cache aggressively where safe. A cache hit is cheaper than fetching from the origin, and it also relieves the origin’s own costs.
• Compress text content. Fewer bytes mean lower data charges and faster pages.
• Keep responses lean. Optimise images and scripts so the same pages move fewer bytes.
• Share a profile. Several sites can share one profile, avoiding repeated base fees, where design and management allow.
• Remove unused resources. Delete forgotten test profiles, routes, and WAF policies.
• Block junk traffic early. Stopping bad bots at the edge reduces both costs and load.

Servers fail and whole regions occasionally do too. Good design expects that.

Availability means your application is reachable and working. Front Door improves availability by checking the health of every origin and steering traffic only to healthy ones. It also runs across many edge locations, so the loss of one edge site does not stop the service.

How health probes work

Front Door sends small requests to each origin at a regular interval, from many edge locations. The request goes to a path you choose, using HTTP or HTTPS. An origin that answers with a successful response counts as healthy. After enough failures in a row, the origin is marked unhealthy and receives no new traffic. When the probes succeed again, it returns to rotation.

flowchart TD
    FD["Front Door probes every origin"] --> A{"Primary origin healthy?"}
    A -->|"Yes"| P["Send traffic to the primary region"]
    A -->|"No"| B{"Backup origin healthy?"}
    B -->|"Yes"| S["Send traffic to the backup region"]
    B -->|"No"| ERR["Return an error to users"]
    P --> RE["Keep probing"]
    S --> RE
    RE --> A

Designing the probe

Point the probe at a small, light page that checks the things your application truly needs, such as the ability to reach its database. Avoid using the home page, which may be heavy. Remember that probes come from many edge locations, so a busy site can receive a lot of probe requests, and an expensive probe page adds real load. The probe path should be cheap, fast, and reliable. Also set the probe frequency so that failures are noticed in a reasonable time without causing false alarms.

Active-active and active-passive

You can arrange origins in two classic ways. In an active-active design, several regions serve users at once, and Front Door shares traffic between them, favouring the quickest. If one fails, the others absorb its share. In an active-passive design, one region serves all traffic, and a second sits ready on a lower priority, used only if the first fails. Active-active makes better use of resources and speeds up distant users, but it requires the application and its data to work across regions. Active-passive is simpler, but the backup region may sit idle most of the time.

Data matters too

Front Door can move web traffic to another region, but it cannot move your data. If the application in the second region needs the same database, you must replicate or share that data using database features. Failover for the web tier without a plan for the data tier gives you a working website that shows wrong or missing information.

Test failover

Practise by stopping an origin in a test environment, watching the probes mark it unhealthy, and confirming that users are served from the backup. Check how long detection takes, and what users see in the meantime. It is far better to discover surprises in a drill than in a real outage.

Small changes to requests and responses that solve big practical problems.

Rule sets let you change requests and responses as they pass through Front Door, without touching your application. Each rule has conditions, which describe which requests it applies to, and actions, which describe what to do. Conditions can look at the path, the file type, the device type, the country the request came from, headers, query strings, and more.

Redirecting to secure connections

One of the most common rules sends everyone who arrives on an unencrypted address to the encrypted version. This ensures users end up on a secure connection even if they type the plain address or follow an old link.

Security headers

Browsers respect special response headers that make attacks harder, such as instructions limiting where scripts may load from, or forcing browsers to use secure connections. Adding these at Front Door gives consistent protection across all your applications, even older ones that cannot easily be changed.

Passing along the real client address

Because the origin sees connections coming from Front Door, not from the user, it needs another way to learn the real address of the user. Front Door passes it in a header, and applications and logging tools should read it from there. Without this, logs show the same few addresses for everyone, and rate limits or location rules misfire.

Order and clarity

Rules run in a defined order, and later rules can undo or conflict with earlier ones. Keep rule sets small and well named, document why each rule exists, and test changes carefully. A tangled pile of rules is a common source of mysterious behaviour.

Stopping bad traffic at the front gate, and making sure there is no back door.

The web application firewall

A web application firewall inspects each request against a set of rules. Managed rule sets, maintained by Microsoft, cover well-known attack types, such as attempts to slip database commands or harmful scripts into web forms. You can also write custom rules, for example to block certain countries, to allow only certain addresses to reach an admin page, or to limit the number of requests one visitor may make per minute. Bot protection rules help to identify automated visitors, separating helpful ones, such as search engines, from harmful ones.

Detection and prevention modes

A WAF policy can run in detection mode, where it only records what it would have blocked, or in prevention mode, where it actually blocks. A wise rollout starts in detection mode, studies the logs for false positives, which are legitimate requests flagged by mistake, tunes the rules, and only then switches to prevention. Staying in detection mode forever gives a false sense of safety.

flowchart TD
    R["Request reaches the edge"] --> C1{"Matches a custom rule?"}
    C1 -->|"Block"| X["Request blocked"]
    C1 -->|"Allow or no match"| C2{"Matches a managed rule?"}
    C2 -->|"Yes - prevention mode"| X
    C2 -->|"Yes - detection mode"| LOG["Log the match and continue"]
    C2 -->|"No"| OK["Request continues to the route"]
    LOG --> OK

Protection against floods

Because traffic enters at many edge locations, large floods are spread out and absorbed across the global network before they reach your origin. Front Door works together with Azure’s platform protection against network-level attacks. Rate limiting rules add protection against floods of ordinary-looking requests that aim to exhaust your application.

Certificates

For HTTPS, Front Door needs a certificate, which is a digital document proving that the site is who it claims to be. Front Door can create and renew a certificate for your domain automatically, which removes a common cause of outages: forgotten expiry dates. Alternatively, you can use your own certificate stored in Azure Key Vault, a secure vault for secrets. Use modern protocol versions and disable old, weak ones.

Closing the back door

The most important origin protection is making sure the origin accepts traffic only from Front Door. Otherwise, attackers can find your origin’s direct address and bypass the WAF entirely. There are two common ways. First, restrict the origin’s network rules to the address ranges that belong to Front Door’s back end. Second, have the origin check a special identifier header that Front Door adds to every request, and reject requests without the right value. In the Premium tier, a private link connection lets Front Door reach the origin through a private path, so the origin has no public address at all. Using both network restrictions and an identifier check is a strong combination.

Security checklist

• Attach a WAF policy with managed rules, and move from detection to prevention after tuning.
• Add custom rules for rate limits, geographic needs, and protected admin paths.
• Use automatic certificates where possible, and keep protocol versions modern.
• Force HTTPS by redirecting plain connections to secure ones.
• Lock down origins so only Front Door can reach them, or use private links in Premium.
• Add security headers in rules for consistent browser protection.
• Control who can change the configuration with role-based access, and review changes, because one wrong rule can take a site offline.
• Send logs to a central workspace and review WAF events regularly.

You cannot manage what you cannot see. Here is what to watch.

Monitoring means continuously checking the health and behaviour of your system. Metrics are numbers measured over time. Logs are written records of individual events. Front Door sends metrics to Azure Monitor, and you can send logs to a central workspace through diagnostic settings. You can then set alerts, which are automatic messages triggered when a number crosses a line you choose.

Logs worth collecting

Access logs record each request, including the path, the status code, the edge location, the origin used, and how long it took. Health probe logs record what the probes saw at each origin. WAF logs record the rules that matched and the action taken. Together they tell the story of any problem, but they can grow large and cost money to store, so choose what to collect and set a retention period.

Telling who is at fault

When users report slowness or errors, the first question is where the problem lies. Compare total latency with origin latency. If both are high, the origin is slow. If only total latency is high, look at the connection to the edge, cache misses, or large responses. If errors appear in access logs with a status from the origin, the origin is failing. If errors come from Front Door itself, such as a rule, WAF block, or routing mistake, the cause is in your configuration.

Troubleshooting step by step

Azure offers several traffic services. Compare before you choose.

Features and product lines change over time. In particular, Front Door includes content delivery features, and Microsoft has been consolidating its content delivery offerings, so confirm current capabilities and retirement notices before you design around any of them.

Front Door and Application Gateway

These two are often confused, because both work with web traffic and both offer a web application firewall. The main difference is scope. Front Door is global and sits at the edge, close to users, and routes between regions. Application Gateway is regional, sits inside your virtual network, and distributes traffic among servers within a region. They are often used together: Front Door as the global entry, and Application Gateway as the regional manager in front of the servers. Be careful to avoid duplicating protection or adding delay without a reason.

Front Door and Traffic Manager

Traffic Manager works through DNS, by answering name lookups with the address of a suitable endpoint. It never sees the traffic itself, so it cannot cache, inspect, or protect it, and its failover speed depends on DNS lifetimes. Front Door handles the actual connection, so it can fail over faster and add many features, but it works only for web traffic. Use Traffic Manager for non-web protocols or very simple needs.

A simple decision guide

flowchart TD
    Q1{"Is the traffic web HTTP or HTTPS?"} -->|"No"| Q4{"Need DNS-level steering across regions?"}
    Q1 -->|"Yes"| Q2{"Users in many regions or need edge protection and caching?"}
    Q2 -->|"Yes"| FD["Use Azure Front Door"]
    Q2 -->|"No"| AG["Application Gateway may be enough"]
    Q4 -->|"Yes"| TM["Consider Traffic Manager"]
    Q4 -->|"No"| LB["Use Azure Load Balancer"]

Layering them together

A typical large design uses Front Door at the global edge for speed, caching, and protection, with origins in two or more regions. In each region, an Application Gateway or a load balancer spreads traffic among the servers. This layered design matches each service to the job it does best.

Every design choice gives something and takes something. Be honest about both sides.

The central trade-off

The big trade-off is capability versus complexity. A global front door gives speed, security, and resilience, but it adds new concepts, such as routes, rules, caching, and WAF tuning, and a new place for things to go wrong. A small site with local users may not need all that, while a global application will find it worthwhile.

Freshness versus speed

Caching speeds things up, but cached content can be out of date. Short lifetimes keep content fresh but reduce the benefit. For each kind of content, decide how stale it may be, and set lifetimes and purging procedures to match.

Protection versus false alarms

Strict WAF rules block more attacks but may also block real users. Loose rules let more attacks through. The answer is careful tuning, starting in detection mode, and reviewing logs, rather than choosing either extreme.

Proven shapes to copy, and common shapes to avoid.

Patterns that work

Anti-patterns

An anti-pattern is a common solution that looks sensible but causes trouble. Here are the usual ones.

A practical list you can print and keep next to your desk.

Best practices

• Choose the tier on purpose. Pick Premium if you need private origins or the richer security features, and plan to leave the Classic version.
• Use at least two origins in different regions, with health probes and clear priorities and weights.
• Lock down the origins so that only Front Door can reach them.
• Design honest, light health pages and tune probe settings carefully.
• Cache what is safe. Version static files, set sensible lifetimes, and never cache personal pages.
• Use automatic certificates and force HTTPS, with modern protocol versions only.
• Roll out the WAF carefully, from detection to prevention, with tuning in between.
• Pass the client address through headers, and make applications read it from there.
• Check host header settings against what each origin expects.
• Test failover and rule changes in a safe environment before production.
• Monitor origin health, errors, latency, cache hit ratio, and WAF activity, and alert early.
• Control change. Use role-based access, review configuration changes, and keep your setup in an infrastructure-as-code tool, which means keeping it in text files so it can be repeated and reviewed.
• Plan the data tier for multi-region designs, because Front Door moves traffic, not databases.

Common mistakes

Four typical situations, described as illustrative examples, showing when the service fits.

The stories below are illustrative composites of the kinds of situations where teams commonly use Azure Front Door. They are not claims about any particular company, but they reflect the reasoning real architects use.

Short answers to the questions beginners ask most often.

Everything important, in one place.

Azure Front Door is a managed, global Layer 7 entry point for web applications. Users connect to a nearby edge location on Microsoft’s network. There, the connection is secured, the request is checked by a web application firewall, routed by rules, and answered from the cache when possible. Otherwise it is forwarded to the best healthy origin over a fast private path. Health probes, priorities, and weights give automatic failover and gradual rollouts, and managed certificates, rule sets, and logs make operation easier.

Remember the comparison we began with: reception desks in hundreds of cities, each greeting local customers, keeping popular dishes warm, and sending special orders to the kitchen. That chain works well only if the kitchens are kept behind a locked door that only the desks can open, if the staff know what may be kept on the shelf and what may not, and if there is a second kitchen ready when the first has a fire. Treat Azure Front Door the same way: lock the origins down, cache with care, tune the firewall before enforcing it, and test failover before you need it.