CLD120 • AWS Academy Cloud Architecting

Module 11

Caching Content

Why cache · Amazon CloudFront · Amazon ElastiCache · DynamoDB Accelerator · Choosing a strategy

Mesa Community College

Module Objective

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

Modules 3–8All layers✓ built
Module 9Elasticity & HA✓ done
Module 10Automation✓ done
Module 11Cachingyou are here
Module 12Decoupling
Module 13Serverless
Module 14Disaster recovery
Builds on Modules 3–9: caching sits in front of the storage, compute, and database layers. Revisits CloudFront (Cloud Foundations Module 5) and ElastiCache (Cloud Foundations Module 8).

Why Cache?

Keep a copy of frequently requested data somewhere faster or closer to the requester.

For end users

Lower latency
responses arrive faster

For the origin

Less load
S3, the database, or application servers do less work
Fresher data
Faster responses
Every caching decision trades some freshness for speed. Decide how stale a piece of data can be before the cache stops being useful.

Amazon CloudFront Caching Revisited

Café customers
→
CloudFront distribution
→
/images/* → S3 storage layer
cached for long periods
/api/* → compute layer
not cached
Content TypeCloudFront Behavior
Static assets (images, CSS, JS)Cached for long periods, because these change infrequently
Dynamic API responsesCached briefly or not at all, depending on how often the underlying data changes
Cache behaviors can vary by path: one distribution can apply different caching rules to different URL paths.

Amazon ElastiCache Revisited

Compute layer
EC2 application tier
→
ElastiCache
in-memory
→
RDS database layer
serves only cache misses

The cache-aside pattern

  1. The application checks the cache first
  2. On a miss, it queries the database
  3. It writes the result to the cache for next time
Cache-aside is the common pattern for using ElastiCache in front of a database.

DynamoDB Accelerator (DAX)

Application
→
DAX
in-memory cache
→
Amazon DynamoDB
DynamoDB alone
milliseconds
With DAX
microseconds
Application cache logic
not needed

DAX

Works only with DynamoDB · API-compatible · minimal code changes

ElastiCache

General-purpose · application usually manages cache reads and writes explicitly

Choosing a Caching Strategy

Content type, read/write ratio, and acceptable staleness 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)
Caching isn’t free of trade-offs. Every cache can hold stale data, and every cache layer is another component to monitor and secure. Add caching deliberately, to fix an observed bottleneck — not by default everywhere.

Key Terms

Cache-aside pattern
The application checks the cache first and falls back to the database on a miss
Cache behavior
A CloudFront rule that controls how a specific URL path is cached
DynamoDB Accelerator (DAX)
An in-memory cache built to sit in front of DynamoDB
Data staleness
The risk that cached data no longer matches the current state of its source

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?