CDN costs: build a bandwidth and request budget

A useful CDN estimate starts with the traffic your application serves. A low advertised transfer rate tells you little about the final bill until you know the audience, response sizes, request count, cache behavior, and features required. A download service and a small-response API can transfer the same number of bytes while producing very different request volumes.

This guide explains how to build a comparison you can update as traffic changes. All monetary examples below use invented planning rates, expressed in US dollars. They are illustrative calculations, not current provider prices, quotes, or EliteCDN.com service offers.

Start with a workload inventory

Collect a representative period of existing traffic, including ordinary weekdays, weekends, and known campaigns. Record transferred bytes, requests, audience regions, response status codes, and the largest content categories. Keep a separate estimate for a launch or event that the historical period does not represent. For a new application, write down assumptions explicitly and replace them with measurements after launch.

Page views are an incomplete billing input. One visit can request HTML, stylesheets, JavaScript, fonts, images, API responses, and video segments. Browser caching can remove some network requests; automated traffic can add others. Estimate what reaches the CDN, then distinguish what the CDN sends to your origin. Keeping these counts separate makes later invoice reconciliation much easier.

Understand the commercial model

A usage model can charge separately for viewer data transfer, requests, or optional services. A bundled plan can combine several services within a recurring charge. A negotiated agreement can introduce minimum commitments and workload restrictions. Compare the actual offer available to your application, including allowances, limits, renewal terms, and treatment of unusually high traffic.

For a primary-source example of itemized categories, the Amazon CloudFront pay-as-you-go pricing documentation separates transfer, requests, and additional features. Its rates and eligibility rules are provider-specific and can change. The comparison method here remains useful even when your preferred provider bundles those categories differently.

Build two views of each proposal: the cash amount payable each month and the effective cost at your expected usage. A minimum commitment might lower a headline rate while increasing what you pay during quiet months. Ask whether unused capacity carries forward, and avoid counting promotional credits as permanent savings.

Keep bytes, bits, GB, and GiB consistent

Data transfer describes an amount; bandwidth also commonly describes a transfer rate. A link measured in megabits per second does not directly tell you the monthly amount transferred. Eight bits make one byte, and the time spent transmitting matters. Avoid converting a peak connection speed into a monthly volume as though the connection runs at that peak continuously.

NIST distinguishes decimal gigabytes from binary gibibytes: one GB is 1,000,000,000 bytes, while one GiB is 1,073,741,824 bytes. Consequently, 1,000 GB is approximately 931.3 GiB. Neither label should be silently substituted for the other in a budget. Record the provider's documented billing definition beside the rate, and normalize all inputs before comparing totals.

Also establish whether your measurement represents compressed response bodies, total transferred bytes, or another definition. A browser report and a billing export can measure different things. Preserve the original byte counts so the conversion can be audited.

Build an illustrative monthly calculation

Suppose a workload serves 2,000 decimal GB and 20 million requests in one month. For this example only, assume a transfer rate of $0.04 per GB, a request rate of $0.70 per million, and a fixed $15 monthly feature allowance in your internal budget. Assume no discounts, included usage, taxes, or geographic differences.

This subtotal is a model, not a complete infrastructure bill. Add origin hosting, applicable origin transfer, storage, monitoring, and support when they fall outside the chosen service. If a tiered price schedule applies, calculate each usage band separately. Multiplying all traffic by the cheapest published tier can materially understate an estimate.

Run at least a normal and a busy-month scenario. Doubling requests does not necessarily double bytes: a burst of small API calls behaves differently from a popular video. Change the inputs independently so the estimate reveals which assumptions matter most.

Use a sensitivity check to guide investigation. In this invented model, removing 250 GB saves $10 in transfer charges, while removing one million requests saves $0.70 in request charges. Those figures explain where to look first for this particular workload; another rate structure could reverse the priority. Include the engineering effort and any new feature charges before calling an optimization a saving. A technically elegant change that saves only a small amount each month can reasonably wait behind a reliability improvement or a reduction in a much larger origin bill.

Understand where caching changes cost

A cache hit can save an origin fetch while still delivering bytes from the CDN to the visitor. Therefore, a higher hit ratio does not automatically reduce billed viewer transfer. Its value can appear in reduced origin traffic, less application work, and lower peak load. Whether those reductions save money depends on how the origin resources are billed.

Track request hit ratio and byte hit ratio separately. Serving many small files from cache can produce an encouraging request ratio even while large misses dominate origin transfer. Segment the measurements by content type and region before changing policy.

Unnecessary query parameters, cookies, and headers in a cache key can create separate copies of identical content. Review those inputs with the application team and use the Cache-Control and CDN caching guide to identify content that can safely be shared. Never remove a variation that separates personalized responses merely to improve the numbers. Broad cache purges also deserve investigation when they repeatedly trigger expensive origin work.

Reduce unnecessary delivery before buying more

Start with the largest recurring transfer categories. Oversized images, duplicate downloads, unnecessary preloads, and media fetched before a visitor requests playback can make a traffic forecast look like an infrastructure problem. Measure user-visible behavior before and after each change. Removing bytes is useful only if the page or application still does its job.

For images, compare displayed dimensions with delivered dimensions and inspect format and quality choices. Our image optimization guide explains how to connect those decisions to delivery. Include any image processing charges in the comparison: reducing transfer while paying for many unnecessary transformations may move the cost elsewhere.

Account for geography and supporting services

When a contract uses geographic rates, calculate a weighted estimate from the expected audience distribution. Repeat the estimate for plausible expansion markets. A cheap result for today's audience might change when a campaign succeeds elsewhere. Evaluate acceptable performance alongside cost before restricting which locations serve traffic.

Make a short inventory of every enabled feature and its billing basis. Depending on the provider and plan, logging, edge execution, cache invalidation, security services, or support can be included or separately charged. For logs, consider the destination's ingestion, retention, and query costs as well as the CDN's export costs. Assign an owner to each feature so unused experiments do not become permanent expenses.

Turn the estimate into an operating habit

Set alerts around both expenditure and the measurements that explain it. A sudden change in origin requests, average response size, or geographic mix can reveal a problem earlier than a monthly invoice. Budget alerts should be treated as notifications unless the provider explicitly documents an enforced spending cap.

Review a sample invoice against the model after deployment. Investigate the largest difference first, document the explanation, and update the assumptions. If a second provider is being considered, include integration and testing effort using the multi-CDN strategy guide. A rate comparison alone cannot show the total cost of operating both services.

Choose a budget you can explain

A defensible CDN budget connects measured requests and bytes to documented billing rules. Keep units explicit, label estimates, separate viewer delivery from origin work, and check the services surrounding the CDN. With that structure, a changing invoice becomes something the team can investigate and manage rather than a surprising number with no clear cause.