CloudFront Hit Ratio and a Second Origin Region
A media site delivers about 400 TB/month of video segments from one S3 bucket in us-east-1 to viewers in North America, Europe, and Southeast Asia. Singapore p95 TTFB is 850 ms. CloudFront sits in front of the bucket, but 30% of viewer requests reach the origin because the cache TTL is 60 s, query strings are forwarded in full, and range requests are common. A dynamic API on an ALB in us-east-1 must remain same-origin with the video for cookie-based sessions. Data transfer out is the largest cost line. The team is considering a second origin region but has not modeled it.
1. Reduce origin load and Singapore latency with configuration changes alone. What do you change, and what do you expect?
Read the worked answer
Treat video segments and the dynamic API as separate cache behaviors:
- Segments are immutable. Use versioned or hashed object names so you can set a long TTL (for example, default 24 hours, maximum 7 days) instead of 60 seconds. This is the single largest lever.
- Stop forwarding all query strings. Forward only the parameters that change the object; otherwise every variant is a separate cache key. Fewer variants means a higher hit ratio.
- Range requests are not the problem. CloudFront supports range requests and can serve them from cache. Confirm the behavior is not configured to bypass caching for range requests.
- Enable Origin Shield in a region close to us-east-1 to collapse simultaneous misses from many edge locations into fewer origin fetches.
- Compression for manifests and API JSON, not for already-compressed video.
Expected effect: origin request share drops from 30% to low single digits. Singapore TTFB improves for cache hits because responses come from the regional edge, but cache misses still cross the Pacific. Measure the miss rate separately; configuration alone cannot fix miss latency.
2. Should the team add a second origin region? Model the tradeoff rather than answering yes or no.
Read the worked answer
Decide with the miss rate, not the total volume:
- At a 95% hit ratio, only about 5% of 400 TB, roughly 20 TB/month, crosses from the origin. A second region improves latency for that slice and improves resilience, but it does not change the experience for the other 95%.
- Adding a region means cross-region replication of the content, additional storage and replication transfer cost, and a routing decision (S3 Multi-Region Access Point or CloudFront origin groups). That is a large fixed cost for a small latency win.
- If the hit ratio stays poor, a second region is treating a symptom. Fix caching first, then re-measure.
Where a second region does pay off is resilience and the dynamic API: use CloudFront origin groups or Route 53 latency/failover routing for the API, and keep the API on a separate cache behavior with caching disabled and cookies forwarded so sessions remain same-origin.
Recommendation: fix caching, re-measure for 30 days, then justify a second origin on availability grounds rather than latency alone.
3. Secure the delivery and control cost without breaking Southeast Asian viewers.
Read the worked answer
Access control: use Origin Access Control from CloudFront to S3 and keep the bucket private. For video, prefer signed cookies over per-segment signed URLs because an HLS or DASH session involves many segment requests; signed cookies authorize the session once. Apply geo restriction only if licensing requires it, since it can conflict with the goal of serving Southeast Asia.
Cost: the dominant lever is cache hit ratio, because every origin fetch incurs S3 request cost and origin transfer. Longer TTLs, query-string normalization, and Origin Shield all reduce that. Compression reduces transfer for text assets.
Price class: a North America and Europe price class would exclude the Southeast Asian edges and hurt the Singapore users who are already the worst case. Keep the edges needed for the audience, and model the cost difference rather than assuming the cheapest class is correct.
Track CacheHitRate per behavior and cost per delivered TB monthly; a hit-ratio regression is both a latency and a cost incident.