AWS Certified Solutions Architect - Associate (SAA-C03) #10 Domain 3-2 High-Performing Architectures — Caching
Following #9 Choosing Compute, we cover the second topic in the high-performing domain: caching. Caching follows the principle of “don’t fetch the same data over and over at high cost; store it nearby and pull it quickly.” In SAA, services diverge based on where you cache (in-memory next to the application vs. at the edge close to the user).
ElastiCache — in-memory data cache #
ElastiCache is a managed in-memory cache. Placed in front of a database, it absorbs the load of repeated lookups and pushes responses down to microseconds–milliseconds. There are two engines, and the difference shows up often on the exam.
| Item | Redis | Memcached |
|---|---|---|
| Persistence | Supported | None |
| Replication , Multi-AZ | Supported (high availability) | None |
| Data structures | Rich (list, set, sorted set, pub/sub) | Simple key-value |
| Multithreaded | No | Yes |
| Backup/snapshot | Supported | None |
- Redis — if you need persistence, replication, Multi-AZ, backups, and rich data structures, it’s Redis. Suitable for advanced features like session storage, leaderboards, and pub/sub.
- Memcached — suitable when you need a simple key-value cache, want to scale out horizontally (sharding) with multithreading, and don’t need persistence or replication.
A “cache that needs high availability/persistence/replication” answers as Redis, and a “simple , multithreaded cache” answers as Memcached.
Cache strategies #
- Lazy Loading — on a miss, read from the DB and populate the cache. Only data that’s actually requested gets cached, but the first request is slow and stale data can linger.
- Write-Through — update the cache whenever you write data. The cache is always current, but data that will never be read may also get cached.
- TTL — set an expiration on cache entries to automatically remove stale data.
DAX — DynamoDB-only acceleration #
DynamoDB Accelerator (DAX) is an in-memory cache placed in front of DynamoDB that lowers read responses from milliseconds to microseconds. The key point is that DAX is DynamoDB-only. It can’t be used as a cache for RDS or other DBs. If the clue is “DynamoDB reads in microseconds,” it’s DAX.
CloudFront — edge content cache (CDN) #
CloudFront is a CDN that caches content at edge locations worldwide so responses come from somewhere physically close to the user. If ElastiCache is the cache next to the application, CloudFront is the cache close to the user.
- Origin — set S3, an ALB, or an external server as the source.
- Effect — reduced latency + lighter origin load. It accelerates dynamic content as well as static content.
- OAC (Origin Access Control) — lock an S3 origin so it’s reachable only through CloudFront, preventing direct bucket exposure.
- Signed URLs/cookies — allow content access to specific users only.
- Edge logic — transform requests at the edge with CloudFront Functions / Lambda@Edge.
If the requirement is “deliver content to users worldwide with reduced latency,” “lighten the origin load,” or “distribute without exposing S3 directly,” it’s CloudFront.
CloudFront vs. Global Accelerator #
Both speed up the user experience, but in different ways.
| Service | Method | Suitable for |
|---|---|---|
| CloudFront | Caches content at the edge | Distributing static/dynamic web content |
| Global Accelerator | Routes over the AWS backbone without caching | Non-HTTP (TCP/UDP), static IPs, fast failover |
If caching is the core, CloudFront; if you need “not caching but global network path optimization , static anycast IPs,” Global Accelerator.
Storing sessions externally for statelessness #
In #6 Auto Scaling, instances scale up and down constantly. If you keep a session in an instance’s memory, the session disappears when that instance goes away. So you move the session out to an external store like ElastiCache (Redis) to make the application tier stateless. That way, whichever instance receives a request reads the same session.
Exam question patterns #
- “Deliver content close to users worldwide, reduce latency.” → CloudFront
- “Reduce DB read load, in-memory cache.” → ElastiCache
- “Cache with persistence/replication/Multi-AZ.” → Redis
- “Simple , multithreaded cache, no persistence needed.” → Memcached
- “DynamoDB reads in microseconds.” → DAX
- “Store session state externally to be stateless.” → ElastiCache (Redis)
- “CDN distribution without exposing S3 directly.” → CloudFront + OAC
Common traps #
1) Thinking Memcached has persistence and replication #
Persistence, replication, Multi-AZ, and backups are Redis. Memcached is a simple cache.
2) Confusing CloudFront with ElastiCache #
CloudFront is an edge CDN close to the user; ElastiCache is an in-memory cache next to the application. They solve different problems.
3) Using DAX as an RDS cache #
DAX is DynamoDB-only. The cache for a relational DB is ElastiCache.
4) Trying to accelerate non-HTTP traffic with CloudFront #
CloudFront caches web content. Path optimization for general TCP/UDP traffic is Global Accelerator.
Wrap-up #
What this post locked in:
- ElastiCache — in-memory cache. Redis (persistence , replication , Multi-AZ) vs. Memcached (simple , multithreaded)
- DAX — DynamoDB-only microsecond cache
- CloudFront — edge CDN. Reduced latency + lighter origin load. Protect S3 with OAC
- CloudFront vs. Global Accelerator — caching vs. network path optimization
- Make the application stateless by storing the session externally in ElastiCache
Next — Domain 3-3 Choosing Storage #
Now that we’ve nailed caching, next is where to put data and which storage to use.
In #11 Domain 3-3 Choosing Storage we’ll cover the distinction between block (EBS) , file (EFS , FSx) , object (S3), EBS volume types, the use cases for EFS and FSx (Windows , Lustre), and S3 storage classes (Standard , Intelligent-Tiering , IA , Glacier) along with lifecycle policies.