AWS Builder Center

Builder Center

Building Faster and More Secure Web Applications with Amazon CloudFront and AWS WAF

Modern web applications need to do more than simply deliver features. They also need to load quickly, handle traffic efficiently, and protect themselves from common web attacks. A user accessing an application from India, for example, should not necessarily have to retrieve every resource from a server located on another continent. Similarly, an application should not expose every request directly to its backend without considering how those requests can be filtered and protected.

Amazon CloudFront is a content delivery network (CDN) that helps deliver application content closer to users, while AWS WAF (Web Application Firewall) helps inspect and control HTTP and HTTPS requests before they reach protected application resources.
Together, they can form an important part of a modern web application's delivery and security architecture.
This article explains how CloudFront and AWS WAF work, where they fit into an application architecture, and how full-stack developers can use them effectively.

What Is a CDN?

A Content Delivery Network, or CDN, distributes content through a network of locations closer to end users.
Without a CDN, a simplified architecture might look like:
1
2
3
4
5
User
↓
Application Server
↓
Content
Every user requests content directly from the origin.
With a CDN:
1
2
3
4
5
User
↓
Nearest Edge Location
↓
Origin Server
If the requested content is already cached at the edge, the CDN can serve it without contacting the origin.
This can reduce latency and decrease the number of requests reaching the origin infrastructure.

What Is Amazon CloudFront?

Amazon CloudFront is AWS's content delivery network.
It can distribute:
  • HTML
  • CSS
  • JavaScript
  • Images
  • Videos
  • API responses
  • Other web content
CloudFront can work with different origins, including services such as:
  • Amazon S3
  • Application Load Balancer
  • EC2-based applications
  • API Gateway
  • Other HTTP-compatible origins
A simplified architecture is:
1
2
3
4
5
6
7
8
9
┌───────────────┐
│ Users │
└───────┬───────┘
↓
┌───────────────┐
│ CloudFront │
└───────┬───────┘
↓
Origin
The origin remains responsible for generating or storing the content, while CloudFront handles distribution.

Understanding Edge Locations

CloudFront uses a globally distributed network of edge locations.
When a user requests content, CloudFront can route the request through an appropriate edge location.
For example:
1
2
3
4
5
User in India
↓
CloudFront Edge
↓
Origin
After content is cached, subsequent requests may be served directly from the edge.
This is particularly useful for static assets such as:
1
2
3
4
app.js
styles.css
logo.png
product-image.jpg

How Caching Works

Caching is one of the most important concepts when working with CloudFront.
Suppose a user requests:
1
https://example.com/logo.png
If the object is not already cached:
1
2
3
4
5
6
7
User
↓
CloudFront
↓
Origin
↓
logo.png
CloudFront retrieves the object from the origin.
The object can then be cached according to the configured caching behavior.
A later request can look like:
1
2
3
4
5
User
↓
CloudFront
↓
Cached logo.png
The origin does not need to handle every request.

Cache Hit and Cache Miss

A cache hit occurs when CloudFront can serve the requested content from its cache.
1
2
3
4
5
6
7
Request
↓
CloudFront
↓
Object exists in cache?
↓
Yes → Return cached object
A cache miss occurs when the requested object is not available in the cache.
1
2
3
4
5
6
7
8
9
Request
↓
CloudFront
↓
Object exists?
↓
No
↓
Request Origin
Increasing useful cache hits can reduce origin traffic and improve response performance.

Cache-Control Headers

Developers can influence browser and CDN caching behavior using HTTP headers.
For example:
1
Cache-Control: public, max-age=3600
This tells compatible caching systems that the response can be cached according to the specified policy.
For static assets with versioned filenames, longer cache lifetimes can often be useful.
For example:
1
2
app.8f31c.js
styles.71ac2.css
When the application changes, a new filename can be generated.
This approach helps avoid users receiving outdated assets.

CloudFront for React Applications

CloudFront is particularly useful for frontend applications.
A possible architecture is:
1
2
3
4
5
6
7
8
9
React Application
↓
Build
↓
Amazon S3
↓
CloudFront
↓
Users
The React build files can be stored in S3 while CloudFront distributes them globally.
For example:
1
2
3
4
5
index.html
assets/
app.js
styles.css
logo.png
CloudFront can serve these resources closer to users.

CloudFront with an API

CloudFront is not limited to static websites.
It can also sit in front of APIs.
For example:
1
2
3
4
5
6
7
8
9
React
↓
CloudFront
↓
API
↓
Backend
↓
Database
This can provide a single entry point for different types of application traffic.
However, API caching must be designed carefully.
Not every API response should be cached.
For example, a public product catalog may be suitable for caching, while a private banking balance generally requires different handling.

Introducing AWS WAF

CloudFront helps with content delivery, but applications also need protection from malicious web traffic.
This is where AWS WAF can be useful.
AWS WAF is a web application firewall that allows developers to create rules for inspecting HTTP and HTTPS requests.
A simplified flow is:
1
2
3
4
5
6
7
8
9
10
11
User Request
↓
AWS WAF
↓
Allowed?
┌───┴────┐
Yes No
↓ ↓
CloudFront Block
↓
Origin
Rules can help control which requests are allowed to reach the application.

Why Use a Web Application Firewall?

Applications can receive unwanted traffic such as:
  • Suspicious requests
  • Automated traffic
  • Malicious patterns
  • Injection attempts
  • Requests from unwanted sources
  • Excessive request rates
A WAF can inspect requests before they reach the application infrastructure.
This adds another security layer between users and the origin.

AWS Managed Rules

AWS WAF supports managed rule groups that can help protect applications against common attack patterns.
Developers can use managed rules rather than creating every security rule from scratch.
However, managed rules should still be evaluated and tested against the application's legitimate traffic.
A security rule that blocks too broadly can accidentally block real users.

Rate-Based Rules

Applications may also need to control excessive request rates.
A rate-based rule can help detect clients sending unusually large numbers of requests within a defined period.
Conceptually:
1
2
3
4
5
6
7
8
9
Client
↓
Many Requests
↓
AWS WAF
↓
Rate Threshold
↓
Action
This can be useful for APIs, login endpoints, and other resources that may be targeted by automated traffic.
Rate-based protection should be designed according to the application's normal traffic patterns.

IP-Based Rules

AWS WAF can also use IP-based conditions.
For example, an application may need to:
1
2
3
Allow specific IP ranges
Block specific IP addresses
Restrict administrative traffic
However, IP addresses can change and shared networks can contain many legitimate users, so IP-based controls should be used carefully.

Combining CloudFront and AWS WAF

The two services become particularly useful when used together.
A typical architecture might look like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Internet
│
↓
┌──────────────┐
│ AWS WAF │
└──────┬───────┘
↓
┌──────────────┐
│ CloudFront │
└──────┬───────┘
↓
┌────────┴────────┐
↓ ↓
S3 Origin API Origin
↓
Application
↓
Database
WAF evaluates requests while CloudFront handles distribution and caching.

Protecting the Origin

Using CloudFront does not automatically mean that the origin should be publicly accessible without restrictions.
For example, if an application uses:
1
CloudFront → Application Load Balancer
developers should consider how direct access to the origin is handled.
The objective is to ensure that application traffic follows the intended architecture and security controls.
This is particularly important when the origin contains application logic or sensitive resources.

HTTPS and TLS

Modern applications should use encrypted communication.
A typical flow is:
1
2
3
4
5
Browser
↓ HTTPS
CloudFront
↓ HTTPS
Origin
HTTPS protects data while it travels between the client and the application infrastructure.
CloudFront can work with TLS certificates managed through AWS Certificate Manager.
Developers should configure certificates and HTTPS behavior appropriately for the application's domain.

CloudFront and API Security

Suppose an application has:
1
2
3
POST /api/login
POST /api/orders
GET /api/products
Not all endpoints have the same requirements.
For example:
1
/api/products
might contain public information.
Meanwhile:
1
/api/orders
could contain authenticated user data.
Therefore, developers should design caching and WAF rules based on endpoint behavior.
A CDN should never be treated as a replacement for authentication and authorization.

CloudFront Is Not Authentication

One common misconception is that putting an application behind CloudFront makes it secure.
It does not.
CloudFront provides content delivery capabilities, and WAF provides request filtering capabilities.
Application-level security still requires mechanisms such as:
1
2
3
4
5
6
Authentication
Authorization
Input Validation
Secure Sessions/Tokens
Access Control
Data Protection
Security should be implemented in multiple layers.

Cache Invalidation

Sometimes cached content needs to be updated immediately.
For example:
1
2
3
4
5
Old:
app.js

New:
app.js
If the old version is cached, users might continue receiving it.
CloudFront provides cache invalidation capabilities that can remove cached objects before their normal expiration.
However, frequent invalidations should not become a substitute for good caching and asset-versioning strategies.

Monitoring and Logging

Performance and security controls need monitoring.
Developers should pay attention to:
  • Cache hit behavior
  • Origin request volume
  • HTTP response status codes
  • WAF blocked requests
  • WAF allowed requests
  • Unusual request patterns
  • API errors
  • Latency
  • Traffic spikes
Logs and metrics can help answer questions such as:
1
2
3
4
Why did traffic increase?
Why did origin requests increase?
Which requests are being blocked?
Why did API latency increase?
Observability is therefore an important part of the architecture.

Example: Full-Stack AWS Architecture

A modern full-stack application could use:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Users
↓
┌─────────────┐
│ AWS WAF │
└──────┬──────┘
↓
┌─────────────┐
│ CloudFront │
└──────┬──────┘
↓
┌────────┴─────────┐
↓ ↓
Amazon S3 API Gateway
React App ↓
Lambda / API
↓
Database
This architecture separates different responsibilities:
  • CloudFront → Content delivery
  • WAF → Web request filtering
  • S3 → Static frontend assets
  • API Gateway → API entry point
  • Lambda → Backend processing
  • Database → Persistent application data
Individual components can then be developed and scaled according to their specific requirements.

Common Mistakes

1. Caching Everything

Private or frequently changing data may not be appropriate for caching.

2. Treating WAF as Complete Security

WAF is one layer of defense, not a replacement for authentication or secure application code.

3. Ignoring Cache Invalidation

Incorrect caching strategies can cause users to receive outdated content.

4. Exposing the Origin Unnecessarily

Applications should consider how direct origin access is controlled.

5. Creating Overly Broad WAF Rules

Aggressive rules can block legitimate users.

6. Not Monitoring Blocked Requests

Security rules should be monitored to understand whether they are working as intended.

7. Ignoring HTTPS

Modern applications should protect communication with TLS.

When Should You Use CloudFront and WAF?

CloudFront can be useful when an application needs:
  • Global content delivery
  • Lower latency for distributed users
  • Static asset caching
  • Reduced origin traffic
  • CDN-based application delivery
AWS WAF can be useful when an application needs:
  • Request filtering
  • Protection against common web attack patterns
  • Rate-based controls
  • IP-based rules
  • Additional security controls at the application edge
They can be used independently or together depending on the application's architecture.

Conclusion

Performance and security are closely connected in modern web applications.
Amazon CloudFront helps applications deliver content efficiently through a global content delivery network, while AWS WAF provides controls for inspecting and filtering web requests.
When combined with services such as Amazon S3, API Gateway, Lambda, and databases, they can form an important part of a modern AWS application architecture.
The key concepts developers should understand are:
  • CDN and edge delivery
  • Caching
  • Cache hits and misses
  • Cache-control policies
  • Origin protection
  • AWS WAF rules
  • Rate-based controls
  • HTTPS and TLS
  • API caching considerations
  • Monitoring and logging
  • Defense-in-depth security
The goal is not simply to add more AWS services to an application. The goal is to use each service where it solves a specific problem.
A well-designed architecture should deliver content efficiently, protect application resources, and remain understandable and maintainable as the application grows.
# aws-academy# aws-ai-chips# aws-ambassador# aws-ai-league# aws-amplify
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article