Kinesis Data Streams vs. Amazon Data Firehose: The SAA-C03 Streaming Data Decision You Need to Nail

Here is the scenario you are almost certain to see on the SAA-C03:

A financial services company collects clickstream events from its trading platform at 5 MB/second. Two downstream systems need access to the stream simultaneously: a real-time fraud detection application that must process every event within one second, and a compliance archival system that loads daily batches into an Amazon Redshift data warehouse. The company also needs the ability to re-process the last 48 hours of data if the fraud model is retrained. Which AWS service or combination of services should the solutions architect use?

If your instinct is "they both handle streaming, so maybe Firehose can do it all" — that's exactly the misconception the question is testing. Kinesis Data Streams and Amazon Data Firehose share a family name but they are architecturally different services that solve different problems at different layers of a streaming pipeline. Getting them mixed up is one of the most common mistakes on streaming data questions, and it's the kind of conceptual confusion that quietly drains points across multiple domains.

The correct answer to the scenario above is Kinesis Data Streams feeding both the fraud detection application directly and an Amazon Data Firehose delivery stream for Redshift — because only Data Streams supports replay and simultaneous independent consumers. This guide gives you the mental model to arrive at that conclusion on your own for any streaming question the exam can construct.

---

The Fundamental Shape of Each Service

Before going deep on mechanics, lock in the basic shape:

• Kinesis Data Streams: A durable, ordered, replayable log of records. Multiple consumers can read the same data independently, at their own pace. You write the consumer code. Data sits in the stream for hours or days, available to be re-read.
• Amazon Data Firehose: A fully managed delivery pipe. Data comes in, gets buffered, optionally transformed by a Lambda function, and pushed to a destination (S3, Redshift, OpenSearch, Splunk, or an HTTP endpoint). No consumer code. No replay. Once delivered, the data is gone from the stream.

The exam exploits exactly one key difference in almost every question: only Data Streams supports replay. Everything else follows from that.

---

Amazon Kinesis Data Streams in Depth

The Shard Model

A Kinesis data stream is divided into shards — the fundamental throughput unit. Each shard provides:

• Write capacity: 1 MB/second or 1,000 records/second (whichever comes first)
• Read capacity: 2 MB/second

You scale a stream by adding shards. If your producer generates 5 MB/second, you need at least 5 shards. The shard count determines both your throughput ceiling and your cost.

Every record is written with a partition key — a string that Kinesis hashes to determine which shard the record goes to. Records with the same partition key always land on the same shard, which is how Kinesis guarantees ordering: within a shard, records are stored and delivered in strict sequence. There is no ordering guarantee across shards.

Data Retention and Replay

This is the feature that defines Data Streams:

Retention Tier	Duration	Additional Cost
Default retention	24 hours	Included
Extended retention	Up to 7 days	Additional per-shard charge
Long-term retention	Up to 365 days	Additional per-GB charge

Every record placed in a Kinesis data stream is available for any registered consumer to read, at any time, until that record's retention window expires. If a consumer crashes, falls behind, or needs to re-process yesterday's events after a bug fix — it simply reads from an earlier sequence number. This is what "replay" means: the data is still there.

Amazon Kinesis Data Streams documentation describes the put-to-get delay — the time between when a producer writes a record and when a consumer can read it — as typically less than one second. That sub-second latency is the basis for real-time processing use cases.

Multiple Independent Consumers

The other major differentiator: multiple independent consumer applications can read the same Kinesis data stream simultaneously, each tracking its own position in the stream. A fraud detection service, an analytics pipeline, and a compliance archiver can all read the same stream at their own pace without interfering with each other.

Enhanced Fan-Out (available via SubscribeToShard) dedicates 2 MB/second per registered consumer per shard via a push model, rather than sharing the 2 MB/second shared pool across polling consumers. For high-throughput multi-consumer scenarios, this matters.

Consumers are written using the Kinesis Client Library (KCL), AWS Lambda triggers, Amazon Managed Service for Apache Flink, or direct API calls. The consumer code is your responsibility.

---

Amazon Data Firehose in Depth

What It Is (and What It Isn't)

Amazon Data Firehose (renamed from Kinesis Data Firehose in February 2024 — same APIs, new name) is a fully managed service for delivering streaming data to persistent destinations. You configure a Firehose stream, point your producers at it, and AWS handles everything: buffering, optional format conversion, optional Lambda transformation, and delivery.

There are no shards to manage, no consumer code to write, no infrastructure to operate. This zero-management model is Firehose's primary value proposition — and the reason the exam places it as the correct answer whenever a scenario says something like "with minimal operational overhead" or "without writing consumer applications."

Destinations

Amazon Data Firehose delivers to these destinations:

• Amazon S3 — the most common; data lands as objects in your bucket
• Amazon Redshift — Firehose writes to S3 first, then issues a COPY command to load into Redshift
• Amazon OpenSearch Service — including OpenSearch Serverless
• Splunk — with optional backup to S3
• HTTP endpoints — including third-party providers (Datadog, New Relic, Coralogix, MongoDB, Dynatrace)
• Apache Iceberg Tables — for open table format scenarios

Buffering: Why Firehose Is Near-Real-Time, Not Real-Time

Before delivery, Firehose buffers incoming records by either time (60 seconds to 900 seconds) or size (1 MB to 128 MB), whichever threshold is hit first. This means the minimum possible latency for data to land in S3 is 60 seconds. If your scenario requires sub-second processing, Firehose cannot meet that requirement.

Optional Lambda Transformation

You can configure a Lambda function that Firehose invokes to transform each batch of records before delivery — common uses include format conversion (JSON to Parquet), filtering records, and enriching events with additional data. The transformation adds latency but no additional consumer infrastructure.

No Replay, No Ordering

Firehose does not retain data after delivery. There is no sequence number, no position tracking, and no way to re-read a record once it has been delivered to the destination. If the delivery fails, Firehose has a retry mechanism and can back up failed records to an S3 error bucket — but this is error handling, not replay. Additionally, Firehose makes no ordering guarantees within a delivery batch.

---

The Comparison Table the Exam Tests From

Dimension	Kinesis Data Streams	Amazon Data Firehose
Primary purpose	Real-time, multi-consumer data streaming	Managed delivery to storage/analytics destinations
Replay	✅ Yes (24 hours to 365 days)	❌ No
Ordering	✅ Guaranteed within a shard	❌ No guarantee
Latency	Sub-second (typically ~1 second put-to-get)	Near-real-time (60-second minimum buffer)
Multiple consumers	✅ Yes — independently, simultaneously	❌ No — one delivery path
Consumer code	Required (KCL, Lambda, Flink, SDK)	Not needed — fully managed
Destinations	Custom (your consumer decides)	S3, Redshift, OpenSearch, Splunk, HTTP
Scaling unit	Shards (manual or automatic)	Serverless (auto-scales)
Pricing model	Per shard-hour + PUT payload units	Per GB ingested
Lambda transform	Via consumer code	✅ Built-in optional transform step
Data source for Firehose	✅ Can be a Firehose source	N/A

---

Four Exam Scenarios, Decoded

Scenario 1: The Fraud Detection + Archival Split

A company processes payment events at 3 MB/second. A real-time fraud model must evaluate each event within 500 milliseconds. A separate compliance team needs all events loaded into Amazon Redshift every hour for regulatory reporting. The company requires the ability to re-run the fraud model against the last seven days of data after model updates. Which architecture should the solutions architect recommend?

Correct answer: Kinesis Data Streams with the fraud detection application as one consumer and Amazon Data Firehose (configured to read from the same stream) as the delivery mechanism to Redshift.

Working through the requirements:

• "Within 500 milliseconds" — Firehose's minimum 60-second buffer eliminates it as the real-time processing layer. → Data Streams for the fraud model.
• "Re-run against the last seven days" — this is replay. Only Data Streams retains data (with extended retention enabled). Firehose cannot replay.
• "Load into Redshift every hour" — this is exactly Firehose's job: buffer, batch, and COPY into Redshift with zero consumer code.
• Firehose can use a Kinesis data stream as its source, so the same stream that feeds the fraud model also feeds Firehose for the Redshift load. One stream, two consumers.

---

Scenario 2: The Data Lake Ingestion

A media company generates 500 GB of video play events daily from 10 million users. The events need to be stored in Amazon S3 in Parquet format for downstream batch analytics jobs. The operations team has no bandwidth to manage streaming infrastructure. Which is the most operationally efficient solution?

Correct answer: Amazon Data Firehose with a Lambda transformation function to convert JSON to Parquet, delivering to Amazon S3.

Working through the requirements:

• "Batch analytics" — no sub-second latency requirement. The 60-second Firehose buffer is fine.
• "No bandwidth to manage streaming infrastructure" — Firehose is serverless and fully managed. No shards to monitor, no consumer applications to operate.
• "Parquet format" — Firehose's built-in Lambda transformation handles JSON-to-Parquet conversion.

Why not Data Streams? You could build this with Data Streams — but you'd need to write a consumer application, operate it, and manage shard scaling. Firehose achieves the same outcome with no code and no servers. When the exam says "minimal operational overhead" and the destination is S3/Redshift/OpenSearch, Firehose wins.

---

Scenario 3: The Multiple Analytics Teams

A gaming company streams player activity events from mobile clients. Three independent teams — an engagement analytics team, an anti-cheat team, and a marketing personalization team — each need to process the full event stream at their own pace without interfering with each other. One team sometimes needs to reprocess yesterday's events after fixing a bug in their pipeline. Which service should the solutions architect use?

Correct answer: Amazon Kinesis Data Streams.

• "Three independent teams" processing the same data simultaneously → multiple consumers → Data Streams.
• "At their own pace without interfering" — each consumer tracks its own shard iterator independently.
• "Reprocess yesterday's events" — replay. Firehose has already delivered yesterday's data to its destination; it cannot provide replay.

Why not Firehose? Firehose has a single delivery path. You cannot have three independent teams consuming the same Firehose stream at their own positions — Firehose doesn't work that way. It delivers to a destination and moves on.

---

Scenario 4: The Log Analytics Pipeline

A company wants to stream application logs from 200 EC2 instances to Amazon OpenSearch Service for real-time search and dashboards. The solution should require no custom consumer code and should handle scaling automatically. Which service should the solutions architect recommend?

Correct answer: Amazon Data Firehose with an OpenSearch Service destination.

• OpenSearch Service is a native Firehose destination.
• "No custom consumer code" — Firehose's defining characteristic.
• "Handles scaling automatically" — Firehose is serverless; no shard management.

The logs land in OpenSearch within roughly 60–120 seconds of generation — "near-real-time" is the correct characterization on the exam. If the question said "within one second," the answer would shift to Data Streams with a custom Lambda consumer.

---

A Note on the Name Change: Kinesis Data Firehose → Amazon Data Firehose

In February 2024, AWS renamed Amazon Kinesis Data Firehose to Amazon Data Firehose. The console reflects the new name; the service works identically. The APIs, CloudWatch metrics, IAM action prefixes (firehose:*), and CloudFormation resource types are unchanged.

Why does this matter for the exam? Some exam questions and their official answer explanations may still say "Kinesis Data Firehose" — particularly older question versions not yet updated. Treat both names as referring to the same service. If an answer choice says "Kinesis Data Firehose" and the context fits Firehose's capabilities, select it.

---

Exam Traps and How to Dodge Them

Trap 1: Seeing "Kinesis" and assuming both services are interchangeable. Data Streams and Firehose are under the Kinesis umbrella, but they serve different purposes. The instant you see "replay" or "multiple independent consumers," Firehose is eliminated — it cannot do either.

Trap 2: Thinking Firehose delivers in real-time. The minimum buffer interval is 60 seconds. "Real-time" processing requires Data Streams (or another service). "Near-real-time" or "streaming to S3/Redshift" maps to Firehose.

Trap 3: Assuming you need custom code for streaming to S3. If the requirement is to continuously load data into S3, Redshift, or OpenSearch with no application code, Firehose is the right answer — even though it's a streaming service. The fully managed delivery model is Firehose's purpose.

Trap 4: Forgetting that Firehose can source from Data Streams. A common architecture places Kinesis Data Streams at the front (for real-time consumers) and connects Firehose to that same stream as a source for loading into S3 or Redshift. This is a single producer → single stream → multiple paths design. On the exam, when you see both real-time processing and delivery-to-storage requirements in the same question, this combination is almost always the correct answer.

Trap 5: Confusing ordering guarantees. Data Streams guarantees ordering within a shard by partition key. Firehose makes no ordering guarantee at all. If the scenario includes "process events in the order they were generated" for a given entity (e.g., transactions for a specific account), Data Streams with a consistent partition key (the account ID) is required.

---

The Decision Tree

Use this every time you see a streaming scenario on the exam:

The path to Firehose is narrow: if the scenario requires replay, multiple independent consumers, or sub-second latency, Data Streams is required. Firehose is the right answer only when all three of those requirements are absent and the destination is S3, Redshift, OpenSearch, or a similar managed target.

---

How This Shows Up in the DVA-C02

The Kinesis pair appears on both the SAA-C03 (Design High-Performing Architectures) and the DVA-C02 (Develop Solutions). On the Developer Associate, the additional nuance is integration patterns:

• Lambda as a Kinesis Data Streams consumer — Lambda polls the stream and processes record batches. You control the batch size and bisect-on-error behavior (to prevent a poison record from blocking the entire shard).
• Firehose with Lambda transformation — Lambda receives a batch of records from Firehose, transforms them, and returns the transformed batch. This is not a long-running consumer; it's a transformation step inside the Firehose pipeline.
• SQS vs. Kinesis Data Streams for ordering — both SQS FIFO and Kinesis Data Streams provide ordering, but they solve different problems: SQS FIFO is a queue with exactly-once delivery, Kinesis is a replayable log for continuous streaming.

---

Practice These Patterns Until They're Automatic

The replay/no-replay distinction sounds simple in writing. On exam day, under a two-minute timer with four plausible answer choices, it's surprisingly easy to reach for Firehose's "streaming" label and miss the replay requirement buried in the scenario stem. The only way to make this automatic is to work through realistic scenario questions until the pattern fires without conscious effort.

The free SAA-C03 practice questions include streaming data scenarios that test exactly these trade-offs — including combination architectures where both services appear as answer components. Run through them before your exam, and pay particular attention to questions where the answer explanation says "because replay is required" — those are the questions that separate 720-point passes from 690-point retakes.

Start with the free 10-question diagnostic — no signup required — and find out in under ten minutes whether streaming data is a weak spot before you walk into the exam.