A SaaS billing tier's RDS for MySQL instance is CPU-bound by the same product-catalog SELECT statements from many application servers. Results may be a few seconds stale. Which change takes most of those repeated reads off the database?
Select an answer to reveal the explanation.
Short Explanation
The database is rereading the same page of the catalog for every customer. You put a cache between the application and MySQL so those repeats never arrive. Transfer Acceleration and a NAT gateway do not remember a query result.
Full Explanation
ElastiCache holds the repeated catalog result close to the application, so MySQL stops doing the same SELECT for every server. A few seconds of staleness matches a cache TTL the application can accept. S3 Transfer Acceleration speeds long-distance uploads to S3; it is not an RDS feature and it does not cache SQL. A NAT gateway gives private subnets a path to the internet; it does not store query results. CloudTrail data events are an audit log of API calls, not a read-through cache, and an alarm on read counts only reports the load. Caveat: ElastiCache is not a substitute for RDS failover, and the application must treat a cache miss and a stale key on purpose. Operational check: watch RDS CPU and the cache hit rate after the application starts reading the catalog from ElastiCache.