Which actions should a solutions architect take to automatically adjust to the increased read load on the database?

Explanations:

Migrating to Aurora Serverless is a good choice for workloads with idle periods and sudden spikes. Aurora Serverless automatically scales the database capacity up and down based on application needs, including both compute and memory resources. It also pauses the database when it’s idle, which can save costs. This directly addresses the need for an automated solution for performance issues during peak hours and also handles the idle time cost effectively.

Increasing the instance size manually is not an automated solution. It requires manual intervention and doesn’t dynamically adjust to the changing workload. This does not address the requirement of an automated solution.

Configuring Aurora Auto Scaling with Aurora Replicas is the standard approach for scaling read capacity in Aurora. Auto Scaling automatically adds or removes read replicas based on metrics like CPU utilization or connection count. This addresses the performance issues caused by increased read load during peak hours. This is an automated solution for scaling reads.

Aurora multi-master is designed for applications that require continuous write availability in multiple Availability Zones. It’s not primarily a scaling solution for read-heavy workloads. It also adds complexity and cost compared to using read replicas. It’s not the most appropriate choice for this specific scenario.

Migrating to a standard RDS for MySQL Multi-AZ deployment doesn’t address the scaling requirements. Multi-AZ provides high availability for failover but doesn’t automatically scale read capacity in response to traffic spikes. It also doesn’t provide the same read scaling capabilities as Aurora.