How to estimate cloud egress costs for a media site

Quick answer: Estimate cloud bandwidth by tracing where each byte travels. For a public media site, calculate bytes delivered to visitors at the CDN, bytes fetched from object storage or another origin on cache misses, stored GB-months, and request or retrieval operations. Apply each provider’s current charge and allowance to the correct route. A high cache hit rate can reduce origin traffic while the CDN still delivers the full visitor payload.

Important constraint: Do not add a generic origin-egress charge to every architecture. Amazon S3’s pricing lists an exception for transfer from S3 to CloudFront; CloudFront’s visitor delivery is a separate pricing question. Cloudflare R2 lists free egress bandwidth from R2 while storage, operations, some retrieval, and other metered services can still matter. A provider’s word “free” applies to its named meter, not automatically to the whole site.

“Cloud egress” is often used as a single line item, but a media-site bill can have several independently metered stages. A visitor requests an image. A CDN edge may serve a cached copy, or it may request the object from storage. Storage holds the object over time. The CDN sends bytes to the visitor. Image transformation, cache invalidation, and requests may add their own terms. The useful estimate names these stages before inserting prices, so it cannot silently charge the same transfer twice or omit a delivery leg.

Start with bytes delivered, then work backward

Suppose a site serves 1,000,000 public asset responses during a month, and each response transfers an average of 200,000 bytes of image or video-preview payload. For this example, every request transfers that payload; real conditional requests, partial responses, errors, and size variation need separate measurement. The edge-delivered total is:

1,000,000 requests × 200,000 bytes = 200,000,000,000 bytes = 200 GB, using decimal GB (1 GB = 1,000,000,000 bytes).

Do not quietly substitute GiB, where one unit is 1,073,741,824 bytes, when a provider bills in GB. Record the provider’s unit and any rounding rule. Even a correct byte count can yield the wrong bill if the price unit is interpreted differently.

Now assume a 90% byte hit ratio at the CDN: 90% of delivered bytes come from cache, and 10% must be fetched from origin. The modeled origin response payload is 200 GB × 10% = 20 GB. At a 50% byte hit ratio, origin response payload becomes 100 GB. In both cases, visitors still receive 200 GB from the edge. The cache changes where the CDN obtains those bytes; it does not erase the bytes sent to visitors.

This is a byte hit ratio. A request hit ratio answers a different question: what fraction of requests were handled from cache. If a 5 MB video preview misses while many tiny thumbnails hit, request hits can look high even though the origin sends most bytes. Never multiply “90% requests hit” by total traffic to infer 20 GB of origin data unless object sizes and response behavior support that conversion. Ask your CDN analytics for both measures where available, or calculate bytes from logs.

Put each meter in its own row

Build a line-item sheet with separate quantities and rates. The table gives a general model; a particular provider may include, waive, round, or combine some rows.

A symbolic monthly estimate is storage GB-month × storage rate + billable origin GB × applicable route rate + billable CDN GB × delivery rate + request and retrieval charges + other used services − applicable allowances. Calculate allowances within each provider’s billing rules rather than subtracting a universal free amount at the end. Rounding can apply per class or billable unit, and taxes or contractual commitments may be separate. Keep the source URL and date beside every rate. The result is a workload estimate until the provider-specific meters and actual traffic can be checked against a bill.

Storage is not the same as transfer. A 50 GB library retained for the whole month is roughly 50 GB-months before the provider’s measurement and rounding rules, even if those objects are downloaded many times. Conversely, a small library of popular thumbnails can generate far more delivery bytes than its stored size. If originals, resized variants, and backups occupy separate objects, add their stored footprint; do not count only the original upload folder.

Requests also diverge from bytes. A cache miss can mean a storage read, while a hit may be served by the CDN without an origin read. Writes occur when assets or variants are uploaded or replaced. A listing or metadata check can add operations without delivering a full object. R2’s pricing page separates Class A and Class B operations and describes storage-class retrieval terms. Map your actual operations to those classes; do not treat one million visitor requests as automatically one million storage reads.

Apply route-specific exceptions before calculating money

For an S3 origin feeding CloudFront, AWS’s S3 pricing page lists transfer from S3 to CloudFront as an exception to ordinary S3 data-transfer-out charging. Do not multiply the hypothetical 20 GB or 100 GB origin payload by a generic S3 internet-egress rate for that exact route. That does not make CloudFront delivery free: the edge still sends 200 GB to visitors, and its applicable delivery and request terms need separate checking. S3 storage, requests, storage class, region, and retrieval terms remain part of the estimate.

For Cloudflare R2, the current R2 pricing documentation lists egress bandwidth from R2 as free. The same page lists stored GB-months and Class A/B operations; Infrequent Access adds retrieval charges and a minimum storage duration. Its free allowance applies to Standard storage under stated rules, and billable-unit rounding matters. If a design uses other Cloudflare products or a separate CDN path, inspect those products’ meters too. “R2 egress free” describes one component; it is not a site-wide zero-bill claim.

These routes should not be squeezed into a single “origin price per GB” column without notes. The model has a place for that term so it can be applied where the provider bills it; put zero or an exception marker with a source where the named route is exempt. Then still calculate all other applicable rows. A generic multi-cloud spreadsheet can be helpful, but only if route-specific conditions are visible to the person reviewing the result.

Check whether the cache assumptions are plausible

Cache math is sensitive to how the site serves assets. MDN’s HTTP caching guide distinguishes shared and private caches, freshness, and validation. A public, versioned image with a stable URL may be a good shared-cache candidate. A personalized or authenticated response may not be. Do not apply a broad public-cache setting to private responses merely to improve a cost forecast.

Ask which events cause an origin fetch: first access to a new object, expiry or revalidation, a changed URL, an explicit purge, or a variant that has not been cached yet. Image resizing can multiply the number of distinct versions of one source. If the site serves width variants at 320, 640, and 1,280 pixels, each variant can have its own cache behavior and stored or transformed footprint. A campaign that sends visitors to a new set of images can have a different hit ratio from a month dominated by repeat views of existing assets.

Some revalidation responses transfer less payload than a full object. Some ranges transfer only part of a file. A failed request may transfer little or no asset content. The simple 200 GB example assumes full 200,000-byte responses and counts origin payload on misses, so it is deliberately easy to audit. Replace that assumption with measured response bytes and status classes when traffic data exists. Keep the dry estimate as a baseline, then compare it with the billing dashboard and CDN logs after launch.

Use a small sensitivity table rather than one confident cache number:

Bound several plausible asset sizes and cache states before choosing a route for high traffic. The largest unknown may be the number of bytes per response, not the storage rate.

Use a provider-specific worksheet and check the first bill

For each candidate route, write down provider, account plan, region, storage class, origin-to-CDN path, request types, included allowance, price unit, rounding, and verification date. Put the traffic inputs above the rate table. Keep public static assets separate from authenticated or personalized responses. Then calculate the same workload through each candidate’s real billing terms; avoid comparing one provider’s storage-only line against another’s complete delivery path.

After deployment, compare forecast and observed quantities, not just total dollars. If the bill is higher, identify whether edge bytes, origin bytes, operations, stored variants, retrieval, or another service departed from the worksheet. Correct the traffic model and refresh volatile prices before the next purchase decision. If the total is lower, still check whether the difference comes from a temporary allowance or promotion that will expire.