Una empresa ejecuta un microservicio como una función de AWS Lambda. El microservicio escribe en una base de datos SQL on-premises que solo admite un número limitado de conexiones concurrentes. Cuando el volumen de invocaciones de Lambda aumenta, la base de datos se sobrecarga y falla, lo que provoca tiempo de inactividad. La empresa tiene un enlace de AWS Direct Connect entre la VPC y el centro de datos on-premises. La empresa quiere proteger la base de datos para que no se sobrecargue. ¿Qué solución satisface estos requisitos?

La opción correcta utiliza Amazon SQS como búfer para desacoplar la función Lambda de la base de datos on-premises. Cuando el volumen de invocaciones de Lambda aumenta, los mensajes se encolan en SQS en lugar de sobrecargar la base de datos. La función Lambda consume mensajes de SQS a un ritmo controlado. Al configurar un límite de concurrencia reservada en Lambda inferior a las conexiones máximas de la base de datos, se asegura que Lambda nunca exceda la capacidad de la base de datos, protegiéndola de sobrecargas. Las otras opciones son incorrectas porque: Crear un clúster de Aurora Serverless y migrar datos con DataSync implica un cambio significativo en la arquitectura de la base de datos, no solo proteger la base de datos existente. RDS Proxy es para bases de datos RDS, no para bases de datos on-premises. Publicar en SNS y usar concurrencia aprovisionada no resuelve el problema de la sobrecarga de la base de datos on-premises, ya que SNS no actúa como un búfer de velocidad y la concurrencia aprovisionada solo garantiza una capacidad mínima, no limita la tasa de escritura a la base de datos.