DynamoDB Streams vs Kinesis Data Streams

DynamoDB Streams is usually the simplest choice for reacting to DynamoDB item changes with Lambda: it retains records for 24 hours and preserves their order per item. Kinesis Data Streams for DynamoDB offers configurable retention up to 365 days and a broader streaming ecosystem, but change records can arrive out of order or more than once. You can enable both on the same table.

What is DynamoDB Streams?

DynamoDB Streams records inserts, updates and deletes from a particular table. You choose whether each record includes keys only, the new image, the old image or both. DynamoDB manages the shards as the table changes; you do not buy or resize stream shards separately.

Each change appears once in the stream, and changes to an individual item retain their order. That is a storage guarantee, not an exactly-once processing guarantee. Lambda may retry the same record, so a notification sender or a derived-table writer must handle duplicates.

Typical uses include detecting order status transitions, archiving TTL deletions, updating a read model and sending changes to another system. For replication of the database itself across Regions, consider global tables before building a custom replicator.

What is Kinesis Data Streams?

Kinesis Data Streams is a general streaming service. Producers can publish application events, telemetry or database changes; consumers maintain their own progress through the stream. Its provisioned mode exposes shard capacity, while on-demand modes manage scaling for you within their applicable quotas.

Kinesis Data Streams for DynamoDB is a managed producer integration. DynamoDB sends item changes to a Kinesis stream without a Lambda bridge. That destination is separate from the table's DynamoDB Stream and can be enabled independently. Each table supports one Kinesis destination in the same account and Region.

Several related AWS services have different jobs:

A Firehose delivery stream and a Kinesis data stream are not interchangeable resources. Choose the data stream for replayable consumption and the delivery service when its destination and buffering behavior fit the job.

Comparison at a glance

The AWS CDC comparison outlines the two integrations. Consult the dedicated Kinesis quota documentation for current mode-specific consumer limits rather than treating every Kinesis stream as having one fixed consumer count.

Retention and replay

The old claim that Kinesis retention stops at seven days is outdated. You can retain data for up to 8,760 hours, or 365 days, with additional retention charges. DynamoDB Streams cannot be extended past 24 hours. Increasing a retention setting does not recover records already removed.

Choose retention based on your longest plausible consumer outage and the replay window needed for deployments or investigations. A stream with a day of history is not a permanent audit archive. If an audit trail must outlive either stream, deliver approved records to durable storage with a retention policy.

A new consumer starts from a configured position; it does not automatically scan existing table contents. For a complete search index or analytical copy, plan an initial snapshot and a checkpointed change-capture handoff. Exporting a snapshot and then enabling a stream afterward leaves a gap for changes in between.

Ordering and duplicate handling

DynamoDB Streams preserves the sequence of changes to one item, not a single order across the table. If two different customers update at the same time, your consumers can process their changes concurrently. A consumer that writes to an external service still needs idempotency because a response can be lost after the external write succeeds.

Kinesis preserves stream sequence within its shards, but the DynamoDB CDC producer can submit item changes in a different order from the original database writes. Do not use the resulting Kinesis sequence number as a database version. AWS documents the ApproximateCreationDateTime field and supports millisecond or microsecond precision for this integration.

For a latest-state projection, an application-managed version attribute can make stale changes detectable. Apply a version only if it is newer than the version already stored in the destination. Define a tie and duplicate policy rather than assuming timestamps alone establish a unique total order. The Kinesis CDC behavior also documents the additional decoding required for binary attribute values.

Consumers, throughput and scaling

DynamoDB Streams works well with a small number of consumers. Adding separate Lambda mappings for every downstream service can cause read throttling. A single handler can fan out through SNS or another event service, or an EventBridge pipe can send records to a target without custom polling code.

Kinesis shared-read consumers compete for shard read capacity. A provisioned shard supports up to 1 MB/s or 1,000 records/s of writes and up to 2 MB/s of shared reads. Shared GetRecords calls are also rate-limited, so five consumers are not five independent allocations of full shard bandwidth.

Enhanced fan-out gives registered consumers dedicated read throughput. The current limit is 20 registered consumers per stream for provisioned and On-demand Standard modes, and 50 for On-demand Advantage. These are Kinesis stream settings and quotas, not additional DynamoDB trigger slots. See Kinesis quotas and limits.

Provisioned streams require capacity planning and shard management. On-demand reduces that work but does not remove hot-key behavior or all stream and account quotas. A DynamoDB table accepting writes successfully does not prove its CDC destination has enough capacity. Monitor destination delivery as well as downstream processing.

Pricing: compare the complete pipeline

DynamoDB Streams pricing

In US East (N. Virginia), the first 2.5 million Streams read requests each month are free; additional requests cost $0.02 per 100,000. This applies separately from the table's on-demand or provisioned read capacity. A GetRecords call is a stream read request even if it returns no records.

Reads made by standard Lambda triggers and global-table replication are not charged. Lambda functions running on Lambda Managed Instances are an exception and pay standard Streams read charges. Lambda execution, logs, failure destinations and downstream writes can still cost money. A custom poller should avoid excessive empty reads.

Kinesis Data Streams pricing

DynamoDB charges $0.10 per million change data capture units in us-east-1, with one unit for a write of up to 1 KB. Item size is based on the larger before or after image. Ten million such changes therefore add $1 in DynamoDB CDC charges, before Kinesis charges.

Kinesis has its own bill, determined by capacity mode, ingestion, consumption, retention and optional features such as enhanced fan-out. Provisioned pricing includes shard time and PUT payload units; on-demand pricing has its own ingestion and consumption structure. Do not carry forward an old tutorial's per-stream hourly figure without checking the selected mode.

Use the DynamoDB pricing page and Kinesis pricing page for the Regions and modes you will deploy. Include the destination system: a continuously running analytics application can cost more than the CDC component itself.

Advantages and limitations in practice

Choose DynamoDB Streams when your main requirement is a Lambda trigger, retention fits within a day, and the small reader budget is sufficient. Automatic shard management and free standard Lambda reads reduce setup and billing complexity. Its main limitations are the short replay window and limited independent readers. A handler that writes back to the source table can also create a loop unless filters and write conditions prevent it.

Choose Kinesis CDC when consumers need a longer replay history, independently provisioned fan-out, or direct integration with Flink, Firehose or Glue streaming ETL. Its tradeoffs are additional billing and operational settings, plus the need to handle out-of-order and duplicate database changes. It is not automatically cheaper or faster for a single Lambda function.

Enable both when the workloads differ. For example, a DynamoDB Stream can drive customer notifications while Kinesis feeds retained analytical events. Each pipeline needs its own monitoring, permissions and recovery plan. Enabling both does not make one a transparent fallback for the other.

Deployment checklist

1. Write down whether you need notifications, a latest-state copy or a complete event history. These require different replay semantics.
2. Count consumers and choose a retention window that covers outages and recovery.
3. Configure the destination and IAM permissions, then verify that CDC is active before relying on it.
4. Test duplicate delivery, stale updates, throttling and a consumer restart against a disposable table.
5. Monitor delivery failures and consumer lag, and verify the recovery procedure before old records expire.

For a Lambda implementation with filtering and partial responses, follow DynamoDB triggers with Lambda. For request, capacity and stream troubleshooting, use DynamoDB logging and monitoring.