CloudFront WAF Protected Web Edge — Quick Learn
A regional web application works, but global users travel to that Region for every request, repeated static content keeps reaching the backend, malicious HTTP requests consume application capacity, and attackers may bypass a newly added edge by calling the origin directly.
The goal is one fast, protected global entrance—not merely another box in front of an open backend.
Four Pressures, Four Controls
- CloudFront receives viewer requests at edge locations near users, returns reusable cached responses, and sends cache misses to a configured origin such as S3 or an ALB.
- AWS WAF attaches a web access control list to CloudFront and evaluates HTTP/HTTPS request properties with managed, custom, and rate-based rules.
- AWS Shield provides managed distributed denial-of-service (DDoS) protection against floods intended to exhaust a public service. Shield Standard supplies automatic baseline protection; Shield Advanced is a paid choice for requirements such as enhanced response support and eligible cost protection.
- Origin protection prevents users from bypassing CloudFront and WAF. The exact control depends on whether the origin is S3 or an ALB.
These controls are not extra proxy fleets in a chain. WAF is associated with CloudFront, and Shield protects the perimeter. CloudFront remains the public request entrance.
A Viewer Request Has Three Outcomes
- Route 53 answers DNS so the client can find CloudFront. DNS is not part of the HTTP data path.
- WAF evaluates the viewer request. A matching block or challenge action stops it before the origin does work.
- For an allowed request, CloudFront checks the matching cache behavior. That rule chooses the origin, cache policy, and request details to forward.
- A cache hit returns a fresh reusable response directly from the edge; the origin does no work.
- A cache miss reaches the selected protected origin. CloudFront returns the response and caches it only when the rules allow reuse.
For example, /assets/app.42bd.js can use S3 and aggressive caching, while /api/orders/42 can reach an ALB and remain unshared. CloudFront improves delivery only when reuse is correct; it does not make every dynamic or personalized request a cache hit.
Close The Side Door Around The Edge
CloudFront and WAF cannot protect traffic that never reaches them.
For a regular S3 origin, keep the bucket private and use Origin Access Control (OAC). CloudFront signs its S3 request, and the bucket policy authorizes the intended distribution. OAC is a trust mechanism, not a network hop. It does not work with the S3 static website endpoint, which CloudFront treats as a custom HTTP origin.
For an ALB origin, prefer a CloudFront VPC origin when the design supports an internal ALB. If the ALB remains internet-facing, restrict origin access to intended CloudFront traffic—for example, with the AWS-managed prefix list containing CloudFront's origin-facing IP ranges and a secret header checked by an ALB listener rule. OAC is not the ALB control.
Read deeper into private S3 and protected ALB originsWAF And Shield Protect Different Layers
WAF understands web request details. It can match common injection patterns, suspicious paths, IP conditions, or excessive rates from a source. Start new rules in count mode, inspect logs and sampled requests, and test login, checkout, uploads, APIs, and health checks before blocking. A false positive is an availability incident even when the rule also stops attacks.
WAF does not replace authentication, authorization, input validation, secure code, or general routed VPC traffic inspection.
Shield focuses on DDoS resilience. A WAF rate rule can slow an abusive source, but a distributed flood can involve many sources and network layers. Shield and WAF can work together; they are not interchangeable, and every public workload does not automatically justify Shield Advanced.
Cache Only Responses That Are Safe To Share
The core cache question is: Can this response correctly serve another matching request?
- Versioned JavaScript, CSS, images, and public downloads are strong cache candidates.
- Personalized pages, login, checkout, and writes normally reach the origin unless the application deliberately defines safe cache behavior.
- A cache key that includes too little can mix responses that should differ; one that includes too much makes most requests unique and destroys the hit ratio.
CloudFront can reduce origin load and keep some fresh cached objects available during origin trouble. It does not make an unhealthy dynamic origin highly available; cache misses still need healthy regional capacity.
SAA Recognition And Traps
- Global users and reusable content → CloudFront, because edge locations can answer safe cache hits without regional work.
- Block SQL injection, cross-site scripting patterns, or abusive HTTP rates → AWS WAF, because it inspects supported web requests.
- Private S3 content served only through CloudFront → regular S3 origin + OAC + restrictive bucket policy.
- Prevent direct ALB bypass → private VPC origin or ALB-specific network and listener restrictions—not OAC.
- Common DDoS protection → Shield Standard; choose Advanced only when its additional capabilities match the requirement.
- Inspect non-HTTP routed VPC traffic → consider AWS Network Firewall; WAF is not a general network firewall.
Do not assume adding CloudFront closes the origin, every response should be cached, WAF solves application security, or Route 53 filters requests.
One-Minute Review
Route 53 resolves the name
↓
CloudFront receives the HTTPS request globally
↓
WAF blocks/challenges or allows it
↓
Allowed cache hit → edge response, no origin work
Allowed cache miss → protected S3 or ALB origin
↓
Shield protects against DDoS; origin controls prevent bypass
If you remember only one thing: CloudFront delivers, WAF filters web requests, Shield mitigates DDoS, and origin controls close the side door.