Shards, Partition Keys, and Throughput

A Kinesis stream's total throughput capacity is the sum of its shards' individual capacities — each shard supports up to 1MB/sec or 1,000 records/sec of writes, and up to 2MB/sec of reads (shared across consumers unless Enhanced Fan-Out is used). Provisioned mode requires you to explicitly set and manage shard count based on expected load; On-Demand mode has AWS automatically scale shard count based on observed throughput, trading some cost efficiency for operational simplicity.

Every record written to a stream includes a Partition Key, which Kinesis hashes to deterministically assign the record to a specific shard — records sharing the same partition key always land on the same shard, in the order they were written, which is what preserves relative ordering for related events (e.g. all events for one specific user or device). Records with different partition keys may land on different shards, enabling parallel throughput across the stream as a whole.

Choosing a partition key is a similar exercise to choosing a DynamoDB partition key: you want enough distinct values (cardinality) to spread load evenly across all shards, while grouping together exactly the records that need relative ordering preserved — too few distinct key values concentrates traffic on too few shards ('hot shards'), just as a poorly chosen DynamoDB key creates hot partitions.