Module Objective: Apply caching at multiple layers of an architecture to reduce latency and offload backend resources.

Builds on Modules 3–9: Caching sits in front of the storage, compute, and database layers already designed, reducing the load each one has to handle directly.

Why Cache?

Caching stores a copy of frequently requested data somewhere faster or closer to the requester, reducing latency for the end user and reducing load on the origin — whether that origin is S3, a database, or an application server.

🔵 Note Every caching decision trades some data freshness for speed — cached data can become stale, so part of designing a cache is deciding how long that's acceptable for a given piece of data.

Amazon CloudFront Caching Revisited

Building on AWS Academy Cloud Foundations Module 5, this module treats CloudFront as an architectural caching layer in front of both the S3 storage layer (Module 3) and the compute layer's dynamic content (Module 4) — reducing origin load for both.

Content TypeCloudFront Behavior
Static assets (images, CSS, JS)Cached for long periods, since they change infrequently
Dynamic API responsesCached briefly or not at all, depending on how often the data changes
✅ Tip — Cache Behaviors Can Vary by Path A single CloudFront distribution can apply different caching rules to different URL paths — long cache times for /images/* and no caching for /api/*, for example.

Amazon ElastiCache Revisited

Building on AWS Academy Cloud Foundations Module 8, ElastiCache is applied here as an in-memory cache sitting between the compute layer and the RDS database layer, absorbing repeated read queries so the database doesn't have to serve every one directly.

🔵 Note — Cache-Aside Is the Common Pattern In the most common caching pattern, the application checks the cache first; on a miss, it queries the database and writes the result back into the cache for next time.

DynamoDB Accelerator (DAX)

For architectures using DynamoDB, Amazon DynamoDB Accelerator (DAX) is a purpose-built, in-memory cache that sits directly in front of DynamoDB, reducing response times from milliseconds to microseconds for read-heavy workloads without application-level cache logic.

✅ Tip — DAX vs. ElastiCache DAX is specific to DynamoDB and requires minimal code changes since it's API-compatible with DynamoDB. ElastiCache is general-purpose and typically requires the application to explicitly manage cache reads and writes.

Choosing a Caching Strategy

As with every other layer in this course, the right caching approach depends on the specific workload — content type, read/write ratio, and acceptable staleness all drive the decision.

NeedLikely Fit
Cache static web content globallyAmazon CloudFront
Reduce read load on a relational databaseAmazon ElastiCache
Reduce read latency on DynamoDB specificallyAmazon DynamoDB Accelerator (DAX)
⚠️ Warning — Caching Isn't Free of Trade-offs Every cache is a place data can go stale, and every cache layer is one more component to monitor and secure — caching should be added deliberately to solve an observed bottleneck, not by default everywhere.

Key Terms for Module 11

cache-aside pattern
A caching pattern where the application checks the cache first, then falls back to the database on a miss
cache behavior
A CloudFront rule controlling how a specific URL path is cached
Amazon DynamoDB Accelerator (DAX)
An in-memory cache purpose-built to sit in front of DynamoDB
data staleness
The risk that cached data no longer reflects the current state of the source it was copied from

Review Questions

  1. What two problems does caching solve at once for both the end user and the origin resource?
  2. How can a single CloudFront distribution apply different caching rules to static assets versus API responses?
  3. What is the difference between Amazon ElastiCache and DynamoDB Accelerator (DAX)?
  4. Why shouldn't caching be added to every layer of an architecture by default?