Una empresa ejecuta una aplicación crítica en la que API Gateway expone una API HTTP integrada con una función Lambda. La aplicación almacena datos en una instancia de RDS for MySQL (2 vCPUs, 64 GB de RAM). Durante períodos pico impredecibles, algunas llamadas a la API devuelven errores HTTP 500. Los registros de CloudWatch muestran "demasiadas conexiones". La base de datos debe permanecer disponible excepto durante el mantenimiento programado. ¿Cómo puede la empresa hacer que la aplicación sea resistente a los picos de conexión?

Amazon RDS Proxy es la solución más eficaz para manejar picos de conexión en este escenario. Actúa como un grupo de conexiones (connection pool) entre la aplicación (Lambda) y la base de datos RDS, reutilizando las conexiones existentes y reduciendo la sobrecarga de establecer nuevas conexiones. Esto permite que la base de datos maneje más solicitudes concurrentes sin agotar sus límites de conexión, resolviendo los errores HTTP 500 causados por "demasiadas conexiones". Reducir las vCPU y aumentar maxconnections es incorrecto porque reducir las vCPU disminuiría el rendimiento general de la base de datos, y aunque aumentar maxconnections podría ayudar temporalmente, no aborda eficientemente la gestión de conexiones durante picos. Crear una alarma de CloudWatch para cambiar la clase de instancia es incorrecto porque el escalado de instancias de RDS toma tiempo y no es una solución reactiva inmediata para picos de conexión repentinos. Además, el problema no es de capacidad de la instancia, sino de gestión de conexiones. Usar EventBridge para aumentar maxconnections es incorrecto porque maxconnections es un parámetro estático que requiere un reinicio de la base de datos para aplicarse, lo que causaría tiempo de inactividad, y no escalaría dinámicamente las conexiones de manera eficiente.