Kinesis Data Stream vs Firehose
Amazon Kinesis Data Streams is a buffer you read from: records land in shards, and any number of consumers can read them, at their own pace, for as long as you retain them. Amazon Data Firehose has no read API. It batches incoming records and delivers them to S3, Redshift, OpenSearch, Splunk, or an HTTP endpoint. Choose Streams when something has to process the data, Firehose when the data only has to land.
How each service handles records
Kinesis Data Streams
A stream is split into shards, and each shard holds records in order for 24 hours by default, extendable to 7 days or, with long-term retention, up to 365 days. Because the records stay put, consumers are independent: a Lambda function, a Flink job, and a replay of yesterday's traffic can all read the same shard without interfering. That retention window is also your safety net, since a consumer that crashes for an hour picks up where it left off instead of losing the interval.
Capacity comes in two modes. On-demand scales the shard count for you and bills by throughput, which is the sensible default when traffic is uneven. Provisioned mode makes you pick the shard count and split or merge shards yourself as volume changes, and bills per shard-hour, which is cheaper once the load is predictable.
Amazon Data Firehose
Firehose has no shards, no consumers, and nothing to scale. You point it at a destination and it accumulates records until a buffer fills, at most 128 MB or 900 seconds for S3, then writes the batch out. That buffering is why Firehose is near-real-time rather than real-time: data arrives in the destination seconds to minutes behind the source.
It does light work on the way through. Firehose can convert JSON to Parquet or ORC, compress with GZIP or Snappy, partition by keys in the record, and invoke a Lambda function to transform each batch. What it cannot do is let a second system read the same records, which is the line that decides most architectures. Billing follows the volume ingested, with no charge for idle capacity.
Which one a workload needs
Firehose fits when the destination is the point: shipping application logs to S3 for later analysis, feeding a Redshift table that powers dashboards, or sending operational logs to OpenSearch. It also fits as the cheap tail of a pipeline, because a Data Stream can fan out to Firehose for archival while a separate consumer does the live work.
Data Streams fits when something reacts to the record: alerting on IoT telemetry, running a fraud check on a transaction, joining events across a window, or serving several teams that each want the same feed. If you need ordering per key, replay after a bad deploy, or more than one consumer, Firehose alone cannot do it.
Choosing between Data Streams and Firehose
Ask whether any code needs to see the records before they land. If the answer is no, use Firehose and skip shard management entirely. If the answer is yes, or might become yes, start with Data Streams and add Firehose as one of its consumers when you also want the raw feed in S3. For how Kinesis compares to the rest of AWS messaging, see Kinesis vs SQS, MSK vs Kinesis, and Kinesis vs EventBridge.
Streaming pipelines end at your own infrastructure. Getting the same events out to customers is a different problem: their endpoints go down, respond slowly, and need signed requests they can verify. [Svix]https://www.svix.com/?utm_source=resources&utm_medium=content) delivers those webhooks with retries, signatures, and delivery logs, so a Kinesis consumer can hand off an event and be done with it.
Ready to send webhooks?
Svix handles signing, retries, rate limiting, and delivery observability for the webhooks you send to your users, so your team can stay focused on your product.
Start sending webhooks with Svix or read the build vs. buy analysis