A DynamoDB table receives very heavy reads with repeated access to the same keys. To achieve microsecond-level low-latency reads, which service is the most appropriate?

Explanation

DynamoDB Accelerator is an in-memory cache for DynamoDB that reduces read latency.

Per-choice explanations

Practical Use

DynamoDB Accelerator (DAX) is a fully managed in-memory cache cluster purpose-built for DynamoDB, reducing DynamoDB read latency from milliseconds to microseconds. The application uses the DAX client SDK to call the existing DynamoDB APIs (GetItem, Query, Scan, and so on) without significant code changes. Workloads with frequent repeated reads on the same keys (hot keys), or with extremely strict latency requirements such as game leaderboards, ad serving, and real-time bidding (RTB), benefit most. An alternative is to place ElastiCache for Redis or Memcached in front of DynamoDB, but then consistency management with the cache (invalidation on writes and TTL design) must be handled by the application. DAX is optimized specifically for DynamoDB and synchronizes the cache and DynamoDB with write-through, reducing consistency code on the application side. On the other hand, DAX cluster node costs are always incurred, so workloads without hot read patterns or with low cache hit rates may not justify the cost. On SAA-C03, when keywords such as "microsecond-level reads against DynamoDB," "repeated access to the same keys," or "further reduce latency" appear, DAX is the correct answer. Distractors include "use ElastiCache" (a general-purpose cache without DynamoDB-specific optimization), "add a Global Secondary Index (GSI)" (for expanding query patterns, not for reducing latency), and "increase provisioned capacity" (throughput scaling that does not directly reduce latency).