Una empresa necesita una solución sin servidor que recopile eventos de Amazon EC2 Auto Scaling de todas las aplicaciones en una cuenta de AWS y almacene los datos de estado en Amazon S3 para actualizaciones de paneles casi en tiempo real. La solución no debe afectar la velocidad de los lanzamientos de instancias EC2. ¿Cómo debe la empresa mover los datos a Amazon S3 para cumplir con estos requisitos?

La opción correcta es utilizar un flujo de métricas de Amazon CloudWatch para enviar los datos de estado de EC2 Auto Scaling a Amazon Kinesis Data Firehose y luego almacenarlos en Amazon S3. CloudWatch puede recopilar eventos de Auto Scaling y los flujos de métricas son una forma eficiente de enviar estos datos a Kinesis Data Firehose, que a su vez entrega los datos a S3 de forma casi en tiempo real sin afectar el rendimiento de los lanzamientos de instancias. Las otras opciones son incorrectas porque: Lanzar un clúster de Amazon EMR es una solución excesivamente compleja y costosa para esta tarea, y no es sin servidor. Crear una regla de EventBridge para invocar una función Lambda en un cronograma no es ideal para eventos en tiempo real y podría introducir latencia o complejidad innecesaria en la recopilación de eventos de Auto Scaling. Utilizar un script de arranque con Kinesis Agent en las instancias EC2 no es adecuado, ya que los eventos de Auto Scaling son generados por el servicio Auto Scaling en sí, no por las instancias individuales. Además, la solución debe ser sin servidor.