Skip to main content
This guide shows how to configure Azure Front Door (AFD) from the Azure portal. It covers origins (backends), origin groups, health probes, routing and rule sets (rewrites/redirects), SSL and end‑to‑end encryption, and a step‑by‑step portal demo with screenshots.

​
Overview

Azure Front Door provides global, scalable edge routing, caching, WAF protections and rules engine capabilities to route requests to healthy backend origins. Key configuration areas:
  • Origins and origin groups (backend pools)
  • Health probes and load‑balancing behavior
  • Routes (listeners/endpoints) and URL matching
  • Rules engine for rewrites/redirects and header transforms
  • SSL / custom domains and end‑to‑end TLS
  • Testing and verification

​
Origins and backend configuration

In Front Door, a backend is called an origin. Configure each origin with values Front Door will use when forwarding client requests. Key origin settings:
  • Origin type: built‑in Azure resource types or custom endpoints
  • Origin hostname: the origin’s host (portal often auto‑populates for Azure resources)
  • Host header: the header that Front Door will send to the origin (must match what the origin expects for SNI/certificate validation)
  • Priority and weight: control failover and proportionate traffic distribution
  • Session affinity: optional sticky sessions if your app requires them
Origin typeUse caseTypical example
App ServiceWeb apps hosted in Azuremyapp.azurewebsites.net
API ManagementAPI front dooring with APIMmyapim.azure-api.net
Application GatewayInternal or regional gatewaymy-agw.internal.cloudapp.net
Storage AccountStatic website hostingmystorage.z16.web.core.windows.net
Custom endpointExternal third‑party or on‑premapi.contoso.com
After you add origins, group them into an origin group (a backend pool). Health probes and load‑balancing settings are applied at the origin‑group level so Front Door routes only to healthy origins.

​
Health probe configuration

Health probes let Front Door determine origin health and only route traffic to healthy backends. Recommended probe settings:
  • Protocol: HTTP or HTTPS (match what the origin supports)
  • Probe path: e.g., /health or /health.html — must return a healthy response
  • Probe method: GET (returns body and headers) or HEAD (headers only)
  • Interval (seconds): how often Front Door probes (minimum 5s)
  • Unhealthy threshold: consecutive failed probes before marking origin unhealthy
  • Sample size / successful samples: tuning parameters for health evaluation
Health probe settingTypical valueNotes
Probe path/health.htmlUse a small static file or lightweight endpoint
ProtocolHTTPSUse HTTPS for end‑to‑end TLS; ensure certs are valid
MethodGET / HEADGET if the endpoint requires a response body
Interval5sMinimum allowed; shorter intervals detect failures faster
Unhealthy threshold3Common starting value; tune per SLA
When using HTTPS probes, ensure the origin certificate is valid and the requested host header matches the certificate Subject/SAN. Otherwise the probe may fail and the origin will be marked unhealthy.
Common probe failures:
  • Wrong probe path (404 or redirect)
  • TLS certificate mismatch or expired certs for HTTPS probes
  • Host header sent by Front Door does not match origin SNI

​
End-to-end request flow

This diagram illustrates the end‑to‑end client request path for Azure Front Door — from edge connection, TLS and WAF evaluation through route/origin selection, caching, and forwarding:
A flowchart titled "Configure routing and redirection rules" that outlines the Azure Front Door request flow — from edge connection and TLS/WAF evaluation through route/origin selection, caching, and forwarding.
Key flow points:
  1. Client request hits the nearest Azure Front Door edge (low latency).
  2. Front Door matches the request to the configured Front Door profile and negotiates TLS (if enabled).
  3. WAF (if enabled) evaluates and may block malicious requests.
  4. Front Door matches the request to a route and selects an origin group.
  5. Rules engine conditions (rewrites/redirects) are applied if configured.
  6. If content is cached at the edge, Front Door can return it immediately.
  7. Otherwise Front Door selects the healthiest origin (priority/weight) and forwards the request.

​
Routing rules, endpoints, and URL patterns

Routes connect a Front Door endpoint (listener) to an origin group. Routes support:
  • URL pattern matching (e.g., /images/* → image origin group)
  • HTTP→HTTPS redirection
  • Cache control and CDN behavior
  • Rules engine association for rewrites, redirects, and header transforms
Examples:
  • /api/* → API origin group (HTTPS only)
  • /static/* → Storage origin with aggressive caching
  • /docs/* → origin group with rule set that rewrites to .html

​
SSL, custom domains, and end-to-end encryption

Front Door supports both Azure‑managed certificates and customer‑provided certificates. Recommendations:
  • Use Azure‑managed certificates to simplify lifecycle and automatic renewal.
  • For end‑to‑end TLS, enable HTTPS between Front Door and your origin and ensure SNI/host headers match origin certificates.
  • If using custom certs, maintain renewal and chain validity.
A slide titled "Secure Front Door with SSL and end-to-end SSL encryption" showing four blue feature buttons on the left and an "Update route" configuration panel on the right with options for patterns, HTTPS redirect, origin group, and forwarding protocol.

​
Portal walkthrough — demo resources

This demo uses multiple App Services deployed across regions, all serving the same application endpoints: 
/health
/api/users
/api/orders
These App Services are globally distributed. The goal is to load balance across regions and use URL rewrites where necessary.
A screenshot of the Microsoft Azure portal showing the App Services view. It displays the overview and essentials for a web app named "app-az700-fd-fhcotp-southeastasia," including resource group, status, location, subscription, and default domain.

​
Creating a Front Door in the portal

  1. Search for “Front Door” in the Azure portal and click Create a Front Door.
  2. Choose the creation experience: Quick create or Custom create. Use Custom create to view all options (recommended for learning and exams).
  3. Select a resource group and enter a Front Door name (e.g., AFD-AZ700). Note: Front Door is a global resource; metadata is stored in the resource group’s region.
  4. Choose SKU/tier (Standard/Premium) based on required features (WAFv2, Rules Engine capabilities, etc.).
  5. Upload or configure custom certificates if you plan to use custom domains (optional).

​
Front-end endpoint (listener)

  • Add an endpoint (e.g., AFD-EP-Web). The name is part of the default domain (for example AFD-EP-Web-xxxx.azurefd.net).
  • The endpoint is the listener that accepts client connections.

​
Add a route

  • Create a route (e.g., AFD-WebRoute). Select the endpoint, optional custom domains, patterns to match (default is /), accepted protocols (HTTP/HTTPS), and whether to redirect HTTP → HTTPS.
  • Routes select an origin group to forward traffic to.
Screenshot of the Microsoft Azure portal displaying the "Add a route" page for Azure Front Door, with fields for Name, Endpoint, Domains, Patterns to match, Accepted protocols, Redirect to HTTPS, Origin group, and Forwarding protocol. Action buttons "Add", "Cancel", and "Close" are visible at the bottom.

​
Create an origin group and add origins

  • Add an origin group (for example AFD-Web Origin Group).
  • Add origins (East US, Southeast Asia, Australia East, West Europe) and configure priority/weight for failover and traffic distribution.
  • Optionally enable session affinity for sticky session requirements.
  • Configure health probes and load‑balancing parameters at the origin group level.
Screenshot of the Microsoft Azure portal showing an "Add an origin group" dialog for Azure Front Door. The panel displays health probe settings (path "/health.html", HTTP protocol, HEAD probe) with a route creation form visible in the background.

​
Health probe and load‑balancing example

Example recommended settings to detect origin health quickly while minimizing false positives:
  • Probe path: /health.html (small static file)
  • Protocol: HTTPS (or HTTP if you do not require TLS)
  • Probe method: GET or HEAD
  • Interval: 5 seconds (minimum)
  • Configure sample size, successful samples, and unhealthy threshold to match application SLA
A screenshot of the Microsoft Azure portal showing the "Add an origin group" dialog for Azure Front Door, with health probe settings configured (path "/health.html", HTTPS protocol, GET probe, 5s interval) and load‑balancing parameters.

​
Forwarding protocol and caching

  • Forwarding protocol options determine how Front Door calls your origin:
    • Match incoming request
    • Use HTTP only
    • Use HTTPS only
  • For true end‑to‑end TLS, choose HTTPS between Front Door and the origin.
  • Use caching/CDN rules to serve static content from the edge.
  • Use rule sets for rewrites, redirects, and header transforms.
A screenshot of the Microsoft Azure portal showing the "Add a route" configuration page for Azure Front Door with fields for patterns, accepted protocols, redirect to HTTPS, origin group, forwarding protocol, and caching. Action buttons "Add", "Cancel", and "Close" appear at the bottom.

​
Deployment and testing

  • Click Review + Create to validate and create the Front Door. Provisioning commonly takes 10–15 minutes.
  • After deployment, open the Front Door endpoint URL (default *.azurefd.net) to confirm routing to the nearest healthy origin.
  • Simulate failover by stopping an App Service in one region and confirm Front Door routes to another healthy origin.
  • Monitor logs and metrics in Azure Monitor for latency, origin health, and WAF blocks.

​
URL rewrites with Rule Sets

If your backend requires .html extensions but users request paths without them (for example /docs/help → /docs/help.html), use a Rule Set with URL rewrite actions:
  1. Create a Rule Set and add rules with conditions (for example, Request Path equals /docs/help).
  2. Add an action of type URL rewrite: set the source pattern and destination pattern (e.g., source /docs/help → destination /docs/help.html).
  3. Save the Rule Set.
  4. Associate the Rule Set with the route and set processing priority if multiple rule sets exist.
A screenshot of the Microsoft Azure portal showing a "Rule set configuration" page with two URL rewrite rules for "/docs/help" and "/docs/faq". Each rule displays the IF condition (request path) and THEN action (URL rewrite) with source/destination patterns and options, and Save/Discard buttons at the bottom.
  • Use the “stop processing more rules” option to avoid unnecessary rule evaluation once a match has been processed.
  • Rewrites happen at the edge before forwarding to the origin; redirects return a redirect response to the client.
If your health probes or rewrites depend on host header or certificate validation, ensure the host header and SNI match the origin certificate — otherwise probes or origin connections can fail and appear as origin unavailability.

​
Final verification

  • Test the endpoint without the .html extension to ensure the rule set rewrites correctly.
  • Confirm response times and the regional origin that served the request. When an origin is stopped, verify Front Door fails over to the next healthy origin.
  • Use Azure Monitor and Front Door metrics (latency, request counts, origin health) to validate production readiness.
A bright yellow webpage screenshot showing a "/docs/help" page header and a "Regional Content Delivery" panel that states the content is served from Southeast Asia. The page also includes buttons and info cards about video content, performance, and geographic optimization.

Watch Video