Una empresa de comercio electrónico ejecuta su aplicación en AWS. La aplicación utiliza un clúster de Amazon Aurora PostgreSQL en modo Multi-AZ para la base de datos. Durante una reciente campaña promocional, la aplicación experimentó una gran carga de lectura y escritura. Los usuarios experimentaron problemas de tiempo de espera al acceder a la aplicación. Un arquitecto de soluciones necesita hacer que la arquitectura de la aplicación sea más escalable y de alta disponibilidad con el MENOR tiempo de inactividad. ¿Qué solución cumplirá estos requisitos?

La opción correcta aborda directamente los problemas de escalabilidad y alta disponibilidad para cargas de lectura y escritura. Añadir instancias de lectura a un clúster de Aurora distribuye la carga de lectura, mejorando el rendimiento y la disponibilidad. Amazon RDS Proxy mejora la escalabilidad y la resiliencia de la aplicación al agrupar y reutilizar las conexiones a la base de datos, lo que reduce la sobrecarga de conexión y la probabilidad de errores de tiempo de espera, especialmente durante picos de tráfico. La primera opción, aunque útil para monitoreo, no escala la base de datos para manejar cargas de lectura/escritura. La segunda opción, ZDR, está diseñada para actualizaciones de software sin tiempo de inactividad, no para escalar el rendimiento de lectura/escritura, y Database Activity Streams es para auditoría, no para escalabilidad. La cuarta opción, ElastiCache, es excelente para reducir la carga de lectura en la base de datos, pero AWS DMS con un enfoque write-around es un método de replicación complejo y no es la solución más directa para la escalabilidad general de lectura/escritura de Aurora con el menor tiempo de inactividad.