A financial services company imported millions of historical stock trades into a DynamoDB table that uses on-demand capacity mode. Each night at midnight a few million new records are loaded. Reads occur in bursts throughout the day and repeatedly request a small set of keys. The company needs to reduce DynamoDB costs. What strategy should be recommended?

The correct strategy is to deploy DynamoDB Accelerator (DAX), use provisioned capacity mode, and configure DynamoDB auto scaling. DAX is ideal for read-heavy, bursty workloads that repeatedly request a small set of keys, as it provides an in-memory cache that significantly reduces read latency and offloads read requests from DynamoDB, thereby lowering read capacity unit (RCU) consumption. Switching to provisioned capacity mode allows for cost optimization when usage patterns are predictable, especially with auto scaling to adjust capacity based on demand, avoiding over-provisioning or throttling. Incorrect options: Deploying an Amazon ElastiCache cluster would require custom application-level caching logic, which DAX handles transparently for DynamoDB. While Savings Plans can reduce costs, they don't address the operational efficiency or performance aspects as directly as DAX and optimized capacity modes for this specific workload. Simply switching to provisioned capacity without DAX or auto scaling might lead to throttling during bursts or over-provisioning during low usage periods.