NetworkingApplication delivery and API edgepremiumtemplate-spec-upgradedfield-manual-complete
Front Door
Azure Front Door is a global entry point for web applications. Instead of sending every user directly to one regional origin, Front Door receives traffic at Microsoft’s edge, applies routing and security rules, and forwards requests to healthy origins such as App Service, Storage, AKS, or external endpoints. It can accelerate static and dynamic content, support custom domains, terminate TLS, integrate with Web Application Firewall policies, and fail over between origins. For users, the goal is faster and safer access. For operators, the goal is central traffic control.
Azure Front Door, AFD, Azure Front Door Standard, Azure Front Door Premium, global edge
Difficulty
intermediate
CLI mappings
5
Last verified
2026-06-02T08:29:00Z
Microsoft Learn
Azure Front Door is Microsoft’s global edge service for modern web applications. Microsoft Learn describes it as a cloud CDN that provides fast, reliable, and secure access to static and dynamic content through Microsoft’s global edge network worldwide.
Front Door sits in the global edge and application delivery layer, in front of regional origins. A profile contains endpoints, routes, origin groups, origins, custom domains, security policies, rules, caching behavior, and WAF integration. DNS points users to the Front Door endpoint or custom domain. Health probes and origin priority determine where requests go, while TLS certificates and routing rules define how hostnames and paths are served. It complements, rather than replaces, regional load balancers, Application Gateway, API Management, and origin-level network controls.
Why it matters
Front Door matters when an application must be reachable, secure, and fast for users in multiple geographies. Without a global edge layer, every user may travel to the same regional endpoint, failover can depend on manual DNS changes, and WAF policy may be duplicated across services. Front Door gives architects one place to manage global entry, TLS, routing, caching, and edge security. It can reduce latency, absorb origin failures through failover, and make migrations safer with traffic splits or route changes. Misconfigured Front Door can also expose origins, cache private content, or route production traffic to the wrong backend, so it deserves careful design.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the Azure portal Front Door profile, operators configure endpoints, routes, origin groups, origins, custom domains, caching, WAF associations, health probes, and custom domain state.
Signal 02
In DNS records, custom hostnames point to Front Door, making the edge endpoint the public entry path instead of each regional origin endpoint directly, improving routing control.
Signal 03
In diagnostic logs and metrics, Front Door exposes edge requests, WAF actions, origin latency, cache status, health probe results, cache status, and routing decisions during incidents.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Put a global edge entry point in front of regional web origins to improve latency and simplify failover.
Centralize WAF, TLS, custom domains, and route rules for several web apps or APIs under one delivery layer.
Migrate users gradually between old and new origins using routes, weights, priorities, and observable health checks.
Protect origins from direct public bypass with Private Link, access restrictions, or origin validation patterns.
Cache static and semi-static content at the edge while preserving dynamic routes for application APIs.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Streaming launch protected from regional origin failure
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A documentary streaming platform expected a premiere spike across Europe and North America. Its single regional origin previously caused buffering and manual DNS failover during high-profile releases.
🎯Business/Technical Objectives
Reduce startup latency for viewers outside the primary region.
Fail over to a secondary origin without manual DNS changes.
Keep WAF protection consistent across both origins.
Limit origin load for cacheable artwork and metadata.
✅Solution Using Front Door
The platform placed Azure Front Door in front of two App Service origins and a storage origin for cacheable artwork. Routes separated video metadata, account APIs, and static image paths. The origin group used priority-based failover, health probes against a real readiness endpoint, and WAF policy in prevention mode for public APIs. Azure CLI exported route, origin, domain, and WAF configuration before the premiere, then a pipeline ran cache purges for updated artwork. Synthetic tests from four regions verified that failed health probes moved API traffic to the secondary origin while static assets remained cached at the edge.
📈Results & Business Impact
Median non-US metadata latency improved 41% during launch week.
A simulated primary-origin outage failed over in 74 seconds without DNS changes.
Origin requests for artwork dropped 58% because cache rules matched static paths.
WAF policy tuning reduced false positives to below 0.3% before premiere traffic arrived.
💡Key Takeaway for Glossary Readers
Front Door gives global applications a controlled edge layer where performance, failover, and security can be tested before the audience arrives.
Case study 02
Freight portal migration completed path by path
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A freight brokerage modernized its customer portal from virtual machines to AKS. A big-bang cutover was risky because carrier rating, tracking, and invoice paths changed at different speeds.
🎯Business/Technical Objectives
Move traffic gradually without changing customer bookmarks.
Keep legacy and AKS origins behind one hostname.
Measure path-level latency and errors during migration.
Rollback one feature path without reverting the whole portal.
✅Solution Using Front Door
Architects used Azure Front Door routes to split traffic by path. Tracking APIs stayed on the legacy origin while quote and invoice paths moved to AKS ingress. Origin groups had separate health probes and priority settings, and the WAF policy was applied consistently across both platforms. Azure CLI commands listed routes and origins before each change window, while deployment scripts enabled one new route at a time. Diagnostic logs were sent to Log Analytics with fields for route name, origin, response code, and latency. The team kept rollback simple: disable the new route and re-enable the legacy path mapping.
📈Results & Business Impact
The migration finished across six route changes with no full-site rollback.
Invoice page P95 latency improved from 880 ms to 430 ms after AKS routing.
One faulty tracking release was rolled back in 9 minutes by changing only its route.
Customer support calls stayed below the normal weekly average during all cutovers.
💡Key Takeaway for Glossary Readers
Front Door route design lets teams modernize public applications one customer path at a time instead of gambling on one cutover.
Case study 03
Benefits application shielded during fraud surge
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A state benefits agency saw automated traffic hit public application forms after a policy announcement. Regional firewalls caught some traffic, but rules differed across hosting teams.
🎯Business/Technical Objectives
Apply one WAF policy to all public application paths.
Preserve access for legitimate applicants during traffic spikes.
Block direct origin bypass attempts.
Produce logs for fraud analysts within one hour.
✅Solution Using Front Door
The agency placed Azure Front Door in front of App Service and API Management origins that served application forms and eligibility APIs. A central WAF policy used managed rules plus custom rate-limiting and header checks. Origins were restricted to accept traffic through Front Door by access rules and expected headers. Azure CLI exported WAF associations, route mappings, and origin host names for the security change record. Diagnostic logs streamed to Log Analytics and a Sentinel workspace so fraud analysts could review blocked IP ranges, rule IDs, countries, and paths without asking application teams for separate log formats.
📈Results & Business Impact
Automated form POST attempts dropped 84% after WAF policy activation.
Legitimate applicant completion rate stayed within 2% of normal weekday levels.
Direct origin bypass probes fell after access restrictions returned 403 responses.
Fraud analysts received usable edge logs in 35 minutes instead of the previous next-day batch.
💡Key Takeaway for Glossary Readers
When Front Door is the enforced edge boundary, security teams can respond globally without chasing every origin team separately.
Why use Azure CLI for this?
With ten years of Azure engineering behind me, I use Azure CLI for Front Door because global routing mistakes are too easy to hide in portal clicks. CLI commands can inventory profiles, endpoints, routes, origin groups, custom domains, WAF links, and health probe settings across subscriptions. That is invaluable during incidents where one route points to an old origin or a certificate validation is stuck. CLI output also helps compare staging and production before DNS cutover. In deployment pipelines, the CLI can validate origin host names, enable or disable routes, purge cache, export evidence, and confirm that traffic-management changes match the approved plan.
CLI use cases
List profiles, endpoints, routes, origin groups, and origins before a migration or incident review.
Inspect custom domain validation, TLS status, WAF associations, and route patterns before DNS cutover.
Purge cached paths or disable an unhealthy origin through an audited command during production response.
Before you run CLI
Confirm subscription, resource group, Front Door SKU, profile name, endpoint name, and whether DNS changes are involved.
Check permissions because route, origin, WAF, and domain changes can affect every user of a public hostname.
Capture current route, origin group, health probe, cache, and custom domain settings before changing production traffic.
What output tells you
Endpoint and route output shows hostnames, patterns, protocols, cache settings, enabled state, and linked origin groups.
Origin group output reveals priority, weight, health probe settings, session affinity, and load-balancing behavior.
Custom domain and security policy output shows TLS status, certificate source, WAF policy association, and domain ownership progress.
Mapped Azure CLI commands
Azure Front Door profile and route inspection commands
direct
az afd profile show --profile-name <profile> --resource-group <resource-group>
az afd profilediscoverNetworking
az afd endpoint list --profile-name <profile> --resource-group <resource-group>
az afd endpointdiscoverNetworking
az afd route list --profile-name <profile> --endpoint-name <endpoint> --resource-group <resource-group>
az afd routediscoverNetworking
az afd origin-group list --profile-name <profile> --resource-group <resource-group>
Architecturally, Front Door is the public edge boundary for many web systems. I design it around hostnames, paths, origin groups, health probes, WAF policy, caching, and DNS ownership. For a global application, Front Door should route users to healthy regional origins and fail over without waiting for DNS TTLs. For a migration, it can shift paths or hostnames gradually while old and new origins run side by side. The design must also decide whether origins remain publicly reachable or are protected with Private Link, access restrictions, or header validation. Observability should include edge logs, origin latency, WAF events, and synthetic tests from key markets.
Security
Security impact is direct because Front Door often becomes the first public surface users and attackers reach. Use managed TLS for custom domains, attach WAF policies, restrict allowed protocols, and avoid bypass paths directly to origins. Origin protection is critical; otherwise attackers can skip Front Door and reach App Service, Storage, or AKS endpoints directly. Private Link, access restrictions, custom origin headers, and firewall rules can reduce bypass risk depending on origin type. Review caching rules so private or personalized responses are not cached accidentally. Monitor WAF events, bot patterns, header anomalies, and changes to routes, domains, and security policies.
Cost
Cost depends on SKU, rule complexity, WAF use, outbound data transfer, requests, caching behavior, and operational patterns. Front Door can lower origin load and improve user latency through caching, but it can also add edge request and data-transfer charges. Poor cache rules may send all traffic to origins while still paying for the edge layer. Overly broad logging retention can increase Log Analytics costs. Premium features such as Private Link and advanced security must be justified against exposure risk. FinOps reviews should examine request volume, bandwidth by region, cache hit ratio, WAF policy scope, diagnostic retention, and duplicate regional delivery services.
Reliability
Reliability improves when Front Door has multiple healthy origins, well-tuned probes, and clear failover priorities. Health probes should hit a meaningful endpoint, not just a static page that stays healthy while the app is broken. Origin groups need realistic latency, priority, and weight settings. DNS validation and custom domain certificate status also affect availability. Reliable designs test regional failover, origin maintenance, route disabling, cache purge behavior, and WAF false-positive handling before a crisis. Front Door can reduce blast radius by moving traffic away from a failing region, but a bad global route or WAF policy can also break every region at once.
Performance
Performance is one of Front Door’s main reasons to exist. Users connect to nearby edge locations, and Front Door routes traffic over Microsoft’s network toward selected origins. Caching can reduce origin round trips for static or cacheable content, while route and rules design can keep dynamic requests on efficient paths. Performance problems usually come from poor origin placement, disabled caching, bad health probes, TLS issues, oversized responses, or routes that send users to distant origins. Operators should track edge latency, origin latency, cache hit ratio, error rate, and Core Web Vitals. Test from real user geographies before declaring a route optimized.
Operations
Operators manage Front Door through route reviews, domain onboarding, certificate validation, WAF tuning, cache purges, origin maintenance, and incident traffic shifts. Practical tasks include listing endpoints and routes, checking origin health, confirming custom domain association, reviewing WAF logs, and comparing production settings with infrastructure code. Runbooks should explain who controls DNS, how to drain or disable an origin, how to purge cached content, and how to roll back a route change. Monitoring should combine Front Door metrics, access logs, WAF logs, origin application logs, and synthetic tests so edge and origin problems are not confused during incidents and maintenance windows.
Common mistakes
Pointing DNS to Front Door while leaving origins directly reachable without access restrictions or origin validation.
Using a health probe that returns success even when the application dependency behind the origin is failing.
Caching personalized or authorization-sensitive responses because route cache rules were copied from static content paths.