CDN Cost Calculator: Estimate Bandwidth, Requests, and Monthly Pricing Fast

When this CDN calculator is useful

Use this page when you need a fast monthly estimate, but you still want the estimate to reflect how CDN bills actually behave in production. The page works best when you are doing one of three jobs: budgeting a new CDN, comparing providers with the same traffic profile, or explaining why a recent spike came from requests, bandwidth, or cache behavior.

• Use one traffic profile across vendors if this is a provider comparison.
• Keep baseline and peak scenarios separate if this is a budgeting exercise.
• Model origin egress separately if your cache hit rate is unstable.

What to model before you trust the number

• Edge bandwidth: GB delivered to users from the CDN edge.
• Request fees: billable request units, usually per 10k or per 1M.
• Origin egress: separate from edge delivery when cache fill or miss traffic is billed.
• Traffic mix: large media tends to be bandwidth-heavy; APIs and small assets often become request-heavy.

Most bad CDN estimates come from mixing those four ideas together. This page intentionally keeps the first-pass model simple: estimate bandwidth and request fees here, then add origin-side transfer only if it is a real billed line item for your setup.

1) Bandwidth

Use monthly GB delivered by the CDN to end users (edge bandwidth). If you only have Mbps, convert it to GB/month with the Units Converter or this guide: estimate CDN bandwidth.

This calculator is intentionally simple: bring your own pricing assumptions, then sanity-check the result against provider billable units (GB vs GiB, per-10k vs per-1M requests, region tiers).

2) Requests

Some providers charge per request (often per 10k or per 1M). If you have RPS, convert it to requests/month first.

Use RPS to Monthly Requests if you start from traffic charts rather than a billing export. For pricing units and conversion tips, read CDN request pricing.

Build scenarios instead of relying on one average month

• Baseline: typical month (normal traffic, normal cache behavior).
• Peak: launches, incidents, seasonal spikes (often where request fees surprise teams).
• If pricing is tiered, run separate scenarios for each tier/region mix and sum the totals rather than using one average rate.

Tip: use the new "Save scenario" button at the top to keep a baseline and peak link you can revisit.

Quick formula and worked example

• Total CDN cost = edge bandwidth cost + request fees.
• Edge bandwidth cost = GB/month x $/GB.
• Request fees = requests/month x ($ per 10k or $ per 1M converted to same unit).
• Complete cloud edge view = total CDN cost + origin egress (modeled separately).

• Edge bandwidth: 6,000 GB/month x $0.05 = $300.
• Requests: 400M/month x $0.0075 per 10k = $300.
• Origin egress: 600 GB/month x $0.09 = $54 (modeled separately).

How to compare providers without distorting the result

• Lock one traffic profile first, then swap only rates and free-tier assumptions.
• Keep request units explicit so you do not confuse per-10k and per-1M pricing.
• Do not hide region mix or tiering inside one vague blended rate if vendors price geography differently.
• Keep origin egress outside the core CDN line unless every provider comparison handles it the same way.

If the comparison gets noisy, stop adding more assumptions and normalize the traffic profile again. Most vendor comparison mistakes come from changing traffic shape and pricing inputs at the same time.

Validate the estimate before you use it in a budget review

• Use billed edge GB and billed request units when available; analytics exports are second-best.
• Check whether the bill spike came from bandwidth, request count, or cache behavior before changing architecture.
• Track origin egress separately when cache hit rate changes, or you will misread the source of savings.
• Revisit the model after launches, bot spikes, or image-optimization changes because request mix often shifts first.

A simple quality check works well here: if you cannot point every major input back to either billing, CDN analytics, or a written traffic assumption, the estimate is still too weak for procurement or finance review.

Common failure modes worth checking

• The bill looks too high for the traffic: verify request unit conversion and bot/request bursts.
• The CDN estimate looks cheap but cloud spend stays high: add origin egress and cache-fill transfer.
• Optimization work changed little: check whether bandwidth or requests is the dominant line item first.
• Provider comparison changes every week: lock region mix, free tiers, and traffic profile before comparing again.

Practical scenario worksheet

Next actions after the first estimate