Una agencia de monitoreo de inundaciones tiene más de 10 000 sensores que envían actualizaciones continuamente, cada una de menos de 1 MB. Los servidores de aplicaciones on-premises reciben las actualizaciones de los sensores, las transforman en registros legibles por humanos y escriben los resultados en una base de datos relacional on-premises. Los analistas ejecutan consultas SQL simples sobre los datos en vivo. Debido al mantenimiento (parches/actualizaciones), estos servidores tienen tiempo de inactividad, y mientras un servidor está inactivo, los servidores restantes no pueden manejar la carga, lo que provoca la pérdida de datos. La agencia desea una mayor disponibilidad y un menor esfuerzo operativo y costo. El arquitecto recomienda usar AWS IoT Core para ingerir los datos de los sensores. ¿Qué diseño adicional debería recomendar el arquitecto para cumplir con los requisitos?

La opción correcta utiliza Kinesis Data Firehose para la ingesta de datos, lo que proporciona escalabilidad y alta disponibilidad sin servidores. Una función de Lambda procesa los datos, convirtiéndolos a Parquet, un formato columnar optimizado para análisis, y los almacena en Amazon S3. Amazon Athena permite a los analistas consultar directamente los datos en S3 usando SQL estándar, lo que reduce el costo y el esfuerzo operativo al eliminar la necesidad de una base de datos relacional dedicada para el análisis. La opción incorrecta que usa Aurora MySQL introduce una base de datos relacional que requiere más gestión y puede ser más costosa para grandes volúmenes de datos de series temporales y consultas ad-hoc. Las opciones que usan Amazon Managed Service for Apache Flink son más complejas y costosas para esta necesidad, ya que Firehose y Lambda son suficientes para la transformación y el almacenamiento.