A read-heavy product catalogue runs on a single Amazon RDS for MySQL instance. Most traffic is repeated lookups of the same popular items, and the rest is a growing volume of varied read-only queries that still hit the database directly. The primary's CPU is now saturated and writes are slowing. The team wants to relieve the primary by both serving repeated reads from memory and spreading the remaining varied reads across additional database capacity, without re-architecting onto a different database engine. Which two changes together meet these requirements? Select TWO.
- AAdd Amazon DynamoDB Accelerator (DAX) as an in-memory cache in front of the RDS for MySQL instance to accelerate the repeated reads.
- BConvert the instance to a Multi-AZ deployment and send the read-only queries to the standby instance.
- CPlace an Amazon ElastiCache cluster in front of the database and serve the repeated popular-item reads from the in-memory cache. Correct
- DCreate one or more RDS for MySQL read replicas and direct the varied read-only queries to the replica endpoints. Correct
- EResize the single RDS instance to a much larger instance class so it can absorb all reads and writes on one node.
Why A is wrong: DAX is tempting as an in-memory cache but only works with Amazon DynamoDB, so it cannot front an RDS for MySQL instance.
Why B is wrong: Multi-AZ adds a synchronous standby for failover only; the standby is not readable, so it adds no read-scaling capacity.
Why C is correct: An in-memory cache absorbs the repeated identical lookups so they never reach the primary, directly cutting its read load.
Why D is correct: Read replicas add separate queryable capacity, letting the application spread varied reads off the primary while writes stay on the writer.
Why E is wrong: Scaling up vertically gives a brief headroom boost but keeps every read on one node and does not offload repeated or varied reads.