A company is creating a prototype of an ecommerce website on AWS. The website consists of an Application Load Balancer, an Auto Scaling group of Amazon EC2 instances for web servers, and an Amazon RDS for MySQL DB instance that runs with the Single-AZ configuration. The website is slow to respond during searches of the product catalog. The product catalog is a group of tables in the MySQL database that the company does not update frequently. A solutions architect has determined that the CPU utilization on the DB instance is high when product catalog searches occur. What should the solutions architect recommend to improve the performance of the website during searches of the product catalog?

The correct answer is to implement an Amazon ElastiCache for Redis cluster to cache the product catalog using lazy loading. The product catalog is infrequently updated, making it an ideal candidate for caching. Caching offloads read requests from the database, reducing CPU utilization on the RDS instance and improving search response times. Lazy loading ensures that data is cached only when requested, optimizing cache usage. Migrating to Amazon Redshift is overkill for a product catalog that is not frequently updated and primarily involves read operations from an existing MySQL database. Redshift is designed for analytical workloads on large datasets, not for caching frequently accessed operational data. Adding an additional scaling policy to the Auto Scaling group will not address the database bottleneck; it will only add more web servers that will still contend for the same slow database resources. Turning on Multi-AZ for the DB instance improves availability and disaster recovery, but it does not inherently improve read performance, as the standby instance is not used for read operations in a Single-AZ configuration. Throttling queries would worsen performance, not improve it.