The Solutions Architect Professional exam does not test whether you can name AWS’s caching services. It tests whether, given a latency complaint buried in a three-paragraph scenario, you can point to the one layer where a cache belongs and pick the right service for it. “Design for performance” runs through Domain 2 (Design for New Solutions), and caching is where the most points hide because the wrong-answer distractors are always plausible-sounding caches at the wrong layer.
This guide is a decision framework, not a feature tour. It walks the request path from the browser to the database, names the caching service that belongs at each hop, and — most importantly — gives you the scenario signals that tell CloudFront from Global Accelerator, Redis from Memcached, and DAX from ElastiCache. If you’re assembling your full prep, anchor it with the AWS Solutions Architect Professional guide for 2026 and the SAP-C02 study plan.
The Layered Caching Model
Every SAP-C02 performance question is really asking “where is the latency, and what’s the cheapest place to remove it?” Answer by walking the request from the user inward. Each layer has one or two AWS services that live there, and putting a cache at the correct layer is usually the whole answer.
| Layer | Where it sits | AWS service | Removes latency from |
|---|---|---|---|
| Edge / CDN | AWS edge locations, close to users | CloudFront | Repeated fetches of static & cacheable content |
| Network path | AWS global backbone | Global Accelerator | Long, jittery internet paths to your app |
| Application / session | In front of your app or DB | ElastiCache (Redis/Memcached) | Expensive repeated DB queries, sessions |
| DynamoDB read path | In front of DynamoDB | DAX | Hot-key, read-heavy DynamoDB access |
| API responses | API Gateway stage | API Gateway caching | Repeated identical API calls |
| Upload path | Edge → S3 | S3 Transfer Acceleration | Slow long-distance uploads to S3 |
Memorise the layers, and half the exam’s caching questions answer themselves. The rest come down to two classic head-to-head choices — CloudFront vs. Global Accelerator and Redis vs. Memcached — plus knowing exactly when DAX beats a general-purpose cache.
CloudFront: Caching at the Edge
CloudFront is AWS’s content delivery network. It caches copies of your content at hundreds of edge locations worldwide, so a user in Singapore fetching an object hits a nearby edge cache instead of an origin in us-east-1. On a cache hit, the origin is never touched — that’s the double win the exam cares about: lower latency for users and less load (and cost) on your origin.
Key concepts the exam probes:
- Origins. CloudFront pulls from an origin: an S3 bucket, an Application Load Balancer, an API Gateway, or any custom HTTP server. One distribution can have multiple origins.
- Cache behaviors. Path patterns (
/images/*,/api/*) route different paths to different origins with different caching rules. A common design: cache/static/*aggressively at the edge, but set/api/*to forward to an ALB with caching effectively disabled. - TTLs and cache policies. Minimum, default, and maximum TTLs — plus the cache key (which headers, cookies, and query strings are part of the key) — decide how long and how granularly objects are cached. A cache key that includes too many headers destroys your hit ratio.
- Invalidation vs. versioned filenames. You can invalidate paths to purge the cache, but invalidations are slow and cost money beyond the free monthly allowance. The architect’s answer is almost always versioned object names (
app.v2.js) so a new deploy simply references new keys — no invalidation needed. - Securing the origin. Use Origin Access Control (OAC) so an S3 bucket only serves requests that come through CloudFront, never directly. For private content, use signed URLs or signed cookies.
- Edge compute. CloudFront Functions (lightweight, viewer request/response, header rewrites, redirects) and Lambda@Edge (heavier, all four trigger points, can call other services) let you run logic at the edge.
The scenario signal for CloudFront: “global users,” “static content,” “reduce load on the origin,” “cache at the edge,” or “reduce latency for downloads.” If it’s HTTP(S) content that can be cached, CloudFront is almost certainly in the answer.
S3 Transfer Acceleration — the upload cousin
Related but distinct: S3 Transfer Acceleration uses CloudFront edge locations to speed up uploads to S3 over long distances by routing them onto the AWS backbone at the nearest edge. Signal: “users worldwide uploading large files to a central S3 bucket, slowly.” Don’t confuse it with CloudFront’s download caching — Transfer Acceleration doesn’t cache anything, it optimizes the network path for PUTs.
Global Accelerator: Optimizing the Network Path (No Caching)
This is the single most-tested distinction in this topic, so get it crystal clear: Global Accelerator does not cache anything. It provides two static anycast IP addresses and routes user traffic onto the AWS global backbone at the nearest edge, then across AWS’s private network to your application — cutting out the slow, unpredictable public internet. It also gives near-instant regional failover and works for any TCP/UDP traffic, not just HTTP.
| Dimension | CloudFront | Global Accelerator |
|---|---|---|
| Primary job | Cache & deliver content | Optimize network path & routing |
| Caches content? | Yes | No |
| Protocols | HTTP/HTTPS | Any TCP/UDP (gaming, VoIP, IoT, MQTT) |
| IP addresses | Distribution domain name | 2 static anycast IPs |
| Best for | Static/dynamic web content, media | Non-HTTP apps, low-latency, fast failover |
| Failover | Origin failover within a distribution | Fast multi-Region failover |
The exam’s favourite trap pairs them: “a global multiplayer game needs the lowest possible latency and fast failover between Regions over UDP.” CloudFront can’t cache a live game session and doesn’t do UDP → Global Accelerator. Conversely, “a media site serving cached video segments to global users” → CloudFront. When you see static IP requirements, non-HTTP protocols, or “route over the AWS backbone,” think Global Accelerator. When you see cacheable content and origin offload, think CloudFront. For how these fit the wider connectivity picture, see the SAP-C02 networking deep dive.
ElastiCache: Application & Database Caching
Move inward from the edge to the application tier. ElastiCache is an in-memory data store (Redis or Memcached) you place in front of a database or between microservices to serve hot data in sub-millisecond time instead of re-running an expensive query. The classic use case: a read-heavy relational database where the same rows are fetched over and over.
Redis vs. Memcached
The exam expects you to choose the right engine from the workload description:
| Need | Engine |
|---|---|
| Persistence, backup/restore, replication | Redis |
| Multi-AZ with automatic failover / HA | Redis |
| Advanced data types (sorted sets, lists, geospatial), pub/sub | Redis |
| Leaderboards, rate limiting, session store, message queues | Redis |
| Dead-simple key/value cache, multi-threaded, scale by adding nodes | Memcached |
| Ability to shard across cores/nodes for a large flat cache | Memcached |
Rule of thumb: if the scenario needs any durability, replication, high availability, or richer data structures, it’s Redis. If it’s purely a simple, horizontally scalable object cache with no persistence needs, Memcached is the lighter choice. In practice modern SAP-C02 scenarios lean Redis, because “must survive a node failure” or “store sessions” appears constantly.
Caching strategies you must recognise
- Lazy loading (cache-aside). The app checks the cache; on a miss it reads the DB and populates the cache. Simple, only caches requested data, but the first request is always a miss and stale data can linger until it expires.
- Write-through. The app writes to the cache and DB together on every write, so the cache is always fresh — at the cost of write latency and caching data that may never be read.
- TTL. Expiry times bound staleness and are almost always combined with lazy loading to keep the cache from serving old data forever.
A frequent exam pairing is lazy loading plus a TTL — it caps both cache-miss cost and staleness. If a question complains about stale data in the cache, the fix is usually a shorter TTL or a write-through pattern. ElastiCache is also the standard answer for externalising HTTP session state so you can run a stateless, horizontally scalable web tier behind an ALB.
DAX: The DynamoDB-Specific Cache
Here’s the distinction that separates a 70% from a pass: when the database is DynamoDB, the right cache is usually not ElastiCache — it’s DynamoDB Accelerator (DAX). DAX is a fully managed, write-through, in-memory cache built specifically for DynamoDB that delivers microsecond read latency (versus DynamoDB’s single-digit milliseconds) and requires almost no application changes — it’s API-compatible with DynamoDB, so you point the SDK at the DAX cluster.
What the exam wants you to know about DAX:
- It accelerates eventually consistent reads (
GetItem,BatchGetItem,Query,Scan). Strongly consistent reads pass straight through to DynamoDB and are not served from the DAX cache. - It’s write-through: writes go to DynamoDB and update the cache, keeping it fresh.
- It’s ideal for read-heavy, bursty, or hot-key workloads — think a flash sale hammering the same product items, or repeated reads of the same records.
- It only works with DynamoDB. If the datastore is RDS/Aurora or you need caching independent of the database, that’s ElastiCache, not DAX.
| Question detail | Pick |
|---|---|
| DynamoDB, read-heavy, needs microsecond reads, minimal code change | DAX |
| DynamoDB but reads must be strongly consistent | DynamoDB directly (DAX won’t help) |
| Relational DB (RDS/Aurora) query offload | ElastiCache |
| Session store / leaderboard / pub-sub | ElastiCache (Redis) |
That “strongly consistent reads bypass DAX” fact is a favourite trap — if a scenario insists on strong consistency, adding DAX does nothing for those reads. For the broader data-store selection logic this builds on, see the SAP-C02 database selection guide.
API Gateway Caching
One more layer worth a mention: API Gateway can cache endpoint responses at the stage level with a configurable TTL. For a read-heavy API whose responses don’t change per-request, enabling the cache cuts latency and offloads the backend (Lambda or an integration) without touching your code. Signal: “a REST API returns the same response repeatedly and the backend is a bottleneck.” It pairs naturally with the serverless patterns in the SAP-C02 serverless architecture patterns guide.
A Worked SAP-C02 Scenario
A global e-commerce platform serves product images and a single-page app to users worldwide (slow page loads outside the US), stores the product catalog in DynamoDB (read-heavy, the same popular items hammered during sales), and keeps user sessions in the web tier (blocking horizontal scaling). What do you add?
Walk the layers:
- Static content + global latency → CloudFront in front of S3 (SPA and images), with OAC locking the bucket and versioned filenames instead of invalidations.
- Read-heavy DynamoDB with hot keys → DAX for microsecond reads on the popular items, no app rewrite.
- Sessions blocking scale-out → ElastiCache for Redis as an external session store so the web tier becomes stateless behind the ALB.
Three caches, three different layers, zero overlap. That layered reasoning — not memorising features — is exactly what the exam rewards, and the kind of multi-constraint decomposition worth drilling. For more worked examples, see how to pass the SAP-C02 on your first attempt.
Cost and Resilience Angles
Caching questions on SAP-C02 frequently hide a cost or resilience twist:
- CloudFront cuts origin cost, not just latency — a high cache-hit ratio means fewer origin requests and less data transfer out of your origin. That ties into the SAP-C02 cost optimization strategies.
- A cache is not a database. Memcached and non-persistent configs lose data on a node failure. If the scenario needs the cached data to survive, that’s Redis with Multi-AZ — which connects to the availability thinking in disaster recovery and high availability.
- Cache invalidation and staleness are correctness concerns. TTLs, write-through, and versioned keys are the levers; picking the wrong one shows up as “users see stale prices.”
Practice the Decision, Not the Definitions
You will not be asked “what is CloudFront.” You’ll be asked to read a dense scenario, spot the latency layer, and eliminate three plausible-but-wrong caches to land on the right one. That skill only comes from doing it repeatedly against realistic, explained questions.
Sailor.sh’s SAP-C02 mock exam bundle is built around exactly these scenario-based trade-offs — including the CloudFront-vs-Global-Accelerator and DAX-vs-ElastiCache decisions covered here — with a detailed explanation of why the best answer wins and why each distractor fails. Gauge your current level first with the free SAP-C02 practice questions, then reinforce the fundamentals with the Well-Architected Framework deep dive and the database selection guide.
Frequently Asked Questions
What is the difference between CloudFront and Global Accelerator on the SAP-C02 exam?
CloudFront is a CDN that caches content at edge locations to speed up delivery of HTTP/HTTPS assets and offload the origin. Global Accelerator does not cache — it provides two static anycast IPs and routes any TCP/UDP traffic over the AWS backbone for lower latency and fast multi-Region failover. Use CloudFront for cacheable web/media content; use Global Accelerator for non-HTTP apps (gaming, VoIP, IoT), static-IP requirements, or rapid regional failover.
When should I use DAX instead of ElastiCache?
Use DAX when the datastore is DynamoDB and you need microsecond reads with minimal code change — it’s a write-through, DynamoDB-API-compatible cache. Use ElastiCache for caching in front of relational databases (RDS/Aurora), for session stores, leaderboards, rate limiting, or pub/sub. DAX only works with DynamoDB; ElastiCache is general-purpose.
Does DAX speed up strongly consistent reads?
No. DAX serves eventually consistent reads from its cache. Strongly consistent reads pass through directly to DynamoDB and are not accelerated. If a scenario requires strong consistency for certain reads, DAX provides no benefit for those specific reads — a common exam trap.
Redis or Memcached — how do I choose on the exam?
Choose Redis whenever you need persistence, replication, Multi-AZ high availability, backup/restore, or advanced data structures (sorted sets, pub/sub, geospatial) — which covers session stores, leaderboards, and rate limiting. Choose Memcached only for a simple, multi-threaded, horizontally shardable key/value cache with no durability or replication needs. Most SAP-C02 scenarios point to Redis.
Why do architects prefer versioned filenames over CloudFront invalidations?
CloudFront invalidations are relatively slow and incur cost beyond the free monthly allowance, and invalidating many paths at scale is inefficient. Referencing new, versioned object names (for example app.v2.js) means a deployment simply points at new cache keys, so users get fresh content immediately without any invalidation — the cleaner, cheaper pattern the exam favours.
Where does S3 Transfer Acceleration fit versus CloudFront?
S3 Transfer Acceleration speeds up uploads to an S3 bucket over long distances by routing them through the nearest CloudFront edge onto the AWS backbone. CloudFront caches and accelerates downloads of content. They share edge infrastructure but solve opposite directions of traffic — use Transfer Acceleration when the problem is slow long-distance PUTs to a central bucket.