CDN Cache Hit Savings Calculator

Analysis mode:

Choose whether CDN delivery/request cost is already in your bill or should be added to the target case.

Workload preset:

Use a preset as a realistic starting point, then replace values with analytics, billing, or CDN logs.

Monthly delivered traffic:

Use CDN analytics, origin logs, object storage billing, or a transfer estimate for the same monthly window.

Cacheable traffic share: {{ cacheable_percent }}%

Dynamic, personalized, POST, or bypassed traffic stays uncacheable and still reaches origin.

Current cache hit rate: {{ current_hit_percent }}%

Use traffic hit rate when byte savings matter most; use request hit rate when origin compute dominates.

Target cache hit rate: {{ target_hit_percent }}%

A target below the current hit rate intentionally models a regression or a conservative rollout.

Monthly requests:

Enter 0 when you only want bandwidth savings. Request counts are in millions.

M requests

Origin transfer rate:

Use a blended $/GB from the origin bill, including storage egress or hosting transfer charges.

$ / GB

Origin request cost:

Set to 0 for bandwidth-only analysis, or include origin compute and request costs that disappear on cache hits.

$ / M origin req

CDN delivery rate:

Use a blended CDN $/GB after free tier, regional mix, contract discounts, or flat-fee assumptions.

$ / GB

CDN request cost:

Set to 0 for no-request-fee or flat-fee CDN contracts.

$ / M requests

Check cache savings assumptions

{{ error }}

Miss amplification: {{ miss_overhead_percent }}%

Keep low for clean cache fills; raise it when logs show duplicated pulls or range fragmentation.

Fixed monthly change cost:

Use 0 when fixed fees are already budgeted or not part of the decision.

$ / mo

One-time setup cost:

Payback is shown when monthly net savings is positive.

Planning window:

Annual planning uses 12 months; short trials can use 1 to 3 months.

months

Metric	Value	Planning note	Copy
{{ row.metric }}	{{ row.value }}	{{ row.note }}

Scenario	Hit rate	Origin transfer	Monthly cost	Delta	Copy
{{ row.scenario }}	{{ row.hitRate }}	{{ row.originTransfer }}	{{ row.monthlyCost }}	{{ row.delta }}

Lever	Modeled signal	Monthly impact	Operator action	Copy
{{ row.lever }}	{{ row.signal }}	{{ row.impact }}	{{ row.action }}

{{ formulaText }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A cache hit is valuable when it prevents a real origin cost. That cost might be object-storage egress, application rendering, image processing, API work, database pressure, or request pricing. A higher content delivery network (CDN) hit rate is therefore not automatically a savings case. It becomes one only when the cacheable share, avoided origin work, CDN delivery charges, request volume, fixed monthly costs, and setup effort are counted together.

CDN savings start with a split between traffic that can be reused safely and traffic that cannot. Static assets, versioned media, public downloads, and shared API responses are often cacheable. Personalized pages, authenticated responses, private account data, POST requests, and rapidly changing output usually stay uncacheable or need stricter cache keys. Hit rate applies to the cacheable part, so a high headline percentage can still save little money when most traffic bypasses the edge.

Bytes and requests deserve separate treatment. A software download may have few requests but large origin egress. A small API response may have little bandwidth cost but high compute or request cost. Some misses also amplify origin work because a single client request can trigger retries, redirects, byte-range pulls, image transforms, shield fills, or several backend calls.

A cache project can fail the financial test even when performance improves. CDN request fees, delivery rates, regional traffic mix, a managed cache service, observability costs, engineering time, and the lifetime of the traffic pattern can absorb the savings. For a short launch campaign, payback over the campaign window matters more than an annualized number. For a long-running workload, the better question is whether the target hit rate is realistic without caching unsafe responses.

The practical result is a cost model, not a pure performance score. A strong cache plan usually combines measurable origin reduction with clear operational benefits: less origin load during spikes, fewer repeated backend renders, simpler static-asset delivery, better latency for reusable content, and less exposure to origin egress surprises.

How to Use This Tool:

Use the calculator to compare current and target cache economics for one monthly traffic window. Replace presets with values from CDN analytics, origin logs, object-storage billing, cloud bills, or internal rate cards before using the result for a business case.

Choose Analysis mode. Existing CDN treats CDN delivery and request costs as already present and focuses on tuning. Add CDN compares a direct-origin baseline with a new CDN target state.
Select a Workload preset or use Custom editable model. Presets load realistic starting patterns for media assets, commerce static assets, API JSON edge caching, and software downloads.
Enter Monthly delivered traffic, choose GB, TB, TiB, or PB, and set Cacheable traffic share. Keep the traffic window aligned with the billing and log window used for rates.
Set Current cache hit rate, Target cache hit rate, and Monthly requests. A target below the current hit rate intentionally models a regression or conservative rollout.
Enter Origin transfer rate, Origin request cost, CDN delivery rate, and CDN request cost. Use blended rates when region, tier, contract, or included-allowance effects make the bill uneven.
Use Miss amplification, Fixed monthly change cost, One-time setup cost, and Planning window when misses trigger extra backend work or payback matters.
Read Savings Breakdown for the main comparison, Scenario Ledger for hit-rate sensitivity, Action Brief for operating levers, Hit-Rate Savings Curve and Cost Stack for charted checks, Formula for the calculation note, and JSON for the structured record. Correct any input warning before trusting exports or charts.

Interpreting Results:

Net monthly savings is the main decision number. It subtracts target origin cost, CDN add-ons when they apply, and fixed monthly change cost from the current monthly cost. A negative value does not mean caching is useless; it means the entered financial case does not pay for itself on monthly cost alone.

Gross origin savings shows avoided origin egress and origin request cost before CDN add-ons. It is useful for explaining origin relief, but it can overstate the business case when fixed costs, new CDN delivery charges, or setup work are material.

Break-even hit rate is the realism check. If it is above 99%, hit-rate improvement alone cannot recover the entered costs under the current assumptions.
Origin transfer delta and Origin request delta show whether byte savings or request savings carry the result. Use the one that matches the workload's real bottleneck.
Setup payback appears only when net monthly savings are positive. A project can save money each month but still miss the selected planning window.
Action Brief highlights levers such as a 10-point hit-rate lift, a larger cacheable share, reduced miss amplification, and request-cost exposure. Use these rows to decide whether policy changes, origin shielding, asset versioning, or billing reconciliation should come next.

Technical Details:

The model converts the selected traffic unit to gigabytes, then divides monthly bytes and monthly requests into cacheable and uncacheable portions. Uncacheable traffic remains an origin load in every state. Cacheable misses are reduced by the selected hit rate, and miss amplification increases origin transfer when each miss causes more backend work than the client-visible response size.

The mode choice changes the cost baseline. Existing-CDN mode compares the current CDN state with a tuned target state and excludes unchanged CDN delivery and request charges. Add-CDN mode compares a direct-origin baseline with a target state that includes CDN delivery, CDN requests, remaining origin misses, and fixed monthly costs.

Formula Core:

\begin{array}{lll} B_{origin} (h) & = & (B_{uncacheable} + B_{cacheable} \times (1 - h)) \times a \\ Q_{origin} (h) & = & Q_{uncacheable} + Q_{cacheable} \times (1 - h) \\ K_{origin} & = & B_{origin} \times r_{GB} + Q_{origin} \times r_{request} \\ K_{target} & = & K_{origin target} + K_{CDN delivery} + K_{CDN requests} + K_{fixed} \\ S_{net} & = & K_{current} - K_{target} \end{array}

CDN cache hit savings formula variables
Symbol	Meaning	Field or result
`h`	Cache hit rate as a fraction from 0 to 0.99	Current or Target cache hit rate
`B`	Monthly delivered traffic in gigabytes	Monthly delivered traffic and traffic unit
`Q`	Monthly requests in millions	Monthly requests
`a`	Miss amplification factor, 1 plus overhead percent	Miss amplification
`r_GB`	Origin egress cost per gigabyte	Origin transfer rate
`r_request`	Origin request or compute cost per million requests	Origin request cost
`K`	Monthly cost component	Origin, CDN, fixed, current, and target costs

Break-even hit rate is solved from the same cost equation by asking which hit rate makes current cost and target cost equal. When the avoided value of a cacheable hit is zero, the break-even rate is unavailable. When the required rate is above 99%, the entered rate card and fixed costs cannot be recovered by hit-rate improvement alone.

CDN cache hit savings validation boundaries
Assumption	Boundary used	Reason it matters
Cacheable share	0% to 100%	Only this share can benefit from hit-rate improvement.
Hit rates	0% to 99%	A 100% target would imply no cacheable misses, which is not a realistic planning denominator.
Miss amplification	0% to 80%	Models extra origin transfer from fan-out, retries, transforms, or shield behavior.
Planning window	1 to 60 months	Turns monthly savings into period impact without letting long horizons hide weak payback.
Traffic units	GB, TB, TiB, or PB	TB and PB use decimal units, while TiB uses 1,024 GB.

With the media asset defaults, 42 TB becomes 42,000 GB. A 92% cacheable share makes 38,640 GB eligible for hit-rate savings and leaves 3,360 GB uncacheable. Moving from 68% to 88% hit rate, with 4% miss amplification, avoids about 8,037 GB of origin transfer and about 69.9 million origin requests. After the $120 fixed monthly change cost, the modeled net savings are about $595 per month and the $2,500 setup cost pays back in about 4.2 months.

Limitations, Privacy, and Accuracy Notes:

The result is an estimate built from entered traffic, hit-rate, rate-card, and cost assumptions. It does not inspect live CDN logs, verify cache keys, detect unsafe caching, apply every provider's regional pricing rule, or prove that a target hit rate is reachable.

Use byte hit rate when origin egress dominates and request hit rate when origin compute, object-store GETs, or API work dominates.
Do not count personalized, authenticated, private, or tenant-specific responses as cacheable unless cache keys and bypass rules protect users.
Reconcile modeled transfer, request counts, CDN charges, and fixed costs against separate bill line items before committing budget.
The calculation uses the values entered in the page. Shared JSON or URLs with saved assumptions can reveal billing and traffic estimates.
Cloud bills may include minimums, regional variation, included allowances, taxes, support charges, negotiated discounts, and provider-specific request classes that are not represented by one blended rate.

Worked Examples:

Media library tuning

A media library uses the default 42 TB monthly traffic, 92% cacheable share, and 380 million monthly requests. Raising hit rate from 68% to 88% lowers modeled origin transfer by about 8.0 TB and origin requests by about 69.9 million. The net savings are positive after the fixed change cost, so the next check is whether cache keys, TTLs, versioned URLs, and invalidation practices can realistically hold an 88% target.

API cache with request-cost exposure

An API workload may have low byte volume but many origin requests. In that case, Origin request cost and Monthly requests can carry more of the savings than bandwidth. If the Action Brief shows request-cost exposure, validate API render cost, object-store operations, shield requests, and any provider charges that disappear only on true hits.

New CDN for a software release

A software-download launch can use Add CDN mode because the target state introduces CDN delivery and request charges. Large cacheable files may avoid substantial origin egress, but the setup cost and a short planning window can still delay payback. Compare period savings with the release window instead of assuming a full-year benefit.

Advanced Tips:

Model the same monthly window used by your CDN analytics and cloud bill. Mixing a traffic peak with average rates can overstate savings.
Raise Cacheable traffic share only after identifying specific paths, object classes, or API responses that can be cached safely.
Use Miss amplification when a miss triggers transforms, origin shield fills, retries, redirects, byte-range reads, or multiple backend calls.
Switch to Add CDN mode when CDN delivery and request charges are new. Keep Existing CDN mode for tuning work where unchanged CDN costs already exist.
Use the Hit-Rate Savings Curve to find diminishing returns. A target plus 5 points may be valuable for large static assets but unrealistic for short-lived personalized content.
Keep a separate operational note for cache invalidation, versioned assets, and bypass rules because the financial result does not prove that the cache policy is safe.

FAQ:

Why can a high cache hit rate still produce weak savings?

Hit rate may apply to a small cacheable share, the avoided origin rate may be low, or CDN and fixed costs may consume the savings. Cost depends on the value of avoided misses, not the hit-rate percentage alone.

Why does Add CDN mode include CDN charges?

Add CDN mode models a new delivery path, so CDN delivery and request costs are part of the target state. Existing CDN mode assumes those unchanged costs already exist and focuses on incremental tuning.

Should request hit rate and byte hit rate be treated the same?

No. Request savings matter when origin requests or application work are expensive. Byte savings matter when origin egress dominates. A small-object API and a large media library can have very different economics at the same hit rate.

What should I check when the break-even hit rate is above 99%?

Check whether CDN delivery cost, fixed monthly change cost, setup cost, or cacheable share is unrealistic for the workload. If the assumptions are accurate, cost savings alone may not justify the project even when performance improves.

Glossary:

Cache hit: A request served from the edge cache instead of going back to the origin.
Cache miss: A request that cannot be served from the edge cache and must reach the origin.
Cacheable share: The portion of traffic that can safely benefit from hit-rate improvement.
Origin egress: Data transferred from the origin or storage service to serve requests.
Miss amplification: Extra origin transfer caused when one client-visible miss creates more backend work than the response size alone suggests.
Break-even hit rate: The target hit rate where current monthly cost and target monthly cost are equal under the entered assumptions.

References:

What is a Cache Hit Ratio?, Cloudflare.
How can using a CDN reduce bandwidth costs?, Cloudflare.
Amazon CloudFront pricing, Amazon Web Services.
How to enable caching in Nginx, Simplified Guide.
How to clear AWS CloudFront cache, Simplified Guide.