AWS CloudFront CDN Setup: Caching, Security, and Lambda@Edge
We configure CloudFront as an edge network to apply logic: A/B testing by headers, redirects without origin calls, geo-blocking, WAF rules. But this flexibility makes configuration nontrivial. Our AWS Certified Solutions Architects have 5+ years of experience with AWS and have implemented over 50 CDN projects for high-load services, saving clients up to $2,500 per month on outbound traffic for a typical 5TB transfer. A common scenario: a team creates a distribution with default settings, goes live, and discovers dynamic content is cached (because Cache-Control is not set on the origin), authenticated API requests return 403 (cookies are not forwarded), and cache invalidation is expensive due to non-optimal cache key policies. We resolve these issues individually for each client, saving up to 70% on outbound traffic costs.
Distributions, Origins, and Behaviors
Origin — data source: S3, ALB, custom HTTP server. For S3, we use OAC (Origin Access Control) — it supports request signing via SigV4 and works with encrypted buckets. This approach reduces security costs by hundreds of dollars per month on a single distribution.
Cache Behavior — a rule defining how CloudFront handles requests by path pattern. Typical configuration:
-
/*→ S3 static assets (with caching) -
/api/*→ ALB backend (no cache or minimal TTL) -
/static/*→ S3 with long TTL (e.g., 31536000 seconds) and origin versioning via URL hash
Cache Policy and Origin Request Policy — intentionally separated. Cache Policy determines what goes into the cache key (headers, query strings, cookies). Origin Request Policy determines what is forwarded to the origin. A common mistake is using Forward: All for headers instead of explicit policies. This breaks caching: each unique User-Agent becomes a separate cache entry, reducing hit rate from 80% to 40%.
SSL and Custom Domains
CloudFront works with ACM certificates (AWS Certificate Manager). Important: the certificate must be created in the us-east-1 region (CloudFront is global, ACM integrated only with that region). For a custom domain, create an Alias record in Route 53 pointing to *.cloudfront.net. Set Minimum TLS Protocol to TLSv1.2_2021, disabling outdated versions.
Lambda@Edge and CloudFront Functions
For logic on CDN, we use two approaches. Comparison:
| Characteristic | CloudFront Functions | Lambda@Edge |
|---|---|---|
| Runtime environment | Lightweight JavaScript | Node.js, Python |
| Network access | No | Yes |
| Max execution time | 10 ms | 5 s (viewer) / 30 s (origin) |
| Memory | 2 MB | 128-3008 MB |
| Regions | All edge PoPs (~450 points) | Regional edges (~13) |
| Latency | Microseconds | Milliseconds |
| Typical tasks | URL transformations, security headers, redirects | A/B testing, authentication, external API calls |
CloudFront Functions are up to 100 times faster than Lambda@Edge for simple URL rewrites (microseconds vs milliseconds). Lambda@Edge is more powerful but more expensive — we choose based on the task.
How to Configure Caching for Static and Dynamic Content?
For static assets, set a long TTL (one year) and versioned URLs with a hash in the file name (main.abc123.js). For dynamic content (API), set a short TTL (0–60 seconds) or disable caching, forwarding authentication headers via an origin request policy. For example, set Cache-Control: max-age=31536000 for static assets.
Why Isn't CloudFront Caching? Common Causes
-
Cache-Controlnot set on the origin — CloudFront assumes caching is not allowed. - Cache policy includes volatile headers (e.g.,
Cookiefor all requests). - Using
Forward: Allinstead of explicit policies.
Cache Invalidation
The first 1000 invalidation paths per month are free. Wildcard /* counts as one operation, but full cache invalidation takes up to 10 minutes. The correct approach is versioned URLs: deployment changes the URL, old files continue to be served from cache. The CI/CD pipeline updates index.html with a short TTL (60–300 seconds) — stale content problem solved without invalidation. According to CloudFront documentation, this is the optimal solution.
Monitoring and Cost
CloudWatch metrics: Requests, BytesDownloaded, 4xxErrorRate, 5xxErrorRate, CacheHitRate. If the cache hit rate is below 60% — optimize cache policies or TTL. Real-time logs via Kinesis Data Firehose → S3 → Athena for traffic analysis.
| Metric | Target | Action on Deviation |
|---|---|---|
| CacheHitRate | > 80% | Increase TTL, check cache key |
| 4xxErrorRate | < 5% | Check origin, access policies |
| 5xxErrorRate | < 1% | Scale origin, check latency |
Typical mistakes when configuring CloudFront:
- Using OAI instead of OAC for S3 (OAI does not support encrypted buckets).
- No access restrictions to origin (triggering lambdas directly).
- Ignoring geo-blocking: CloudFront allows restricting access by country at the distribution level.
Process of Work
- Analytics — audit current architecture, identify bottlenecks.
- Design — choose scheme (multiple origins, cache behaviors, policies).
- Implementation — configure CloudFront, Lambda@Edge, CloudFront WAF, SSL.
- Testing — check caching, response time, geo-blocking.
- Deployment — gradual rollout (canary or blue-green).
What's Included (Deliverables)
- Documentation of distribution configuration, policies, and functions.
- CI/CD setup for automatic invalidation and deployment.
- Team training (runbook, typical operations).
- Post-launch support (1 month monitoring, consultations).
- Access to AWS resources and configurations.
Timelines
Basic distribution setup for static assets — a few hours. Configuration with multiple origins, WAF, Lambda@Edge, and custom policies — 1–3 days depending on complexity. Contact us for an accurate estimate of your project — get an engineer consultation. Accelerated loading reduces user churn, saving up to 30% in conversion. Order a CDN audit and find out how much you can save.