CloudFront WAF Protected Web Edge

1. Situation

Start with the public web application from the previous architecture study:

flowchart LR
  User["User"] -->|"HTTPS request"| ALB["Public Application Load Balancer"]
  ALB --> App["Application"]

This is a sensible regional architecture. The Application Load Balancer, or ALB, is the public entrance, while the application runs behind it.

Now imagine that the application becomes popular outside its AWS Region.

A user in Singapore requests the same logo, JavaScript bundle, and product images as a user in London. Every request still travels to the application's Region. The ALB and application repeatedly serve files that rarely change.

The application also attracts unwanted traffic. Some requests contain common attack patterns. Others arrive so quickly that they may overwhelm the backend. Even if a protected edge is added, an attacker may try to reach the ALB or S3 bucket directly.

The design question is no longer only:

how do we run a public application on AWS?

It has evolved into:

how do we create one fast, protected front door for users around the world?

2. Naive Design

The simplest design sends every user directly to the regional application:

user anywhere in the world -> ALB -> application

This is not automatically a bad design. It may be enough for a small application with mostly local users. It becomes incomplete when the requirements mention global latency, caching, edge security, or reduced origin load.

A common first improvement is to add CloudFront but leave the original endpoints open:

flowchart LR
  User["Normal user"] --> CloudFront["CloudFront"]
  CloudFront --> ALB["Public ALB origin"]
  Attacker["Attacker"] -. direct request .-> ALB

The normal user takes the intended path. The attacker takes the side door.

If the ALB still serves direct requests, controls attached to CloudFront can be bypassed. The same mistake happens when an S3 bucket remains public even though CloudFront is supposed to be its only public delivery path.

The lesson is important:

Adding a front door is not enough. The architecture must also close unnecessary side doors.

3. What Breaks

The architecture faces four different pressures. Each pressure needs a different kind of control.

Pressure 1: every request travels to the Region

A static image does not become more useful because the application server sends it again. Repeated long-distance trips add latency and make the origin repeat work that could happen closer to users.

The architecture needs a global delivery layer that can reuse safe responses.

Pressure 2: malicious web requests reach the application

An ALB can route HTTP traffic, but routing is not the same as inspecting a request for SQL injection patterns, suspicious paths, known bad IP addresses, or excessive request rates.

The architecture needs a web request filter at the public edge.

Pressure 3: the origin remains reachable directly

If an attacker discovers the origin address, the attacker may skip the protected edge. CloudFront and its web request rules cannot protect traffic that never goes through CloudFront.

The architecture needs an origin-specific way to trust the intended CloudFront path and reject direct access.

Pressure 4: a traffic flood is larger than normal application abuse

A rate rule can slow a noisy client, but a distributed denial-of-service attack may come from many systems and target network, transport, or application capacity.

The architecture needs managed DDoS protection in addition to customizable web request rules.

These are related problems, but they are not the same problem. That is why the finished architecture uses several services instead of asking one service to do everything.

4. AWS Architecture

Build the architecture one pressure at a time.

Step 1: add CloudFront for global delivery

Amazon CloudFront becomes the public entry point. Users connect to a nearby CloudFront edge location instead of treating the regional origin as the first stop.

CloudFront uses a distribution, which is the configuration that describes the public domain, origins, cache behavior, HTTPS settings, and other delivery rules.

flowchart LR
  User["User"] -->|"1. Request"| Edge["CloudFront edge location"]
  Edge -->|"2a. Cache hit: respond nearby"| User
  Edge -->|"2b. Cache miss: fetch"| Origin["Regional origin"]
  Origin -->|"3. Response"| Edge

A cache hit means CloudFront already has a fresh reusable response. The origin does no work for that request.

A cache miss means CloudFront needs to ask the origin. CloudFront may then cache the response according to the configured rules.

CloudFront does not make every request fast through caching. A personalized account page, checkout request, or write operation may still need to reach the origin. The first win is understanding that safe, reusable content no longer needs a full regional round trip every time.

Step 2: attach AWS WAF for web request inspection

CloudFront can deliver requests, but delivery alone does not decide whether an HTTP request looks malicious.

Attach an AWS WAF web access control list, or web ACL, to the CloudFront distribution. The web ACL contains ordered rules that inspect HTTP and HTTPS requests.

flowchart LR
  User["Normal user"] --> Edge["CloudFront distribution<br/>AWS WAF web ACL attached"]
  Edge -->|"Allowed"| Origin["Origin"]
  Attacker["Malicious request"] --> Edge
  Edge -. Blocked at the edge .-> Blocked["Request ends"]

AWS WAF is attached to CloudFront; it is not a separate fleet of servers that the request visits afterward.

For this lesson, remember three WAF building blocks:

• Managed rule groups provide maintained protections for common web threats.
• Rate-based rules track excessive request rates and apply an action when a threshold is crossed.
• Count mode records matches without blocking so a team can test a rule against real traffic.

WAF can reduce malicious traffic reaching the application. It does not replace login, authorization, secure coding, or server-side input validation.

Step 3: close the path around CloudFront

Once WAF protects the intended entry point, the next question is whether clients can avoid it.

Origin protection depends on the origin type.

For an S3 origin, keep the bucket private and use Origin Access Control, or OAC. CloudFront signs origin requests, and the S3 bucket policy allows the intended CloudFront distribution to access the objects.

flowchart LR
  User["User"] --> CloudFront["CloudFront + WAF"]
  CloudFront -->|"Signed origin request with OAC"| S3["Private S3 bucket"]
  User -. Direct request denied .-> S3

OAC is not another network hop. It is the trust mechanism on the CloudFront-to-S3 path.

For an ALB origin, apply controls that make CloudFront the intended public path. Depending on the design, that can mean using a private ALB through CloudFront VPC origins, or restricting an internet-facing ALB with CloudFront-specific network and application controls. The exact mechanism differs from OAC, but the architectural goal is the same: direct clients should not receive the application by walking around the edge.

Step 4: understand where Shield fits

AWS Shield provides managed protection against distributed denial-of-service, or DDoS, attacks.

Shield Standard is automatically available to AWS customers and protects against common network and transport layer attacks. Shield Advanced is a paid option for organizations that need stronger detection and response capabilities, specialized support, and DDoS-related cost protection for eligible resources.

Shield is best pictured as protection around the public AWS perimeter, not as another box that every request passes through.

flowchart LR
  DNS["Route 53<br/>DNS"] -. Resolves the application name .-> User["User"]

  subgraph EdgeBoundary["AWS edge with Shield Standard DDoS protection"]
    Edge["CloudFront distribution<br/>AWS WAF web ACL attached"]
  end

  User -->|"HTTPS"| Edge
  Edge -->|"Signed request with OAC"| S3["Private S3 origin<br/>static assets"]
  Edge -->|"Protected HTTPS origin request"| ALB["Protected ALB origin"]
  ALB --> App["Application"]

The finished mental model is:

CloudFront = global delivery and caching front door
WAF        = customizable HTTP request inspection at that door
Shield     = managed DDoS protection around the AWS perimeter
OAC        = CloudFront-to-private-S3 trust

5. Request Or Data Flow

Do not memorize one long request sequence. Learn the three outcomes the edge can produce.

flowchart TD
  Request["HTTPS request reaches CloudFront"] --> WAF{"WAF decision"}
  WAF -->|"Block"| Stop["Return block or challenge response<br/>origin does no work"]
  WAF -->|"Allow"| Cache{"Usable cached response?"}
  Cache -->|"Yes: cache hit"| Return["Return response from the edge"]
  Cache -->|"No: cache miss"| Origin["Send request to the selected origin"]
  Origin --> Response["Origin returns response"]
  Response --> Return

Outcome 1: allowed request and cache hit

Route 53 resolves the application domain to CloudFront. DNS helps the client find the entry point; the application request itself then goes to CloudFront.

WAF evaluates the web request. If the request is allowed and CloudFront has a usable cached response, CloudFront returns it from the edge. The origin is not contacted.

This is the ideal path for versioned JavaScript, CSS, images, downloads, and other public content that can be safely reused.

Outcome 2: allowed request and cache miss

WAF allows the request, but CloudFront does not have a usable cached response. CloudFront selects the correct origin and forwards the request according to the distribution behavior.

If the origin is private S3 with OAC, CloudFront signs the origin request. If the origin is an ALB, the ALB forwards the request to a healthy application target.

The origin returns a response. CloudFront sends it to the viewer and may cache it if the cache rules allow that response to be reused.

Outcome 3: WAF blocks the request

The request matches a blocking rule, such as a tested managed-rule signature or a rate-based rule. WAF blocks or challenges the request at the protected edge. The application origin does no work for that request.

This flow explains the value of combining the services: CloudFront decides how to deliver allowed traffic, while WAF decides which web requests satisfy its rules.

6. Security Controls

Secure the architecture from the viewer toward the origin.

Protect the viewer connection

Use an ACM certificate with CloudFront for the application domain. Redirect HTTP viewers to HTTPS or require HTTPS so credentials, session cookies, and response data are encrypted between the viewer and the edge.

Use HTTPS between CloudFront and custom origins such as an ALB when sensitive traffic crosses that connection.

Inspect web requests at the edge

Start WAF with a small, explainable policy:

1. Add appropriate managed rule groups.
2. Add rate-based rules for abusive request patterns.
3. Run new rules in count mode.
4. Review sampled requests, logs, and application behavior.
5. Move a rule to block only after legitimate traffic is understood.

A security rule can cause an availability incident. A rule that blocks checkout, login, file uploads, health checks, or API clients is not safe merely because it blocks some attacks.

Protect each origin correctly

• S3 REST origin: keep Block Public Access enabled, use OAC, and scope the bucket policy to the intended CloudFront distribution.
• S3 website endpoint: treat it as a custom origin; OAC does not apply to S3 website endpoints.
• ALB origin: prefer a private origin when the design supports it, or restrict an internet-facing ALB to intended CloudFront traffic with appropriate network and listener controls.
• Application: keep authentication, authorization, input validation, secure session handling, and least-privilege IAM. WAF is defense in depth, not application security by itself.

Log decisions

Enable WAF logging and useful CloudFront and origin observability. During an incident, operators should be able to distinguish:

• a WAF block from an application error
• a cache hit from a cache miss
• an origin timeout from an edge response
• malicious traffic from a false positive

7. Resilience Controls

CloudFront improves resilience mainly by reducing how much work reaches the origin.

If ten thousand users request the same cacheable image and CloudFront can reuse it, the origin does not need to perform ten thousand equivalent reads. Cached content may also remain available during some origin problems, depending on cache freshness and error behavior.

But CloudFront does not make an unhealthy origin highly available. Dynamic requests and cache misses still depend on the origin. An ALB still needs healthy targets across Availability Zones, and the application still needs scaling, timeouts, and failure handling.

Shield Standard supplies automatic baseline DDoS protection. Shield Advanced becomes relevant when the requirement explicitly calls for enhanced DDoS visibility, response support, or eligible cost protection—not merely because the application is public.

WAF can protect resilience by removing abusive HTTP traffic before it consumes application capacity. WAF can also harm resilience through false positives, which is why count mode, logs, and staged rollout matter.

Origin Shield and CloudFront origin groups are useful advanced options, but they are not required to understand this architecture. Learn them in the dedicated Amazon CloudFront reference when a scenario specifically needs another caching tier or origin failover.

8. Performance Controls

CloudFront performance starts with one question:

Can this response be safely reused for another request?

A cache key is the lookup identity CloudFront uses to decide whether two requests can share a cached response. It can include the path and selected query strings, headers, or cookies.

The tradeoff is straightforward:

• Include too little, and different users or request variants may receive the wrong response.
• Include too much, and nearly every request becomes a unique cache entry, reducing the cache-hit ratio.

For a beginner, the safe rule is to start with clearly public static assets. Do not cache authenticated HTML or API responses until the application team can explain exactly why sharing that response is correct.

Compression, sensible cache durations, versioned asset names, and selective invalidations can improve delivery further. Those are CloudFront tuning details, not new layers in the architecture.

9. Cost Controls

The edge adds cost, but it can also prevent more expensive work.

The useful cost question is not simply, "Does CloudFront cost money?"

Ask:

which work is the edge preventing the origin from doing?

Good caching can reduce ALB, compute, and origin data-transfer pressure. Poor caching can add an edge bill while still sending nearly every request to the backend.

10. Exam Variants

SAA-C03 questions usually describe a requirement and expect you to recognize the matching boundary.

Read the whole requirement

Suppose an exam question says:

A company serves static assets from S3 to global users. The bucket must not be public, and users must access objects only through the CDN.

The answer is not only CloudFront. The complete requirement points to:

CloudFront + private S3 origin + OAC + bucket policy

Now suppose the question adds:

The company must block common malicious HTTP requests before they reach the origin.

That additional requirement adds AWS WAF. One sentence in an exam question often represents one missing architectural capability.

11. Common Traps

Final Mental Model: One-Minute Review

Final Architecture Map

The associated controls are intentionally drawn beside CloudFront rather than as extra proxy hops. Cache misses continue to a protected origin; direct origin bypass is closed.

flowchart LR
  User["User"] -->|"HTTPS request"| Edge["CloudFront edge<br/>delivery, cache, and routing"]
  Shield["AWS Shield<br/>DDoS protection"] -.->|"Protects the edge and resource"| Edge
  WAF["AWS WAF web ACL<br/>HTTP request rules"] -.->|"Evaluates requests at the edge"| Edge
  Edge -->|"Cache hit"| Response["Return cached response"]
  Edge -->|"Cache miss"| Origin["Protected origin"]
  OAC["OAC<br/>private S3 origins only"] -.->|"Signs the origin request"| Origin

WAF, Shield, and OAC are protections associated with the path; they are not three extra proxy servers. CloudFront handles global delivery, WAF applies web-request rules, Shield mitigates DDoS attacks, and origin controls stop users from walking around the edge.

12. Related Topics

Use Amazon CloudFront when you want deeper coverage of distributions, cache behaviors, cache keys, origins, TTLs, and OAC.

Use AWS WAF for web ACLs, managed rule groups, rate-based rules, rule actions, logging, and tuning.

Use AWS Shield for the differences between Shield Standard and Shield Advanced.

Review Amazon S3 for bucket policies and private object storage, and AWS Network Firewall when a scenario requires routed VPC traffic inspection rather than HTTP request filtering.

Official AWS references:

• How CloudFront delivers content
• Use AWS WAF protections with CloudFront
• Restrict access to an Amazon S3 origin
• Restrict access to Application Load Balancers
• AWS Shield Standard overview