Cloud / Azure Front Door Interview questions

Azure Front Door is Microsoft's global, Layer 7 (HTTP/HTTPS) entry point for web applications. It accepts client requests at the nearest Microsoft edge location and forwards them to the best available origin over Microsoft's private backbone.

One service covers several jobs: global load balancing, TLS offload, caching, URL-based routing and web application firewall (WAF) protection. Origins can live in Azure, on-premises or in another cloud, as long as they are reachable on a public endpoint (or through Private Link in the Premium tier).

A typical use is a multi-region web app or API that needs a single global hostname, quick failover and a security layer in front.

Azure Front Door currently comes in two tiers, Standard and Premium, both generally available since March 2022. The older Classic tier is on the retirement path (March 31, 2027) and can no longer be created through the portal or CLI.

The tier is fixed per profile. You can upgrade Standard to Premium, but there is no seamless downgrade tool.

A profile is the top-level container for a Front Door deployment. In Azure Resource Manager it is a Microsoft.Cdn/profiles resource, and it holds everything else: endpoints, origin groups, origins, routes, rule sets, custom domains, secrets and security policies.

The tier (Standard or Premium) is chosen when the profile is created, so every endpoint under it shares the same tier. Billing also starts here, because each profile carries a base fee on top of usage-based request and data transfer charges.

Teams usually keep one profile per application or environment, but several apps can share one profile if you want to avoid paying multiple base fees.

An endpoint is a logical grouping of routes that gets its own hostname on the Front Door domain, in the form <name>-<hash>.z01.azurefd.net. Clients can reach your app through that hostname, or through custom domains you associate with the endpoint.

The random hash is added so that a deleted endpoint name cannot be re-registered by someone else, which protects against subdomain takeover. A profile can contain multiple endpoints, and each one can have several routes pointing at different origin groups.

An origin is the actual backend that serves content, such as an App Service, a storage account, a Container App or any public host name. Each origin has a host name, ports, an optional host header, a priority (1-5), a weight (1-1000) and an enabled flag.

An origin group is a set of equivalent origins that share the same health probe and load-balancing settings. Routes point to an origin group, never directly to a single origin.

In the Classic tier these were called backends and backend pools.

A route tells Front Door which domains and URL patterns map to which origin group. It is the glue between the front end (endpoint, custom domains) and the back end (origin group).

Key route settings:

• Domains and patterns to match, such as /* or /api/*
• Accepted protocols (HTTP, HTTPS) and the option to redirect HTTP to HTTPS
• Forwarding protocol to the origin (HTTP only, HTTPS only, or match request)
• Optional origin path, caching and compression settings
• Attached rule sets

When several routes could match, the most specific domain and path pattern wins.

Anycast means the same IP addresses are advertised from many edge locations at once. Using BGP routing, each client's traffic naturally lands on the network-closest Front Door edge instead of one fixed server.

Your DNS name resolves (through a CNAME to the endpoint) to these anycast addresses, so users in Singapore and Frankfurt get the same IP but connect to different physical locations. If one edge becomes unreachable, routing converges and clients are served from the next nearest one with no DNS change.

Edge locations (points of presence) are Microsoft's globally distributed entry points where Front Door terminates client connections. Microsoft maintains a large worldwide footprint, and the current count is published in its documentation.

At the edge, Front Door performs TCP and TLS termination, WAF evaluation, rules engine processing and cache lookups. Only when the content is not cached does the request travel to the origin over Microsoft's backbone.

Each edge keeps its own cache, so the first request for an object at a given location is usually a cache miss.

Front Door chooses an origin using up to four mechanisms, evaluated together at the origin-group level:

The default latency sensitivity is 50 ms, which means origins close to the fastest one share traffic.

A health probe is a synthetic request sent from each edge to every origin in an origin group to check whether it can take traffic. You configure the path (for example /health), protocol, request method (HEAD or GET) and interval.

A probe that returns 200 OK counts as successful. Front Door looks at recent samples and, if too few succeed, marks the origin unhealthy and stops sending user traffic to it until it recovers.

Tip: use HEAD to reduce load on the origin, and point the probe at a lightweight endpoint rather than the home page. Probing can be turned off when an origin group holds only one origin.

Caching lets Front Door store copies of cacheable responses at the edge and serve them without contacting the origin. It is enabled per route and mainly helps static assets like images, CSS, JavaScript and downloads.

Front Door respects origin headers such as Cache-Control by default. If the origin sends no expiry, Front Door applies a default cache duration of roughly one to three days. You can override behavior with the rules engine, choose how query strings affect cache keys, and purge content when needed.

The result is lower latency for users and less load and egress at the origin.

The rules engine lets you change how requests and responses are handled without touching application code. You group rules into a rule set and attach it to one or more routes.

Each rule has conditions (URL path, header, cookie, client country, device type, HTTP method and more) and one or more actions:

• URL redirect and URL rewrite
• Modify request header and modify response header
• Route configuration override, such as picking a different origin group or changing cache behavior

Rules run in order, and you can stop evaluating the rest once one matches. A common use is adding security headers like Strict-Transport-Security to every response.

Azure Web Application Firewall on Front Door inspects HTTP(S) requests at the edge and blocks malicious ones before they reach your origin. You create a WAF policy and link it to endpoints or domains through a security policy.

A policy can operate in Detection mode (log only) or Prevention mode (block). Rule types include:

• Custom rules: IP allow/deny, geo-filtering, header matches and rate limiting (both tiers)
• Managed rules: the Default Rule Set against SQL injection, XSS and similar attacks, plus Bot Manager (Premium only)

Start in Detection mode, review logs for false positives, then switch to Prevention.

Adding a custom domain means proving you own it, then pointing DNS at Front Door:

1. Add the domain under the profile's Domains section and choose Azure-managed or your own certificate.
2. Create the _dnsauth.<subdomain> TXT record shown by Front Door to validate ownership.
3. Associate the domain with an endpoint and a route.
4. Create a CNAME from your host name to the endpoint's azurefd.net hostname.

For an apex domain such as example.com, a CNAME is not allowed, so use an Azure DNS alias record pointing to the Front Door endpoint.

X-Azure-FDID is a request header Front Door adds when calling your origin. Its value is the unique ID (GUID) of your Front Door profile.

Origins use it to confirm that a request really came through your Front Door. This matters because the AzureFrontDoor.Backend service tag covers every customer's Front Door, so an IP restriction alone would still let someone else's profile reach your origin.

# nginx example: reject requests that did not come through our profile
if ($http_x_azure_fdid != "11111111-2222-3333-4444-555555555555") {
    return 403;
}

Session affinity routes a user's requests to the same origin for the length of the session. Front Door does this by issuing cookies named ASLBSA and ASLBSACORS when the feature is enabled on the origin group. It is off by default.

Use it only for apps that keep state in memory on the server. The cost is less even load distribution, since busy users stay pinned. If the pinned origin turns unhealthy, Front Door moves the user to another one, so state can still be lost. Stateless apps with shared session stores do not need it.

With Private Link, Front Door Premium reaches your origin through a private endpoint instead of the public internet. Traffic travels from the Front Door edge across Microsoft's backbone into a Microsoft-managed network, then connects to the origin privately.

Supported origins include Azure Storage (blob and static website), App Service and Functions, Container Apps, API Management and internal load balancers exposed through a Private Link service.

After creating the origin you must approve the pending private endpoint connection on the origin resource. Once approved, you can disable public access to the origin entirely.

You pick a certificate type when adding the domain:

• Azure-managed certificate: free, issued after domain validation and renewed automatically.
• Bring your own certificate (BYOC): stored in Azure Key Vault, with Front Door's managed identity granted read access.

With BYOC, select the latest version of the secret so renewals are picked up without reconfiguring. Also set the minimum TLS version on the domain; TLS 1.2 is the sensible floor today.

Finally enable Redirect all traffic to use HTTPS on the route so plain HTTP requests never reach the origin.

URL redirect is a rules engine action that returns a 3xx response to the client, telling the browser to request a new location. You can change the protocol, host name, path, query string and fragment.

Supported status codes are 301 (permanent), 302 (found), 307 (temporary, method preserved) and 308 (permanent, method preserved).

Common examples are sending www to the apex domain, moving an old path to a new one, or forcing HTTP to HTTPS. The browser's address bar changes because the client makes a second request.

URL rewrite changes the path sent to the origin while the client keeps seeing the original URL. It works through a source pattern and a destination path, with an option to preserve any unmatched remainder of the path.

Example: rewrite /api/v1/* to /* so an origin that does not know about the /api/v1 prefix still works.

The origin host header is the Host value Front Door sends to the origin. By default it equals the origin's host name, but you can override it.

It matters for multi-tenant backends such as App Service or Azure Storage, which pick the right site or account from the Host header. If the header does not match what the origin expects, you typically see 404 errors or the default site.

Set it explicitly when your public domain (for example www.contoso.com) differs from the origin host name (for example contoso.azurewebsites.net), and make sure your app generates links correctly when the two differ.

You purge from the portal, CLI or PowerShell by listing content paths per endpoint and domain. Three forms are allowed:

• Single file: /images/logo.png
• Folder with wildcard: /images/*
• Everything: /*

az afd endpoint purge --resource-group rg-web --profile-name fd-prod \
  --endpoint-name www --domains www.contoso.com --content-paths "/images/*"

Purges take a few minutes to propagate across edges. For frequent updates, prefer versioned file names or query strings over repeated purges.

Remember that purging removes the object only from Front Door's edge caches. Browser caches and any other CDN in front of you keep their copies until they expire, so a purge alone may not make users see the new file immediately.

The forwarding protocol on a route decides how Front Door talks to the origin. It is separate from the protocols clients use to reach Front Door.

Choose HTTPS only for end-to-end encryption. Pair it with an HTTP-to-HTTPS redirect on the route, and make sure the origin has a valid certificate that matches its host name.

The features interviewers expect you to name:

• Global load balancing with latency, priority, weighted and session-affinity options
• Anycast + split TCP acceleration over Microsoft's backbone
• Edge caching and compression
• TLS offload with managed or custom certificates
• WAF, bot protection (Premium) and rate limiting
• Rules engine for redirects, rewrites and header changes
• Private Link origins (Premium)
• Health probes with automatic failover, WebSocket support, and diagnostics through Azure Monitor

In an interview, group these into three themes: performance (anycast, caching, compression), resilience (probes, failover, routing methods) and security (WAF, TLS, Private Link). That structure is easier to remember and sounds more organised than a flat list.

Front Door can compress eligible responses at the edge using gzip or Brotli, depending on the client's Accept-Encoding header. Smaller payloads mean faster page loads and less bandwidth.

It applies to a defined list of text-based MIME types such as HTML, CSS, JavaScript and JSON, and only to files within a size range (roughly 1 KB up to 8 MB). Compression works together with caching, so enable caching on the route first.

If the origin already compresses the response, Front Door passes it through rather than compressing twice.

Both route users to healthy endpoints globally, but they work at different layers. Traffic Manager is DNS-based: it answers a DNS query with an endpoint and then steps aside. Front Door is a reverse proxy: every request flows through it.

Pick Traffic Manager for non-HTTP workloads, and Front Door for web apps and APIs.

One more difference: because Traffic Manager never sees the traffic, it cannot terminate TLS, inspect requests or cache anything. If a client keeps a resolved IP past the TTL, it may keep hitting a failed endpoint, which is exactly the gap Front Door closes.

Both are Layer 7 load balancers with WAF options, but Front Door is global and edge-based, while Application Gateway is regional and lives inside a virtual network.

Many designs use both: Front Door in front for global reach, Application Gateway inside each region.

Cost and operations also differ. Front Door is a profile with request-based billing and no VNet to manage, while Application Gateway runs as capacity units you place and size per region. For a single-region internal app, Application Gateway alone is often the simpler choice.

Standard covers acceleration and delivery; Premium adds the advanced security features.

You can upgrade a Standard profile to Premium in place, but going back down means recreating the profile.

A practical rule: start on Standard for plain content delivery and custom WAF rules, and move to Premium the moment a security review asks for managed rule sets, bot protection or a private connection to the origin. The in-place upgrade keeps your endpoints and domains.

Standard and Premium are a re-architected platform that merged Classic Front Door with Azure CDN capabilities. The concepts were renamed and expanded.

Classic retires on March 31, 2027. New Classic resources can no longer be created, Classic stopped supporting Azure-managed certificates from August 2025, and a built-in migration tool moves profiles across.

The practical impact for existing users is that scripts, Terraform and ARM templates written for Classic (Microsoft.Network/frontDoors) do not carry over. Standard and Premium use Microsoft.Cdn/profiles, so the migration tool handles the profile while you rewrite the automation.

Front Door speeds up dynamic content using four techniques together:

1. Anycast lands the client on the nearest edge.
2. Split TCP: the client's TCP and TLS handshakes finish at that nearby edge, so the round trips are short.
3. The edge reuses warm, persistent connections to the origin, skipping repeated handshakes.
4. Traffic crosses Microsoft's private backbone instead of the congested public internet.

Example: a user in Sydney calling an origin in West Europe completes the expensive handshakes in milliseconds with a Sydney edge, which then forwards over an already-open connection. Cached content skips the origin trip altogether.

Note that acceleration helps most for dynamic, uncacheable traffic such as API calls. For static files, caching gives the bigger win, since the origin is skipped altogether. The two work together rather than replacing each other.

Front Door continuously measures probe latency from each edge to every healthy origin. It keeps the fastest origin and also any origin whose latency is within the additional latency sensitivity window (default 50 ms). Those origins form the eligible pool.

Example: the fastest origin responds in 40 ms and sensitivity is 50 ms, so any origin up to 90 ms is eligible. Traffic is then split among them by weight.

The origin group's sample size and successful samples required (commonly 4 and 3) control how many recent probes decide health. Setting sensitivity to 0 makes Front Door strictly prefer the fastest origin.

Latency is measured from the edge to the origin, not from the user to the origin. Two users in the same city therefore see the same ranking of origins, which keeps routing stable and avoids flapping between regions when a few probes are slow.

Front Door filters origins in layers. First priority (1-5, lowest wins) picks the group of healthy origins to use. Then latency sensitivity trims that group, and finally weight (1-1000) splits traffic proportionally among what remains.

This is how you do canary releases (shift weights) and active/passive disaster recovery (use priority) in the same origin group.

If you only want strict failover, give each origin a different priority and ignore weights. If you only want load sharing, keep all origins at priority 1 and tune weights. Mixing the two is what makes a canary inside an active region possible.

Failover is driven by health probes. Each edge probes every origin; when the number of successful samples falls below the required count, that origin is marked unhealthy and dropped from rotation. New requests go to the next best origin by priority, latency and weight.

When probes succeed again, the origin is added back automatically. No DNS change is needed, so failover typically completes within seconds to a couple of minutes depending on probe interval and sample settings.

flowchart LR
  P["Edge health probes"] --> H{Origin healthy?}
  H -- yes --> R["Keep in rotation"]
  H -- no --> X["Remove from rotation"]
  X --> N["Route to next priority or latency pool"]
  N --> B["Probe keeps checking"]
  B --> H

Shorter probe intervals speed detection but increase probe traffic to your origin.

If your origin stays reachable on the public internet, attackers can bypass Front Door entirely by hitting the origin's IP or default hostname. That skips your WAF rules, rate limits and geo-filtering.

Lock it down with layered controls:

• Private Link (Premium): origin has no public exposure at all.
• Service tag AzureFrontDoor.Backend in NSG or firewall rules, instead of hard-coded IPs that change.
• X-Azure-FDID header check to ensure the request came through your own profile.

The service tag and header check go together, because the tag covers all Front Door customers.

Check the result after locking down: call the origin's default hostname directly and confirm you get a 403 or a timeout, while the same request through Front Door still works. If both fail, your rule is likely blocking the Front Door service tag as well.

The idea is one global entry point with identical stacks in two or more regions.

1. Deploy the app in each region (for example App Service in East US and West Europe).
2. Create one origin group with an origin per region at the same priority; use latency routing so users hit the closest region.
3. Expose a /health endpoint that checks critical dependencies shallowly, and use it as the probe path.
4. Replicate data with a multi-region store such as Cosmos DB or geo-replicated SQL.
5. Attach WAF and enable caching for static content.

flowchart TD
  U[Users] --> FD["Azure Front Door"]
  FD --> A["Region A origin"]
  FD --> B["Region B origin"]
  A --> DB[(Replicated data)]
  B --> DB

Test failover regularly by disabling an origin, and keep sessions stateless so users can move between regions.

Cache duration follows a precedence order:

1. A rules engine override if you configured one (route configuration override).
2. The origin's Cache-Control (max-age) or Expires header.
3. If neither exists, a default of about one to three days.

The cache behavior options in a rule are Honor origin, Override always and Override if origin missing. With Honor origin, responses marked private, no-cache or no-store are not cached.

Use Override always for static files whose origin sends bad headers, and avoid it for personalized pages.

When you serve personalized content, route those paths to a rule that disables caching, or make sure the origin sends Cache-Control: private. Overriding blindly can leak one user's page to another, which is the most serious mistake with edge caching.

The query string setting decides whether URLs that differ only by query parameters share one cache entry or not.

Example: with Use query string, /app.js?v=7 and /app.js?utm_source=x are two objects. Ignoring marketing parameters raises the hit ratio, while keeping v as a version key still allows cache busting.

If your app builds cache-busting URLs with a version parameter, keep that parameter in the key and ignore the rest. This gives you both a high hit ratio and instant updates after a deploy, without relying on purges.

Custom rules are written by you, while managed rules are maintained by Microsoft.

An Allow custom rule can skip managed-rule inspection for trusted traffic, so use it carefully.

Both sets can be tuned: you can add exclusions for fields that trigger false positives (for example a rich-text form field) and change individual managed rule actions, without switching off the whole rule set. Always test changes in Detection mode first.

Rate limiting is a custom rule of type RateLimitRule inside a WAF policy. You define:

• A threshold (requests allowed)
• A duration, either 1 or 5 minutes
• Match conditions such as path /login or a header
• An action: block, log or redirect

Requests are counted per client IP, and counters are tracked at the edge, so enforcement is approximate rather than exact to the request.

Practical approach: start with Log, check the logs for legitimate heavy users such as shared NAT addresses, then move to Block. Apply tight limits only to sensitive endpoints like login and password reset.

Combine rate limiting with a geo-filter or IP allow rule for admin paths. For APIs behind a shared corporate proxy, many users appear as one IP, so a strict per-IP limit can block legitimate traffic. Review the logs before enforcing it.

A single request passes through several stages at the edge before it ever reaches your origin:

1. DNS resolves the custom domain (CNAME) to the Front Door anycast address.
2. The client connects to the nearest edge; TLS terminates there.
3. WAF policy inspects the request.
4. The route is matched by domain and path, and the rules engine runs.
5. On a cache hit, the edge responds immediately.
6. On a miss, Front Door picks an origin and forwards over the backbone.
7. The response passes back through response rules, may be cached, and goes to the client.

sequenceDiagram
  participant C as Client
  participant E as Front Door edge
  participant O as Origin
  C->>E: HTTPS request
  E->>E: WAF, route match, rules
  alt cache hit
    E-->>C: cached response
  else cache miss
    E->>O: forward request
    O-->>E: response
    E-->>C: response (cached if allowed)
  end

For Azure-managed certificates, Front Door issues the cert after domain validation and renews it automatically, as long as the DNS still points at Front Door. No action is needed.

For BYOC, the certificate lives in Key Vault and Front Door reads it using a managed identity. When the secret version is set to latest, a renewed certificate in Key Vault is picked up automatically after a propagation delay. If you pin a specific version, you must update the domain manually.

Also check that the Key Vault access policy or RBAC role for Front Door's identity is still valid; a revoked permission is a common cause of expired certificates.

For managed certificates, validation can fail if the DNS record was changed to point somewhere else, for example to another CDN. Keep the CNAME (or alias record) pointing at the Front Door endpoint, and renewal will keep working without anyone touching it.

Front Door does not stop serving. When every origin in the group appears unhealthy, it treats them all as healthy again and sends requests anyway, spreading them across the origins.

The reasoning is that a probe failure may be wrong or temporary (for example a bad probe path), and refusing all traffic would turn a partial problem into a full outage.

In practice, users then see whatever the origin returns: real content if it recovered, or errors such as 502, 503 or 504 if it is truly down. To avoid false alarms, monitor the Origin Health Percentage metric and alert before it hits zero.

Probe design affects this behavior directly. A probe path that depends on a database can mark every origin unhealthy during a database blip, even though static pages still work. Keep probe endpoints light and focused on whether the origin can accept traffic.

A 502 means Front Door could not get a valid response from the origin. Work through the common causes:

1. TLS problems: the origin certificate is expired, self-signed, from an untrusted CA or does not match the origin host name.
2. Protocol or port mismatch: forwarding protocol is HTTPS only but the origin only listens on HTTP.
3. Firewall or NSG blocking the AzureFrontDoor.Backend service tag.
4. Host header sent to the origin that it rejects or resets.
5. The origin closing the connection or crashing mid-response.

Test the origin directly with curl -v using the same host header, then check the access log (originName, httpStatusCode) and quote the X-Azure-Ref value when opening a support case.

Also look for a mismatch between the SNI or host header Front Door sends and what the origin's certificate covers. Setting the origin host header to the name on the certificate is a very common fix for this specific 502.

A 504 means Front Door waited for the origin but the origin did not answer within the origin response timeout. The default is 60 seconds and it can be raised (up to 240 seconds), but raising it is a last resort.

1. Measure how long the slow request takes directly against the origin.
2. Check origin CPU, memory, database calls and cold starts.
3. Move long jobs to an async pattern: return 202 and let the client poll.
4. Raise the timeout only for routes that truly need it.
5. Confirm the app is not holding connections open for streaming that Front Door treats as idle.

Compare the access log's origin timing fields against the Total Latency metric to see where the time goes.

Start by reading the X-Cache response header, which tells you what the edge did:

If you see misses, check: caching enabled on the route, origin Cache-Control headers, query string variations creating separate entries, non-GET methods, a recent purge, and the fact that each edge fills its own cache on first request.

For testing, request the same URL twice from the same location. The first response is usually a miss and the second a hit. If the second is still a miss, look at the response headers from the origin, because that is where the cause almost always sits.

Use both when you need global entry plus regional control. Front Door handles global routing, acceleration, caching and edge WAF. Application Gateway sits inside each region's VNet for path routing to private backends, internal-only services or mutual TLS inside the network.

Design points:

• Restrict Application Gateway's public IP to the AzureFrontDoor.Backend tag and check X-Azure-FDID.
• Decide which layer owns the WAF to avoid double inspection and duplicate false positives.
• Preserve the client IP through X-Forwarded-For.
• Expect added latency and cost, so skip the combination if Front Door alone fits.

If you do not need VNet-level path routing, internal-only backends or regional mTLS, skip Application Gateway. Front Door Premium with Private Link can often reach the private app directly, and removing a hop reduces both latency and cost.

Microsoft provides an in-portal migration that creates a new Standard or Premium profile from your Classic configuration with no downtime.

1. Validate: the tool checks compatibility and flags unsupported items.
2. Prepare: it builds the new profile; review the mapping of routes, origin groups, rules and WAF.
3. Enable managed identity if you use BYOC certificates from Key Vault.
4. Migrate: traffic switches to the new profile.

Choose Premium if you need managed WAF rules or Private Link. Plan ahead: Classic retires March 31, 2027, and the profile name carries over. Also update any IaC and automation, since Standard/Premium use different APIs and CLI commands (az afd).

After the cut-over, verify DNS still points to the endpoint, test HTTPS on every custom domain, and review WAF policies that were converted. Keep the old configuration documented until you are confident, since you cannot simply roll the migration back.

Front Door billing combines a base fee per profile, request charges and data transfer out from the edge, so the savings come from doing less work at the origin and fewer profiles.

• Enable caching and compression so fewer bytes leave the edge and the origin.
• Ignore irrelevant query strings to raise the hit ratio.
• Use Standard unless you need managed WAF, bot protection or Private Link.
• Consolidate small apps into fewer profiles to avoid multiple base fees.
• Use Azure Cost Management to find which endpoints drive request and egress charges.
• Block abusive traffic at the WAF so you do not pay to serve it.

Check current pricing for how traffic from Azure origins to the edge is billed.

Be careful with one trade-off: aggressive caching reduces cost but risks serving stale or personalized content. Measure the Byte Hit Ratio metric before and after each change so you can show the saving rather than guess it.

Use Azure Monitor with diagnostic settings sent to Log Analytics.

AzureDiagnostics
| where Category == "FrontDoorAccessLog"
| where toint(httpStatusCode_s) >= 500
| summarize errors = count() by originName_s, bin(TimeGenerated, 5m)

Add alerts on Origin Health Percentage and 5XX rate, and use WAF logs to tune rules before moving from Detection to Prevention.

Retention matters too: Log Analytics ingestion is billed, so sample or filter noisy access logs if volume is high, and consider archiving to a storage account for long-term audit needs. Dashboards in Azure Monitor workbooks make these numbers easy to share with the team.

Standard and Premium use the az afd command group. Build the pieces in dependency order: profile, endpoint, origin group, origin, route.

az afd profile create -g rg-web --profile-name fd-prod --sku Premium_AzureFrontDoor
az afd endpoint create -g rg-web --profile-name fd-prod --endpoint-name www --enabled-state Enabled
az afd origin-group create -g rg-web --profile-name fd-prod --origin-group-name og-app \
  --probe-request-type HEAD --probe-protocol Https --probe-path /health \
  --probe-interval-in-seconds 60 --sample-size 4 --successful-samples-required 3 \
  --additional-latency-in-milliseconds 50
az afd origin create -g rg-web --profile-name fd-prod --origin-group-name og-app \
  --origin-name app1 --host-name app1.azurewebsites.net \
  --origin-host-header app1.azurewebsites.net --priority 1 --weight 1000 --enabled-state Enabled
az afd route create -g rg-web --profile-name fd-prod --endpoint-name www --route-name r1 \
  --origin-group og-app --supported-protocols Http Https --https-redirect Enabled \
  --forwarding-protocol HttpsOnly --link-to-default-domain Enabled --patterns-to-match "/*"

For repeatable infrastructure, the same objects exist in Bicep and Terraform under Microsoft.Cdn/profiles.