CDN
Intermediate 11 min read CDN

CDN Economics & Pricing

Pay attention to the bytes, not the panel

CDN bills follow three levers: data transfer (egress GB), requests (1000s of invocations), and extras (WAF, invalidation, features). A cache-hit-ratio plan is a cost plan, not a performance feature.

egresspricingrequest pricingcache hit ratioinvalidation costdata transfer
Prerequisites: CDN Basics
Before we start

What you will learn

  • Decompose a CDN bill by egress, requests and optional features
  • Compute the break-even of higher TTLs / origin shield / versioning
  • Explain why egress from origin is often the hidden cost
In 60 seconds

Every miss moves origin bytes into the CDN and pays twice: origin egress + edge serving egress. Loud egress stays cheap because hits only pay the edge side. Pricing plans (pay-per-GB vs flattened) reward compression, cache tuning and shields.

Introduction

What is this?

Billing surfaces: data transfer out (edge→user, GB, tiered rates), invocations/requests (per 1000 requests at edge), feature add-ons (WAF, real-time logs, custom functions, premium routing tiers), invalidation/allowed (CloudFront: first free 1000 paths/month then per-path; some purge free). Origin egress: new CloudFront egress owes the S3 egress unless using OAC special rates; FrontDoor similar egress rules. Shield/3-tier pricing: prefixes vs nearest-edges. Free tier: generous for CloudFront (1TB/mo, 10M requests) and limited for others. Cache-hit-ratio (CHR) = hits/total requests × 100; 10% CHR vs 98% CHR can multiply the bill ~8x at the same traffic volume.

Motivation

Why do you need it?

  • Egress, not caching, is usually the biggest CDN line item.
  • Each percent of CHR is a real dollar figure on millions of requests.
  • Invalidation and functions are repeatable, silent costs on active (rapid rollouts) teams.
  • Knowing the pricing plan lets you choose flattened vs pay-per-use for your shape.
Think about it

Mental model

Imagine

A post office charging per letter you send out, plus a surcharge for each held box you empty

Think of

CDN egress + invalidation

Every letter you dispatch costs; emptying your whole P.O. box each day (mass invalidation) has its own fee and defeats the purpose of keeping copies there.

Mechanics

How it works

  • The unit 'served byte' prices differ by hop: edge→viewer (GB billed) vs viewer→edge (free).
  • Misses produce two charges: origin egress + edge egress on the returned assets.
  • Hits produce only the edge egress — the origin never pays for a served copy.
  • Fine features attach per request (functions, WAF) and per action (invalidations).
  • Firms on the same volume but different CHRs see bills that diverge super-linearly.

Who pays which hop.

Viewer
Edge hit
Edge miss
Origin
Edge
Hands-on

Examples

Rough egress math

Rough egress math
traffic = 10 TB/mo served edge-to-user
CHR = 0.95 → origin fetches 0.5 TB → cheap egress
CHR = 0.50 → origin fetches 5 TB → 10x origin egress + edge side
# levers: hash filenames + long TTLs + origin shield + gzip/brotli
cloudfront free tier guardrail: 1 TB/mo + 10M requests

The same 10TB of user traffic produces wildly different bills purely from hit ratio and where the fetch happens.

Real world

In production

  • Flat 'loud egress' package from a big-VNIP provider for a video scale-up.
  • gzip/brotli + WebP decision on large assets to buy both latency and bytes.
  • Set an invalidation budget in Terraform so rollbacks that purge thousands of paths don't surprise the bill.
  • Measure per-origin CHR and alert when it dips under 90% for a sustained window.
Guidelines

Best practices

  • Gzip/brotli over larger assets; images via responsive formats — cheaper than any CDN bargain.
  • Version assets and set long TTLs; never mass-invalidate on a routine deploy.
  • Track egress by origin group and CHR in the monthly review, not just latency.
  • Use the origin shield to temper hot-fetch bursts between edges and origin.
  • Re-negotiate a just-to-egress plan once CDN volume and CHR profile stabilize.
Watch out

Common mistakes

  • Focusing only on edge egress while origin egress runs un-cached in parallel.
  • Confusing 'we have a CDN' with 'we have a cache that hits' — 20% CHR is mostly an origin bill.
  • Deploying unversioned assets and invalidating whole distributions daily (double billing).
  • Caching big media only after the fact — precaching/flushing theory misses peak predictability.
When things break

Debugging tips

  • Bills: compare data transferred at edge vs origin to expose uncached twins.
  • Re-run the p95 file size + CHR product to see which single asset dominates the GBs.
  • Verify with S3 egress line — if it trends with edge egress, CHR is deceivingly low.
  • Sprint refresh the free-tier: track what costs a cent per 1000 requests and optimize the top one.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

Which two hops are billed on a cache miss?

2

The single most cost effective CDN tuning is:

Go deeper

Official documentation