A city portal repeatedly reads the same reference data from Amazon RDS, driving a costly sprawl of read replicas. What cost-aware alternative should the architect evaluate?
Select an answer to reveal the explanation.
Short Explanation
If every page asks RDS the same question, stop hiring more replica waiters—put ElastiCache at the door. Caching hot reads is often cheaper than replica sprawl.
Full Explanation
Introducing Amazon ElastiCache to serve repeated reads so fewer RDS read replicas are required is the correct cost-aware alternative when a city portal repeatedly reads the same reference data from Amazon RDS and drives costly replica sprawl. Caching hot reference data offloads the database and often replaces a herd of replica instances with a smaller cache tier. Adding unlimited cross-Region read replicas for every page view fails by multiplying replica cost and complexity without addressing repeat-read locality. Turning off Multi-AZ on the primary to improve read throughput fails conceptually: Multi-AZ is for high availability of the primary; disabling it harms resilience and is not a read-scaling strategy. Storing the reference data only in client browser cookies fails because cookies are size-limited, user-controlled, and inappropriate as the authoritative municipal reference-data store. Exam caveat: cache repeated RDS reads with ElastiCache before endless replica growth; do not disable Multi-AZ or push reference data into cookies. Operational check: identify hottest reference queries; deploy Redis/Memcached with TTLs aligned to data freshness; reduce replica count after cache hit rates stabilize; watch portal latency; and keep Multi-AZ on the primary for availability.