AWS Scenarios
CloudFront WAF Protected Web Edge
Design an internet-facing web edge with CloudFront, AWS WAF, Shield, private origins, origin access control, TLS, logging, caching, rate limits, and exam decision traps.
After this, you will understand
Edge security helps learners separate CDN caching, HTTP filtering, DDoS protection, and origin access instead of treating CloudFront as only a performance service.
Put CloudFront in front of the app, attach AWS WAF, keep the origin private where possible, and log what the edge allows and blocks.
The origin remains publicly reachable, WAF rules are too broad or too narrow, caching leaks personalized data, or teams confuse WAF with network firewalls.
Use CloudFront as the entry point, AWS WAF for HTTP request inspection, Shield for DDoS protection, OAC for private S3 origins, and origin controls for ALB or API origins.
Think before readingWhat problem does OAC solve for an S3 origin?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- CloudFront as the public edge
- AWS WAF web ACLs
- Shield and DDoS protection
- S3 origin access control
- ALB and API origins
- Caching and personalized content
- TLS and viewer policies
- Rate limiting and managed rules
- Edge logs and metrics
- SAA-C03 security traps
1. Situation
A company exposes a public web application. The app serves static assets from S3, dynamic traffic through an ALB, and some API paths through API Gateway.
The team wants lower latency, protection from common web attacks, DDoS resilience, TLS at the edge, and a way to keep origins from being directly abused.
The core design question is:
how do we make the edge the front door without letting attackers walk around it?
CloudFront is the front door. AWS WAF filters HTTP requests. Shield helps with DDoS protection. Origin controls prevent bypass where possible.
2. Naive Design
The naive design exposes the ALB and S3 bucket directly to the internet, then later adds CloudFront for performance.
That leaves two public paths:
user -> CloudFront -> origin
user -> origin directly
If attackers can reach the origin directly, they can avoid some edge protections, increase origin load, or discover behavior that should have been hidden behind CloudFront.
Another naive design attaches WAF and immediately blocks too much traffic without testing. Security rules that break checkout, login, uploads, or APIs create a reliability incident.
3. What Breaks
Origin protection breaks when S3 buckets are public or ALB security groups allow broad internet access without validating traffic came through the intended edge path.
Caching breaks when personalized or authenticated responses are cached without careful cache keys and headers.
Security breaks when WAF rules are used as a replacement for authentication, authorization, input validation, or application security.
Operations break when blocked requests are not logged. During an incident, the team cannot tell whether WAF protected the app or caused the outage.
Cost breaks when CloudFront reduces user latency but WAF rules, logging, invalidations, or origin requests are not understood.
4. AWS Architecture
Create a CloudFront distribution for the application domain. Use ACM certificates for TLS at the edge.
For S3 static assets, use an S3 REST origin with CloudFront Origin Access Control. Keep the bucket private and allow access from the CloudFront distribution.
For dynamic traffic, use ALB, API Gateway, or another supported origin. Restrict origin reachability where possible using security groups, custom headers, origin policies, and service-specific controls.
Attach an AWS WAF web ACL to the CloudFront distribution. Start with managed rule groups, rate-based rules, IP reputation rules, and explicit application-specific rules where useful.
Use Shield Standard by default for supported DDoS protection. Consider Shield Advanced when the business needs enhanced DDoS response, cost protection, or advanced support.
Enable logs and metrics for CloudFront, WAF, and the origin.
5. Request Or Data Flow
A viewer sends an HTTPS request to the application domain.
Route 53 resolves the domain to CloudFront. CloudFront receives the request at the edge.
AWS WAF evaluates the request against the web ACL. It can allow, block, count, challenge, or apply rule actions depending on the configuration.
If the object is cacheable and already in cache, CloudFront returns it without hitting the origin.
If CloudFront needs the origin, it forwards the request according to the cache policy and origin request policy. For S3 with OAC, CloudFront signs the origin request.
The origin responds, CloudFront applies response behavior, and logs capture request outcome.
6. Security Controls
Use OAC for private S3 origins when the bucket should not be public. Remember that OAC applies to S3 REST origins, not S3 website endpoints.
Attach WAF at CloudFront for global edge filtering. Use managed rules as a baseline, but test in count mode when introducing new rules to production traffic.
Use rate-based rules for abusive patterns such as credential stuffing, scraping, or simple request floods. Do not confuse rate limiting with authentication.
Protect the origin. For ALB origins, use security groups, private subnet design where appropriate, and application-level validation. Custom origin headers can help distinguish CloudFront requests, but they are not a full authentication system by themselves.
Use TLS viewer policies and modern security headers.
7. Resilience Controls
CloudFront reduces origin load by caching and absorbing edge traffic closer to users.
Origin Shield can add an extra caching layer to reduce duplicate origin requests during traffic spikes, though it has additional cost.
Use multiple origins or origin groups when the app has meaningful failover options. Test what CloudFront does when an origin returns errors.
Do not rely on WAF to keep a fragile origin alive under all traffic conditions. Autoscaling, queueing, caching, and application resilience still matter.
Log WAF actions and CloudFront status codes so operators can distinguish attack traffic, rule false positives, cache misses, and origin failures.
8. Performance Controls
CloudFront improves read latency for cacheable content. It does not make uncacheable dynamic writes magically fast.
Cache keys matter. Include only the headers, cookies, and query strings required to serve correct responses. Too many key dimensions lower the cache hit ratio.
Do not cache authenticated HTML or API responses unless the application is designed for it.
Compress static assets, use proper TTLs, and invalidate carefully. Frequent broad invalidations can become operational noise.
Keep the origin close to the Origin Shield Region if using Origin Shield.
9. Cost Controls
CloudFront charges are shaped by requests, data transfer, invalidations, logs, and optional features.
AWS WAF charges depend on web ACLs, rules, and request volume. Managed rule groups may add cost.
Shield Standard is included automatically, while Shield Advanced is a paid service.
Origin request reduction can lower ALB, compute, and data transfer pressure. Good caching can make the edge cheaper than repeatedly hitting origin.
Bad caching can do the opposite by sending every request to origin while still adding edge service cost.
10. Exam Variants
"Protect web app from SQL injection and common HTTP attacks" points to AWS WAF.
"Improve global latency for static and dynamic web content" points to CloudFront.
"Keep S3 bucket private behind CloudFront" points to Origin Access Control.
"Protect against DDoS" points to Shield Standard or Shield Advanced depending on required support and cost protection.
"Block too many requests from one IP" points to WAF rate-based rules.
"Inspect non-HTTP VPC traffic" does not point to WAF. Consider Network Firewall or security appliances.
11. Common Traps
Do not leave the origin publicly bypassable when the requirement says traffic must go through CloudFront.
Do not use an S3 website endpoint with OAC.
Do not confuse WAF with security groups, NACLs, or Network Firewall.
Do not cache user-specific responses without cache-key discipline.
Do not skip WAF logging. Count mode and logs are how you tune rules safely.
Do not assume Shield Advanced is always required.
12. Related Topics
Review Amazon CloudFront, AWS WAF, AWS Shield, Amazon S3, and Amazon API Gateway.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.