Una aplicación de comercio electrónico utiliza Amazon API Gateway y una función AWS Lambda, almacenando datos en una base de datos Amazon Aurora PostgreSQL. Durante un evento de ventas, un aumento repentino de pedidos provocó tiempos de espera agotados (timeouts). El arquitecto de soluciones encontró un alto uso de CPU y memoria en la base de datos debido a muchas conexiones abiertas. Para evitar errores de tiempo de espera con el menor cambio en la aplicación, ¿qué solución debería implementar el arquitecto?

La opción correcta es usar Amazon RDS Proxy. RDS Proxy gestiona y agrupa las conexiones a la base de datos, lo que reduce la sobrecarga de la CPU y la memoria causada por un gran número de conexiones abiertas y concurrentes, especialmente útil para funciones Lambda que abren y cierran conexiones frecuentemente. Al modificar la función Lambda para usar el endpoint de RDS Proxy, se resuelve el problema de las conexiones sin requerir cambios significativos en la lógica de la aplicación. Configurar la concurrencia aprovisionada para Lambda solo ayuda a que la función esté lista más rápido, pero no resuelve el problema subyacente de las conexiones a la base de datos. Una base de datos global en varias regiones no aborda el problema de las conexiones en una sola región. Crear una réplica de lectura ayuda con las lecturas, pero el problema son las conexiones de escritura y lectura que saturan la base de datos principal. Migrar a DynamoDB es un cambio drástico que requiere reescribir la lógica de la aplicación y no es la solución con el menor cambio.