A flood-monitoring agency has over 10,000 sensors that continuously send updates under 1 MB each. On-premises application servers receive sensor updates, transform them into human-readable records, and write results to an on-premises relational database. Analysts run simple SQL queries on the live data. Due to maintenance (patches/updates), these servers have downtime, and while a server is down the remaining servers cannot handle the load, causing data loss. The agency wants higher availability and lower operational effort and cost. The architect recommends using AWS IoT Core to ingest sensor data. What additional design should the architect recommend to meet the requirements?

The correct option leverages AWS IoT Core for ingestion, Kinesis Data Firehose for reliable, scalable delivery, and an AWS Lambda function for transformation to Apache Parquet. Storing data in Amazon S3 as Parquet files is cost-effective and optimized for analytical queries. Amazon Athena provides a serverless, pay-per-query solution for analysts, eliminating the need for database management and ensuring high availability. The first incorrect option uses Aurora MySQL, which can be expensive and operationally complex for large-scale, continuously updated data analytics compared to S3 and Athena. The third and fourth incorrect options introduce Amazon Managed Service for Apache Flink (Kinesis Data Analytics), which is overkill and adds unnecessary complexity and cost for the described transformation and querying needs. Kinesis Data Firehose with Lambda is a simpler, more cost-effective solution for this scenario.