To cut Amazon Kinesis Data Streams costs, right-size shard count to real throughput first, then choose on-demand mode for spiky streams or provisioned shards for steady ones, trim extended retention you do not replay, and batch small records so payload units fall. Each provisioned shard bills an hourly rate around the clock whether or not data flows, so an over-provisioned stream is pure waste. On-demand mode removes the shard-sizing problem but bills on throughput, so steady high-volume streams are usually cheaper on right-sized provisioned shards. The order matters: size the stream before you change anything else.
Last updated: June 2026 · Written by Fredrik Filipsson and reviewed by Morten Andersen · See, Cut, Lock, Run method
Amazon Kinesis Data Streams is AWS's managed service for ingesting and processing real-time streaming data, billed on shards and throughput in provisioned mode, or on stream-hours and throughput in on-demand mode. The bill grows quietly because shards are easy to add and hard to remember to remove, and because extended retention keeps charging long after the replay window matters. This guide is part of our complete guide to AWS cost optimization, the cluster pillar it links up to.
What drives Amazon Kinesis Data Streams costs?
Kinesis Data Streams cost is driven by shard hours, throughput, and retention, in that order for most streams. In provisioned mode you pay a shard-hour rate, around $0.015 per shard-hour in many Regions, for every shard around the clock, plus PUT payload units charged per million 25 KB units, around $0.014 per million. In on-demand mode you pay a per-stream-hour rate plus data ingested and retrieved, which removes shard sizing but bills the throughput directly. Extended data retention beyond the 24-hour default adds roughly $0.020 per shard-hour, and enhanced fan-out consumers add a separate consumer-shard-hour and data-retrieval charge. Confirm the current rates for your Region against the Kinesis Data Streams pricing page, since rates vary by Region and change over time.
How do I cut Amazon Kinesis Data Streams costs step by step?
Cut the bill by sizing the stream to real throughput, choosing the right mode, and removing retention and per-record overhead you do not need. Work through these five steps in order:
- Measure shard utilization. In Amazon CloudWatch, compare
IncomingBytesandIncomingRecordsagainst each shard's limits of 1 MB per second and 1,000 records per second. Shards sitting well below either limit are over-provisioned. - Choose on-demand or provisioned mode. Move spiky or unpredictable streams to on-demand so you stop paying for idle shards, and keep steady, well-understood streams on provisioned shards where you can size precisely and pay less per unit.
- Right-size provisioned shards. Reduce shard count to match real peak throughput plus a small margin. Use UpdateShardCount to scale down, and remember every shard you remove saves a full hourly rate every hour, day and night.
- Trim data retention. Lower retention from extended back toward the 24-hour default wherever downstream consumers do not need to replay older data, since extended retention adds a per-shard-hour charge on top of the base shard cost.
- Batch and aggregate records. Aggregate small records with the Kinesis Producer Library so each 25 KB payload unit carries more useful data, and batch consumer reads to reduce GetRecords API volume. Fewer, fuller records mean fewer payload units billed.
This is the same cut-waste-before-you-commit discipline behind our AWS cost optimization service. For the cache layer of the same data platform, see the sibling guide ElastiCache cost optimization: Redis reserved nodes and sizing.
Size the shards and pick the mode before you touch retention or batching. A stream with the wrong shard count wastes money every hour; retention and batching are real but smaller wins layered on top of a right-sized stream.
Should I use Kinesis on-demand or provisioned mode?
Use on-demand mode for spiky or unpredictable streams and provisioned mode for steady, high-volume streams. On-demand removes the risk of under-provisioning during a spike and the waste of over-provisioning for a peak that rarely comes, because AWS scales the stream automatically and bills on throughput. The trade is that at steady high volume, on-demand usually costs more per gigabyte than a tightly sized provisioned stream. A practical pattern is to launch new streams on on-demand to learn the real traffic shape, then move the predictable ones to right-sized provisioned shards once the pattern is clear. For streams that only land data in storage or a warehouse, also evaluate whether Amazon Data Firehose, billed on data ingested with no shards to manage, fits better than a raw Data Stream.
Paying for Kinesis shards that sit idle?
Our AWS cost audit reads your stream utilization, right-sizes shard counts, picks on-demand or provisioned per stream, and proves the saving before you change a line of producer code. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →How does data retention affect the Kinesis bill?
Retention affects the bill because every hour of extended retention is billed per shard, on top of the base shard cost. Kinesis Data Streams keeps data for 24 hours by default at no extra retention charge, and you can extend retention up to 365 days, but extended retention adds roughly $0.020 per shard-hour for the window beyond the default. That is easy to leave switched on after a one-off backfill and forget. Set retention to the shortest window your consumers actually replay from, and treat long-term durability as a job for Amazon Data Firehose writing to Amazon S3, not for the stream itself. For the storage side of that pattern, our guide to reducing Amazon S3 request and API costs covers keeping the landing zone cheap.
The AWS Cost Optimization Field Guide includes the streaming-pipeline checklist we run on Kinesis, Firehose, and the consumers behind them, so the savings hold after the first pass.
Frequently asked questions
Is Kinesis on-demand mode more expensive than provisioned?
For steady, high-volume streams, yes, on-demand usually costs more per gigabyte than a tightly sized provisioned stream because you pay for the convenience of automatic scaling. For spiky or unpredictable streams, on-demand is often cheaper overall because it removes the idle-shard waste of provisioning for a peak. Match the mode to the traffic shape.
How much does extended retention cost on Kinesis?
Retention beyond the 24-hour default adds roughly $0.020 per shard-hour for the extended window, on top of the base shard cost. Confirm the current rate for your Region on the AWS pricing page. Set retention to the shortest window your consumers replay from, and use Amazon Data Firehose to S3 for long-term durability.
Does batching records actually lower Kinesis costs?
Yes. PUT payload is billed in 25 KB units, so many tiny records each consume a full unit. Aggregating small records with the Kinesis Producer Library packs more data into each unit, lowering the payload-unit count billed. Batching consumer reads also reduces GetRecords API volume.
Should I use Kinesis Data Streams or Amazon Data Firehose?
Use Data Streams when you need millisecond replayable streaming with multiple custom consumers. Use Amazon Data Firehose when the goal is simply to land streaming data in S3, Redshift, or OpenSearch, since Firehose bills on data ingested with no shards to size and is often cheaper for pure delivery pipelines.
The short version
Kinesis Data Streams cost is a shard-and-retention problem. Measure shard utilization, move spiky streams to on-demand and size steady ones precisely, trim extended retention you do not replay, and batch small records so payload units fall. Size the stream before anything else, because an over-provisioned shard count wastes money every hour. When you want every stream sized correctly and the AWS bill proven down, that is the work our AWS cost optimization service delivers.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: AWS pricing ↗, AWS documentation ↗ and FinOps Foundation Framework ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.