Caching And Content Delivery Optimization — AWS Developer (DVA-C02)
CloudFront at the Edge vs ElastiCache at the Origin
CloudFront sits between globally distributed users and your origin, caching HTTP responses at edge locations close to the requester. ElastiCache sits between your application tier and the database, caching query results to reduce round trips to RDS or DynamoDB. Candidates see a latency problem and select ElastiCache without identifying where the latency originates. If the bottleneck is distance to the origin server, CloudFront is correct. If the bottleneck is repeated identical database reads from a single region, ElastiCache addresses it. Cache-Control headers and CloudFront TTL settings control how long responses stay cached at edge locations before the origin is revalidated.
What This Pattern Tests
The exam describes a performance requirement and tests caching layer selection. CloudFront (CDN) caches static content and API responses at edge locations — reduces origin load and latency for geographically distributed users. ElastiCache Redis caches application data (session state, leaderboards, query results) with sub-millisecond reads. DAX sits in front of DynamoDB as a transparent read-through/write-through cache. The trap is using CloudFront to cache highly dynamic, personalized content (low cache hit ratio) or ElastiCache for content that changes every second (cache invalidation overhead exceeds cache benefit).
Decision Axis
Content type and access pattern determine caching layer: static content = CDN, repeated queries = application cache, DynamoDB hot keys = DAX.
Associated Traps
More Top Traps on This Exam
Decision Rules
Whether origin-data-store compatibility and the minimal-code-change constraint together mandate DAX over ElastiCache, because DAX is API-transparent to DynamoDB while ElastiCache requires explicit cache-aside logic wired by the application.
Domain Coverage
Difficulty Breakdown