Water-meter gateways emit continuous reading events that a billing enrichment job must process as a stream, not as overnight CSV drops only. Which AWS approach fits application-level streaming ingest?
Select an answer to reveal the explanation.
Short Explanation
Meters do not wait for the overnight CSV truck — readings keep flowing all day. Put that firehose of events into Kinesis and let enrichment consumers work the stream. Batch-only drops miss the continuous nature of the data.
Full Explanation
Water-meter gateways that emit continuous reading events need application-level streaming ingest, not overnight CSV drops alone. Ingest with Amazon Kinesis Data Streams (or Kinesis Data Firehose where appropriate) and process records continuously from application consumers. Streams preserve near-real-time enrichment for billing anomalies, leak detection, and dashboards while Firehose can land transformed data in S3/analytics stores. Municipal utilities lose operational signal when they wait for a nightly file truck.
Landing one CSV in S3 each night and ignoring daytime meter events fails the continuous-processing requirement. Storing each reading only in an email attachment for a clerk to open is not scalable ingest. Requiring operators to paste readings into Systems Manager Run Command each minute is manual toil, not streaming architecture.
Exam caveat: Kinesis Data Streams suits custom consumers and real-time apps; Firehose suits managed delivery to destinations with buffering. Choose based on consumer needs. Design for shard scaling, checkpointing, and poison-record handling.
Operational check: publish meter events to a stream with device and timestamp keys; attach consumers that enrich and write billing or anomaly stores; alert on iterator age; and keep nightly batch only as reconciliation, not as the sole path.