GCP Cloud CDN Pricing: Cache Egress, Requests, Cache Fill, and Origin Boundaries
Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.
Cloud CDN pricing becomes predictable when you break it into three drivers, but the real budgeting decision is whether Cloud CDN cost is mainly an edge bandwidth problem, a request-shape problem, or a cache-fill problem caused by weak hit rate. Most surprise bills are caused by cache misses and cold-cache events, not by steady-state hits.
Quick pricing read
Cloud CDN pricing is not one generic delivery line. Google separates cache egress, cache fill, and HTTP or HTTPS cache lookup requests, and those charges do not belong to the same owner as origin egress in every architecture. The key budgeting question is whether the delivery bill mostly belongs on Cloud CDN itself or whether weak hit rate, purges, cold cache behavior, or an external backend path keep shifting cost back onto the origin side.
- Cache egress is the main Cloud CDN surface: this is the bandwidth delivered from Cloud CDN caches to end users, and it is usually the largest visible line item.
- Cache lookup requests are separate: request charges matter most for API-like traffic, sites with many small objects, or traffic patterns where request volume grows faster than bytes.
- Cache fill is not the same as edge delivery: low hit rate, purges, deploys, and cold cache periods increase cache fill even when the visible user-facing bandwidth looks stable.
- Hit rate and purge behavior change the whole bill shape: weak cacheability or repeated invalidation can push the delivery bill away from steady-state CDN economics and back toward origin pressure.
- Origin ownership still matters: origin egress and transfer paths belong beside the Cloud CDN bill when the cost is really created by the backend or origin path rather than cached delivery itself.
This page was updated on 2026-06-18 against the current Cloud CDN pricing page, Cloud CDN overview, and Cloud CDN caching documentation.
Inside the Cloud CDN bill vs beside the Cloud CDN bill
- Inside the Cloud CDN bill: cache egress bandwidth, cache lookup requests, and cache fill tied directly to Cloud CDN cache behavior.
- Beside the Cloud CDN bill: origin-owned egress, external backend transfer, load balancer or origin-path charges, and any backend-side storage or analytics costs that still occur after a cache miss.
- Why this matters: origin egress belongs beside the Cloud CDN bill when the cost is really created by the origin path, because a team can have a reasonable CDN line and still create expensive backend transfer through weak hit rate or external backend design.
0) Define the boundary (edge vs origin)
- Edge bandwidth: bytes delivered from CDN to end users.
- Origin egress: bytes pulled from origin to CDN on cache miss/fill.
- Requests: request count at the edge; keep a separate count for origin if your origin pricing cares.
1) Edge bandwidth (GB/month)
Use a representative traffic window. If you only have RPS, estimate transfer from response size and request volume. If you have a few very large endpoints (downloads, media), model them separately. This is the cache egress side of the bill, not the cache-fill side.
Tools: CDN bandwidth, Response transfer, Unit converter.
2) Requests (per month)
Convert RPS to monthly requests and keep units explicit (per 10k vs per 1M). Request fees often dominate for API-like traffic with small payloads. For many small-object delivery paths, request growth becomes visible before bandwidth looks alarming.
Tools: RPS to monthly requests, CDN request fees.
- Keep a peak scenario for bot spikes and incident traffic.
- If you have many small objects per page, request counts scale faster than bandwidth.
3) Origin egress (cache fill)
Origin egress is driven by cache misses. A practical estimate is: origin GB ~= edge GB * (1 - hit rate). Purges, deploys, and low TTLs reduce hit rate and increase cache fill. If the architecture uses an external backend or a transfer-sensitive origin path, keep that spend beside the Cloud CDN bill instead of blending it into CDN delivery.
Tool: Data egress cost.
- Model large objects separately: one download path can dominate origin GB even when overall hit rate looks healthy.
- Track cold cache events: a purge plus a large deploy can temporarily turn most traffic into cache fill.
Worked estimate template (copy/paste)
- Edge requests/month = baseline + peak
- Edge GB/month = requests/month * avg response size (GB) (split big endpoints)
- Origin GB/month ~= edge GB/month * (1 - hit rate)
Common pitfalls
- Double-counting edge bandwidth and origin egress.
- Using one blended response size when a few endpoints dominate bytes.
- Ignoring purge/deploy behavior and cold-cache events.
- Treating cache fill and origin-owned transfer as if they were the same cost owner.
- Mixing request pricing units (per 10k vs per 1M).
- Assuming hit rate is stable; it varies by path, TTL, and cache key configuration.
How to validate
- Validate cache hit rate overall and by path, and measure changes during deploys/purges.
- Validate top endpoints by bytes and request volume (avoid blended averages).
- Validate whether origin egress belongs to the same budget owner as Cloud CDN delivery or to a separate origin path.
- Validate peak windows where retries or bot traffic increase requests and bandwidth.