A transit authority is choosing between Amazon Kinesis Data Firehose and Amazon Kinesis Data Streams to feed ridership counts into a demand-forecasting feature pipeline. The forecasting job only needs to read fresh batches of ridership data every few minutes from S3, with no need for custom per-record processing before landing. Which service fits this requirement?
Select an answer to reveal the explanation.
Short Explanation
Think of Firehose like a mail truck on a fixed route — it collects records, waits for a buffer window, and drops them off at S3 without you having to write and run a custom consumer. That's exactly the batch-every-few-minutes, no-per-record-logic pattern here, which is what Firehose is built for. Kinesis Data Streams is the right call when you need low-latency, per-record custom processing — a job this pipeline doesn't have.
Full Explanation
Kinesis Data Firehose is a fully managed delivery service: you point it at a destination like S3, set a buffering interval or size threshold, and it batches and writes records without requiring a consumer application to poll shards or manage checkpoints. That matches a forecasting job that just needs periodic, buffered arrivals in S3 with no custom transform step. Treating Kinesis Data Streams as the standard path for any stream reaching S3 ignores that Firehose was purpose-built for exactly this delivery pattern; Data Streams is the right choice when a consumer needs low-latency, per-record access — for example, real-time anomaly scoring — which this pipeline doesn't call for. Claiming Firehose gives sub-second per-record consumer access has the two services backwards: Data Streams, not Firehose, is what exposes shards for custom low-latency consumers; Firehose intentionally trades per-record access for simplicity. Saying Firehose cannot deliver to S3 is simply incorrect about the service's core purpose — S3 is one of its standard native destinations. Scope note: if the forecasting pipeline later needs sub-minute freshness or in-flight enrichment, revisit toward Data Streams with a custom consumer. Operational check: confirm the configured buffering interval matches the every-few-minutes freshness the forecasting job actually needs before relying on it.