Azure Front Door pricing: model requests, bandwidth, and origin traffic

Azure Front Door is "edge delivery + routing + (optional) caching/WAF". A reliable estimate splits costs into explicit drivers: edge bandwidth, request volume, origin traffic (cache fill), and operational add-ons like WAF/rules and logging.

0) Define the boundary (edge vs origin)

Edge bandwidth: bytes delivered from Front Door to end users.
Origin egress: bytes from your origin to Front Door on cache fill (cache misses).
Requests: request count at the edge; keep a separate count for origin if your origin pricing cares.

Most "surprise bills" are cache miss spikes (origin egress), not steady-state edge delivery.

1) Edge bandwidth (GB/month)

Start with monthly bandwidth to end users. If you already have metrics, use a representative window (not just a good day) and convert to GB/month. If you only have RPS, estimate response sizes and multiply by request volume.

Tools: Response transfer, CDN bandwidth, Unit converter.

Split out any "heavy tail" endpoints (downloads, exports, media) instead of blending one average response size.
Keep a peak scenario (bot traffic, incident traffic, marketing spikes) to avoid underestimating.

2) Requests (per month)

Convert RPS to monthly requests and model peaks separately if you have bursty traffic. Keep units explicit (per 10k vs per 1M) and include retries/timeouts, which multiply both request count and bandwidth.

Tools: RPS to monthly requests, Request cost.

If you use rules/rewrites/routing, keep a separate "rules touched" estimate (not every request triggers complex rules).
If you have multiple hostnames and routes, track them separately: traffic distribution changes which paths cache well.

3) Origin egress (cache fill)

If you cache at the edge, origin egress is driven by misses. A practical estimate is: origin GB ~= edge GB * (1 - hit rate). Purges, deploys, and low TTLs reduce hit rate and can cause short-lived origin spikes.

Tool: Data egress cost.

Model large objects separately: one download path can dominate origin GB even when overall hit rate looks healthy.
Track "cold cache" events: a full purge plus a large deployment can temporarily turn most traffic into origin fills.

4) Logging (often the hidden bill)

Access logs and diagnostics can become significant at scale. Treat logging as its own pipeline: events * bytes/event becomes GB ingested, then retention and query scans.

Tools: Log ingestion, Retention storage, Search/scan.

Worked estimate template (copy/paste)

Edge requests/month = baseline + peak (include retries)
Edge GB/month = requests/month * avg response size (split top endpoints)
Origin GB/month ~= edge GB/month * (1 - hit rate) (model purge/deploy periods separately)
Log GB/month = log events/month * bytes/event (sample real payloads)

Common pitfalls

Double-counting edge bandwidth and origin egress (they are different legs).
Using one blended response size when a few endpoints dominate bytes.
Ignoring cache invalidations/purges and cold cache events (misses drive origin traffic).
Forgetting logging volume (verbose logs per request can dominate).
Not modeling peaks (bots/incidents/releases) that multiply requests and cache misses.

How to validate

Validate cache hit rate overall and by path, then estimate origin GB from misses.
Validate top endpoints by bytes and request volume (avoid blended averages).
Validate peak periods (deploys/incidents) where retries/purges increase requests and origin traffic.
Validate log payload size by sampling real logs, then multiply by request volume.