CloudFront

CloudFront is AWS's CDN: edge locations cache responses close to users. Origins can be S3, ALB, API Gateway, or custom HTTP servers. A FullStack team uses it to accelerate static Next.js assets, cache GET APIs cautiously, and terminate TLS at the edge.

| Control | Effect | |---------|--------| | Cache policy | TTL, headers in cache key, query string behavior | | Origin request policy | Which headers/cookies reach the origin | | OAC / OAI | Private S3 access without public buckets | | Invalidation | Purge paths after deploy — costs add up |

Use separate behaviors for `/_next/static` versus dynamic HTML. Set security headers (HSTS, CSP) via response headers policy. Enable access logs or real-time logs for debugging cache misses.

On interviews: cache key design, stale-while-revalidate patterns, signed URLs/cookies, WAF at edge, and why you must not cache authenticated API responses blindly.

Common pitfalls: caching `Set-Cookie` responses; long TTL on HTML during active development; origin exposed publicly when only CloudFront should reach it; ignoring geographic pricing tiers.

The trade-off is global latency and offload versus cache invalidation complexity and debugging distributed behavior.

Checklist:

• Split behaviors for static assets and dynamic routes.
• Lock S3 origins behind OAC; restrict origin security groups to CloudFront.
• Tune TTLs and cache keys for your API semantics.
• Automate invalidation or use versioned asset filenames.