Which solution will resolve this issue with the LEAST operational overhead?
Create a proxy in RDS Proxy. Configure the users’ applications to use the DB instance through RDS Proxy.
Deploy Amazon ElastiCache for Memcached between the users’ applications and the DB instance.
Migrate the DB instance to a different instance class that has higher I/O capacity. Configure the users’ applications to use the new DB instance.
Configure Multi-AZ for the DB instance. Configure the users’ applications to switch between the DB instances.
Explanations:
RDS Proxy is designed to handle varying application workloads and provides connection pooling, reducing the number of open connections to the database. This effectively mitigates connection rejection errors during high demand while requiring minimal operational overhead to set up and manage.
While Amazon ElastiCache can improve application performance by caching frequently accessed data, it does not directly address database connection limits or rejection errors. Implementing caching may add complexity and operational overhead without resolving the underlying connection issues.
Migrating to a larger instance class can improve I/O performance, but it does not specifically address the connection limits that are causing the rejection errors. This option also involves more operational overhead due to the migration process and potential downtime during the switch.
Configuring Multi-AZ increases availability and durability but does not alleviate the issue of connection limits during high demand. The applications would still face connection rejections since both instances would still be subject to the same connection limits. Additionally, this option may introduce complexity without solving the underlying problem.
I rate that the answer is:
Create a proxy in RDS Proxy. Configure the users’ applications to use the DB instance through RDS Proxy.