AWS Networking & CDN
CloudFront
Global CDN delivering content with low latency from 450+ edge locations worldwide
Amazon CloudFront is a global content delivery network (CDN) that distributes content from 450+ edge locations worldwide, reducing latency by serving requests from the location closest to the user. It integrates natively with S3, ALB, API Gateway, and custom origins, and is AWS's primary solution for accelerating both static and dynamic content delivery.
How CloudFront Delivers Content
When a user requests content, CloudFront routes the request to the nearest edge location (Point of Presence). If the edge has a cached copy (cache hit), it returns it immediately. On a cache miss, CloudFront fetches from the origin, caches the response according to cache behavior rules, then returns it.
| Component | Role | Key Setting |
|---|---|---|
| Distribution | Top-level CloudFront resource with a .cloudfront.net domain | Alternate domain names (CNAMEs) require an ACM certificate |
| Origin | Where CloudFront fetches content on cache miss | Can be S3, ALB, EC2, API GW, or any HTTP server |
| Cache Behavior | Path-pattern rules controlling caching and routing | One default (*) plus any number of path-specific behaviors |
| Origin Request Policy | What headers/cookies/query strings to forward to origin | Avoid forwarding all headers - destroys caching efficiency |
| Cache Policy | What determines the cache key and TTL | Separate from forwarding - key only what varies the response |
| Edge Location | Cache node serving end users | 450+ globally; content cached here after first request |
| Regional Edge Cache | Larger cache tier between edge and origin | Reduces origin load; longer TTL than edge locations |
CloudFront distributions require ACM certificates in us-east-1 (N. Virginia) regardless of where your application runs. This is a common gotcha - a certificate in ap-southeast-1 will not work for CloudFront even if your origin is there.
Cache Behaviors and Cache Key Design
Cache behaviors define how CloudFront handles requests matching a path pattern. The default behavior (*) matches everything not matched by more specific patterns. More specific patterns take precedence.
| Scenario | Cache Behavior Config | Why |
|---|---|---|
| Static assets (/static/*) | TTL: 1 year, compress: yes, no cookies forwarded | Content is versioned by filename hash; aggressive caching is safe |
| API responses (/api/*) | TTL: 0 (no cache) or short TTL, forward auth header | Dynamic data; must validate freshness frequently |
| HTML pages (/) | TTL: 5-60 min, forward Accept-Encoding | Balance freshness vs origin load |
| User uploads (/uploads/*) | Signed URLs required, restrict S3 origin access | Private content should not be publicly cacheable |
Cache key design directly impacts hit ratio. Only include values in the cache key that actually change the response. Forwarding all cookies or all headers fragments the cache and effectively disables caching.
# Invalidate specific paths after a deployment
aws cloudfront create-invalidation \
--distribution-id E1EXAMPLE \
--paths "/index.html" "/static/js/*"
# Invalidate everything (costs $0.005 per path after first 1000/month)
aws cloudfront create-invalidation \
--distribution-id E1EXAMPLE \
--paths "/*"Invalidations cost money after the first 1000 paths per month ($0.005/path). Prefer versioned filenames (app.abc123.js) over invalidations for static assets. Reserve invalidations for emergency cache busting of HTML or config files.
Security Features: OAC, WAF, Signed URLs
CloudFront provides several security layers to protect your origin and control access to content.
| Feature | Purpose | How It Works |
|---|---|---|
| Origin Access Control (OAC) | Prevent direct S3 access, force CloudFront | CloudFront signs requests to S3 with SigV4; S3 bucket policy allows only the OAC |
| Signed URLs | Time-limited access to specific objects | URL includes expiry + signature; used for private downloads |
| Signed Cookies | Time-limited access to multiple objects | Cookie with policy + signature; used for streaming/private sections |
| AWS WAF | Block malicious requests at the edge | Attach a WAF Web ACL to block IPs, SQL injection, XSS, rate limits |
| Geo Restriction | Block or allow by country | Uses IP geolocation; not 100% accurate for VPNs |
| HTTPS Only | Enforce TLS between user and CloudFront | Viewer protocol policy: Redirect HTTP to HTTPS |
| Field-Level Encryption | Encrypt sensitive form fields at the edge | CloudFront encrypts specific POST fields with your public key |
Always use Origin Access Control (OAC) instead of the older Origin Access Identity (OAI) for S3 origins. OAC supports all S3 regions, SSE-KMS encrypted buckets, and is the current AWS recommendation.
Lambda@Edge vs CloudFront Functions
Both run code at the edge, but they target different use cases and have very different performance and cost profiles.
| Feature | CloudFront Functions | Lambda@Edge |
|---|---|---|
| Runtime | JavaScript (ES5) | Node.js or Python |
| Max execution time | 1ms | 5s (viewer) / 30s (origin) |
| Memory | 2 MB | 128 MB - 10 GB |
| Triggers | Viewer request/response only | Viewer and origin request/response |
| Access to request body | No | Yes (origin request/response) |
| Cost | $0.10 per 1M invocations | $0.60 per 1M invocations + duration |
| Latency | Sub-millisecond | Milliseconds |
| Use cases | URL rewrites, header manipulation, simple redirects | Auth, A/B testing, dynamic content generation, image resizing |
Use CloudFront Functions for lightweight viewer-side manipulations (URL normalization, security headers). Use Lambda@Edge when you need more compute, access to the network, or need to modify origin requests.
CloudFront Pricing and Cost Optimization
CloudFront pricing varies by region and traffic tier. Data transfer out (to internet) is the main cost driver, plus HTTP request counts.
| Cost Component | Approximate Price | Optimization |
|---|---|---|
| Data transfer out (US/EU) | $0.0085/GB (first 10 TB) | Compress responses; use cache TTLs aggressively |
| Data transfer out (Asia) | $0.140/GB | Consider price class to exclude expensive regions |
| HTTP requests | $0.0075 per 10,000 | Consolidate small files; use HTTP/2 multiplexing |
| HTTPS requests | $0.0100 per 10,000 | Expected for security; unavoidable |
| Invalidations | $0.005 per path after 1,000 | Use versioned file names instead |
| Lambda@Edge | $0.60 per 1M + duration | Use CF Functions for simple transformations |
Price Class lets you restrict distribution to edge locations in specific regions. Price Class 100 (US/EU/Canada) is cheapest. Use it for services whose users are predominantly in those regions.
Interview Focus Points
- 1How does CloudFront cache behavior path pattern matching work? Which patterns take priority?
- 2Explain Origin Access Control and why you would use it over a public S3 bucket.
- 3A user reports stale content after a deployment. What are your options to fix it immediately and avoid it in the future?
- 4When would you use Lambda@Edge vs CloudFront Functions? Give a concrete example of each.
- 5How would you implement authentication at the CloudFront edge for a private SPA?
- 6Explain the difference between viewer protocol policy and origin protocol policy.
- 7How does CloudFront handle origin failover? What is an origin group?
- 8What is the difference between Signed URLs and Signed Cookies? When do you use each?
- 9How would you set up CloudFront for a Next.js static export with dynamic routes?
- 10Explain how cache key design impacts CloudFront hit ratio and origin load.