Which solution will reduce the downtime for scaling exercises with the LEAST operational overhead?
Create more Aurora PostgreSQL read replicas in the cluster to handle the load during failover.
Set up a secondary Aurora PostgreSQL cluster in the same AWS Region. During failover, update the application to use the secondary cluster’s writer endpoint.
Create an Amazon ElastiCache for Memcached cluster to handle the load during failover.
Set up an Amazon RDS proxy for the database. Update the application to use the proxy endpoint.
Explanations:
Adding more read replicas can improve read scalability and offload read traffic, but it does not directly reduce downtime during a failover of the writer instance. The failover will still result in downtime as the writer instance switches.
Setting up a secondary cluster may provide a backup option, but switching the application to use the secondary cluster during a failover involves additional complexity and operational overhead, which could lead to longer downtime during the scaling exercise.
Using ElastiCache for Memcached helps with caching data and can reduce the load on the database, but it does not address the downtime caused by the failover of the writer instance itself. It does not provide a solution for immediate failover resilience.
Amazon RDS Proxy sits between the application and the database, allowing for seamless connection management and failover handling. This solution abstracts the database connection, which can help reduce downtime during scaling operations, providing a smoother experience with minimal operational overhead.
In my experience, the answer is:
Set up an Amazon RDS proxy for the database. Update the application to use the proxy endpoint.
I outline that the answer is:
Set up an Amazon RDS proxy for the database. Update the application to use the proxy endpoint.