Which solution will meet these requirements?
Create an Aurora Replica node. Create an Auto Scaling policy to scale replicas based on CPU utilization. Ensure that all reporting requests use the read-only connection string
Create a second Aurora MySQL single-node DB cluster in a second Availability Zone. Ensure that all reporting requests use the connection string for this additional node
Create an AWS Lambda function that caches reporting requests. Ensure that all reporting requests call the Lambda function
Create a multi-node Amazon ElastiCache cluster. Ensure that all reporting requests use the ElastiCache cluster. Use the database if the data is not in the cache.
Explanations:
Creating an Aurora Replica node allows for read scaling, which offloads reporting queries from the primary DB cluster. Using Auto Scaling for replicas based on CPU utilization ensures that the system can dynamically adjust to demand, improving performance and stability. Read-only connection strings for reporting ensure that these queries do not compete with write operations.
While creating a second Aurora MySQL single-node DB cluster in a second Availability Zone can provide redundancy, it does not improve read performance or scalability. Reporting requests would still need to access a single node, which does not address the issues of high CPU utilization and maximum connections.
An AWS Lambda function that caches reporting requests may reduce the load on the database, but it does not directly address the issues of CPU utilization or maximum connections in the MySQL database. Additionally, implementing caching through Lambda may introduce complexity and latency.
A multi-node Amazon ElastiCache cluster could help with caching frequently accessed data, reducing database load. However, it does not solve the underlying problem of high CPU utilization and connection limits in the Aurora database itself, as reporting requests would still need to hit the database if data is not cached.