Amazon CloudFront

What is CloudFront?

Amazon CloudFront is AWS’s content delivery network: 600+ edge locations serve cached copies of your content from near the user, falling back to your origin (S3, ALB, any HTTP server) on cache misses. Beyond static assets, it terminates TLS at the edge, fronts APIs to shave connection latency (edge-terminated handshakes ride AWS’s backbone to origin), and integrates natively with WAF, Shield, and ACM certificates.

The AWS-specific advantages worth knowing

Origin Access Control lets S3 buckets stay fully private while CloudFront serves them — the correct static-site pattern, eliminating the public-bucket class of breach. Edge-to-origin traffic from S3 is free; you pay CloudFront egress instead of S3 egress, usually at better rates. Functions at the edge (CloudFront Functions for lightweight header/URL manipulation at ~microsecond scale; Lambda@Edge for heavier logic) handle auth redirects, A/B routing, and header normalization without touching origin. Signed URLs/cookies gate paid content at the edge.

Cache-hit ratio is the entire game

Every miss pays origin latency and origin load. The levers: correct Cache-Control from origin (no headers ≈ no caching), cache policies that exclude irrelevant query strings and headers from the cache key (each unique key combination is a separate cached object — forwarding all headers silently reduces your hit ratio toward zero), and versioned asset filenames so long TTLs are safe. Watch the ratio in CloudWatch; below ~85% on static-heavy workloads, your policy — not your traffic — is usually the culprit.

What people get wrong

• Invalidation as a workflow: paths beyond the free tier cost money and take minutes; versioned filenames make invalidation an emergency tool, not a deploy step.
• Forwarding cookies/headers “just in case” — cache-key cardinality explodes and hit ratio collapses.
• Testing from one location and calling latency solved; edge performance varies by geography — measure from where users are.

Primary source: Amazon CloudFront documentation

Cache Hit Ratio as the Central Optimization Metric

A CDN’s entire value proposition depends on how often requests are served directly from an edge cache rather than requiring a trip back to the origin — a metric called cache hit ratio. Optimizing CloudFront configuration (cache key settings, TTL values, cache behaviors per URL path pattern) to maximize cache hit ratio is the primary lever for both improving user-facing latency and reducing origin load and associated data transfer costs, which is why CDN configuration tuning is treated as an ongoing performance and cost optimization exercise rather than a one-time setup task — a poorly configured cache key (one that includes unnecessary query parameters or headers, for example) can silently fragment what should be a single cacheable response into many separately cached variants, tanking the hit ratio without any obvious error appearing anywhere in the system.