Azure CDN pricing: estimate bandwidth, requests, and cache fill

CDN pricing becomes predictable when you split traffic into three drivers: edge bandwidth, edge requests, and origin egress (cache fill). Most surprise bills come from cache misses and cold-cache events, not from steady-state hits.

0) Define the boundary (edge vs origin)

Edge bandwidth: bytes delivered from CDN to end users.
Origin egress: bytes from your origin to CDN on cache miss/fill.
Requests: count requests at the edge, and keep a separate estimate for origin requests if your origin pricing cares.

In many architectures you pay for both legs: CDN edge delivery plus origin egress on cache fill.

1) Edge bandwidth (GB/month)

Use a representative traffic window. If you only have RPS, estimate transfer from response size and request volume. If you have a few very large endpoints (downloads, exports), model them separately.

Tools: CDN bandwidth, Response transfer.

2) Requests (per month)

Requests matter for lots of small objects and API-heavy traffic. Convert RPS to monthly requests and keep pricing units explicit (per 10k vs per 1M).

Tools: RPS to monthly requests, CDN request cost.

Split into at least two buckets if needed: API-like (high RPS, small payloads) and download-like (lower RPS, large payloads).
Keep a peak scenario for bot spikes and incident traffic.

3) Origin egress (cache fill)

Origin egress is driven by cache misses. A practical estimate is: origin GB ≈ edge GB * (1 - hit rate). Purges, deploys, and low TTLs reduce hit rate and increase cache fill.

Tool: Egress cost.

Model large objects separately: one media/export path can dominate origin GB even when overall hit rate looks good.
Track hit rate during deploys/purges. Cold cache events are often the root cause of origin spikes.

Worked estimate template (copy/paste)

Edge requests/month = baseline + peak
Edge GB/month = requests/month * avg response size (GB) (split big endpoints separately)
Origin GB/month ≈ edge GB/month * (1 - hit rate)

Common pitfalls

Double-counting edge bandwidth and origin egress.
Using one blended response size when a few endpoints dominate bytes.
Ignoring purge/deploy behavior and cold-cache events.
Mixing request pricing units (per 10k vs per 1M).
Assuming hit rate is stable; it varies by path, TTL, and cache key configuration.

How to validate

Validate hit rate and top endpoints by bytes and requests (avoid blended averages).
Validate origin egress separately from edge bandwidth.
After one billing cycle, reconcile edge vs origin legs and keep a peak scenario for incident windows.