The correct choice is Use Amazon ElastiCache to cache frequently accessed reads in front of the database. Caching leaderboard and hot profile reads in memory reduces database I O and query latency while keeping changes to the application minimal.

Amazon ElastiCache, using Redis or Memcached, stores hot data in memory so reads are served much faster than from disk and the database sees far fewer read queries. A cache can be integrated with a few client library calls and simple time to live and invalidation rules, and that makes it the lowest effort and highest impact change for weekend spikes in read traffic.

Connect the application to the database using Amazon RDS Proxy improves connection management and handles failover more gracefully but it does not reduce the cost or latency of executing slow read queries so it will not eliminate the read throughput bottleneck.

Create Amazon RDS for MySQL read replicas and route read traffic to them can scale read capacity but it requires read write split logic and replicas can experience replication lag which may produce stale leaderboard results. This option is more invasive than adding a cache for very hot, frequently read items.

Migrate the data layer to Amazon DynamoDB would force a major redesign of the data model and application code and would not meet the requirement to minimize architectural changes during an urgent performance problem.

Full AWS Practitioner Certification Question