CDN Cost Calculator

A content delivery network bills on three meters: bytes served out to users, HTTP requests answered, and bytes held in cache. Which one dominates depends entirely on what the site serves. Video and images push transfer; an API answering many small calls pushes request count; storage is almost never the driver.

Rates differ by provider, by contract volume and, most sharply, by the region a request is served from. Delivery into some markets costs several times what the same gigabyte costs elsewhere, and published rate cards step down as volume rises. A single flat figure cannot represent either of those, so the honest input is a traffic-weighted average across the regions actually served rather than the headline rate at the top of a price page.

Two mechanisms move the transfer meter more than any negotiation. Compression shrinks what crosses the wire, and modern schemes such as Brotli, standardised as an IETF specification, are supported by every current browser. Caching stops the byte being sent at all: HTTP caching, defined in RFC 9111, exists so that a stored response can be reused to reduce both latency and network overhead each time it is served, and every reuse is a request the origin never sees.

Run it with sensible defaults

Using monthly gb transferred of 5,000, cost per gb of 0.08, monthly requests of 20 million, cost per million requests of 1, storage of 500 GB and storage cost per GB of 0.023, the calculation works out to 431.50 a month, or 5,178 a year. The defaults are meant as a starting point, not a recommendation.

The split is the useful part. Transfer is 400 of that bill, requests 20, storage 11.50, so transfer alone is 92.7% of the total, requests 4.6% and storage 2.7%. On a shape like this one, effort spent on storage rates is effort wasted.

The levers in this calculation

Monthly GB Transferred and Cost per GB are the larger levers: a 1% change in either moves Monthly CDN Cost by 0.93%, against 0.03% for Storage Cost per GB. That is not a coincidence. Each input's sensitivity is simply its share of the bill, so transfer at 92.7% of the total moves the result by roughly 0.93% per 1%, and storage at 2.7% moves it by 0.03%.

Transfer volume and transfer rate are interchangeable in the arithmetic, since only their product enters the sum. Halving the bytes served has exactly the same effect as halving the rate paid for them, which is worth knowing because one of those is usually within a team's control and the other usually is not.

How the math works

Total is transfer gigabytes times the transfer rate, plus millions of requests times the per-million rate, plus stored gigabytes times the storage rate. The three components are independent and summed, with the annual figure being twelve times the monthly total.

Two things the model does not see are worth naming, because both add cost rather than reduce it. The first is the second transfer leg: this calculation measures bytes going from edge to user, but every cache miss also pulls the object from the origin, and that origin egress is billed separately by whoever hosts it. At a 90% cache hit ratio, the default 5,000 GB implies roughly 500 GB fetched from origin; at 70% it is 1,500 GB. A site with a poor hit ratio pays twice for the same content.

The second is the pricing structure itself. Rates are tiered by volume and vary by region, so a flat per-gigabyte figure overstates the bill at high volume and understates it for traffic weighted toward expensive regions. Commitment discounts, minimum monthly charges, and separate line items for features such as edge compute or image transformation sit outside the model as well.