Una aplicación de comercio electrónico expone una API a través de Amazon API Gateway que invoca funciones de AWS Lambda. Los datos se almacenan en una instancia de base de datos de Amazon RDS for PostgreSQL. Durante una venta flash, las llamadas a la API se dispararon y la aplicación se ralentizó: CloudWatch mostró muchas invocaciones de Lambda, una gran cantidad de conexiones a la base de datos y un alto uso de CPU en la instancia de base de datos. ¿Qué debería recomendar el arquitecto de soluciones para mejorar el rendimiento?

La respuesta correcta es crear un Amazon RDS Proxy y actualizar la función Lambda para conectarse a través de su endpoint. RDS Proxy es ideal para aplicaciones sin servidor como AWS Lambda porque agrupa y reutiliza las conexiones a la base de datos, reduciendo la sobrecarga de establecer nuevas conexiones para cada invocación de Lambda. Esto aborda directamente el problema de las muchas conexiones a la base de datos y el alto uso de CPU en la instancia de RDS durante picos de tráfico. Aumentar la memoria de Lambda podría mejorar el rendimiento de la función, pero no resuelve el problema fundamental de las conexiones a la base de datos. Modificar el código para cerrar conexiones inmediatamente es una buena práctica, pero RDS Proxy lo gestiona de forma más eficiente a escala. Añadir ElastiCache for Redis es una solución de caché válida para reducir la carga de la base de datos, pero RDS Proxy es una solución más directa y menos compleja para la gestión de conexiones en Lambda. Reutilizar una única conexión fuera del handler es una mejora, pero RDS Proxy ofrece una solución más robusta y escalable para la gestión de conexiones en entornos sin servidor.