A production Aurora MySQL cluster is a single writer node and is heavily queried for reporting. The cluster suffers intermittent performance problems due to high CPU and reaching max connections. A SysOps admin needs to stabilize performance. Which solution will address this requirement?

Creating an Aurora Replica and directing reporting queries to its read-only endpoint effectively offloads read traffic from the primary writer instance, reducing CPU contention and connection limits on the primary. Configuring an Auto Scaling policy for replicas ensures that read capacity dynamically adjusts to demand, preventing future performance bottlenecks during peak reporting periods. Provisioning a second single-node Aurora MySQL cluster in another Availability Zone would create a separate, independent database that would need its own replication strategy to stay in sync with the primary, adding complexity and potential data staleness for reporting. Implementing a Lambda function to cache query results is an application-level caching solution that might help with specific, frequently run queries but doesn't address the underlying database load for all reporting queries or the connection limit issue. Deploying a multi-node ElastiCache cluster is a robust caching solution but requires significant application-level changes to integrate and manage cache invalidation, making it a more complex and potentially overkill solution for simply offloading read traffic from Aurora.