> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # Kinesis > AWS Kinesis. An ordered, sharded record stream with a retention window, where each consumer tracks its own position and can replay past records. **On this page** * [Coverage by target cloud](#coverage-by-target-cloud) * [How the targets compare](#how-the-targets-compare) * [Max adaptation](#max-adaptation) * [On Google Cloud](#on-google-cloud) * [Via Pub/Sub](#via-pub/sub) * [Via Managed Service for Apache Kafka](#via-managed-service-for-apache-kafka) * [On Google Cloud and Private Kubernetes](#on-google-cloud-and-private-kubernetes) * [Via Strimzi Kafka](#via-strimzi-kafka) * [On Azure](#on-azure) * [On OCI](#on-oci) ## Coverage by target cloud | Target | Available | | ------------------ | --------- | | Google Cloud | ✓ | | Azure | ✓ | | OCI | ✓ | | Private Kubernetes | ✓ | ## How the targets compare Each row compares a capability of Kinesis with its adaptation on each target. A dash means this row is not stated for that target. ### Max adaptation #### Runtime surface | Capability | Kinesis | Google Cloud · Pub/Sub | Google Cloud and Private Kubernetes · Strimzi Kafka | Google Cloud · Managed Service for Apache Kafka | Azure | OCI | | -------------------------------------- | ----------------------- | -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | Ordered ingest · partition key → shard | shard (hash-key ranges) | an ordering key (per-key order preserved; no fixed addressable shard count) | partition (the layer replicates Kinesis's hash-key partitioner) | partition (the layer replicates Kinesis's hash-key partitioner) | partition (the layer replicates Kinesis's hash-key partitioner) | partition (the layer replicates Kinesis's hash-key partitioner) | | Sequence numbers · replay position | native | generated in order within each ordering key; replay can seek to a timestamp or snapshot, not an exact message offset | synthesized, per-shard monotonic, decode to a seek position | synthesized, per-shard monotonic, decode to a seek position | synthesized, per-shard monotonic, decode to a seek position | synthesized, per-shard monotonic, decode to a seek position | | KCL checkpointing · consumer position | DynamoDB lease table | Pub/Sub subscription acks (not consumer-group offsets) + a co-deployed DynamoDB adapter for the KCL lease table | target consumer-group offsets + a co-deployed DynamoDB adapter for the lease table | target consumer-group offsets + a co-deployed DynamoDB adapter for the lease table | target consumer-group offsets + a co-deployed DynamoDB adapter for the lease table | target consumer-group offsets + a co-deployed DynamoDB adapter for the lease table | | Retention | 24 h - 365 d | up to Pub/Sub's \~31-day cap, short of Kinesis's 365 days | up to Kinesis's 365-day ceiling (broker retention.ms; storage cost is the broker's) | up to Kinesis's 365-day ceiling (broker retention.ms; storage cost is the broker's) | up to Event Hubs's ceiling (\~90 days on Premium/Dedicated), short of Kinesis's 365 days | OCI Streaming's managed retention window (under OCI quotas) | | Resharding | Yes | No - no analog; Pub/Sub auto-scales, out of scope | Partial - add partitions (UpdateShardCount up); split/merge/reduce out of scope | Partial - add partitions (UpdateShardCount up); split/merge/reduce out of scope | Partial - add partitions (UpdateShardCount up); split/merge/reduce out of scope | Partial - add partitions (UpdateShardCount up); split/merge/reduce out of scope | | Enhanced fan-out | Yes | Yes - a Pub/Sub subscription per consumer, each receiving its own copy of the stream | Partial - a consumer group per enhanced-fan-out consumer; dedicated-throughput SLA becomes broker-limited | Partial - a consumer group per enhanced-fan-out consumer; dedicated-throughput SLA becomes broker-limited | Partial - a consumer group per enhanced-fan-out consumer; dedicated-throughput SLA becomes broker-limited | Partial - a consumer group per enhanced-fan-out consumer; dedicated-throughput SLA becomes broker-limited | | API coverage | full | high | high | high | high | high | #### Limits | Capability | Kinesis | Google Cloud · Pub/Sub | Google Cloud and Private Kubernetes · Strimzi Kafka | Google Cloud · Managed Service for Apache Kafka | Azure | OCI | | ---------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Capacity mode · PROVISIONED / ON\_DEMAND | Yes | Partial - Pub/Sub scales automatically; a PROVISIONED shard count does not create a fixed set of addressable shards | Partial - PROVISIONED → a fixed partition count; ON\_DEMAND (auto-scaled shards) has no elastic analog on a fixed-partition broker, served at a provisioned partition count | Partial - PROVISIONED → a fixed partition count; ON\_DEMAND (auto-scaled shards) has no elastic analog on a fixed-partition broker, served at a provisioned partition count | Partial - PROVISIONED → a fixed partition count; ON\_DEMAND (auto-scaled shards) has no elastic analog on a fixed-partition broker, served at a provisioned partition count | Partial - PROVISIONED → a fixed partition count; ON\_DEMAND (auto-scaled shards) has no elastic analog on a fixed-partition broker, served at a provisioned partition count | ## On Google Cloud ### Via Pub/Sub | Operation | Area | Support | Depth | Notes | | -------------------------------------------------------------------------------------- | ------------------ | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Capacity mode (PROVISIONED / ON\_DEMAND) | Capacity | Partial | Common | Pub/Sub scales automatically, matching ON\_DEMAND behavior. It cannot provide the fixed, addressable shard set of PROVISIONED mode; a supplied shard count does not control capacity | | GetRecords (Limit / NextShardIterator / MillisBehindLatest) | Consume | Partial | Most usage | GetRecords maps to a StreamingPull drain of the subscription (the same receive path as the SQS→Pub/Sub adapter); AT\_TIMESTAMP maps to a Pub/Sub Seek, but replay to an exact sequence position is Partial: Seek is timestamp/snapshot-granular, not per-message offset | | GetShardIterator (TRIM\_HORIZON / LATEST / AT\_TIMESTAMP / AT/AFTER\_SEQUENCE\_NUMBER) | Consume | Supported | Most usage | TRIM\_HORIZON maps to the start, LATEST to the tail, and AT\_TIMESTAMP to a Pub/Sub Seek; AT/AFTER\_SEQUENCE\_NUMBER has no exact analog because Pub/Sub has no per-message offset, so at-sequence positioning is Seek-granular (timestamp/snapshot), not per-message | | Sequence numbers | Consume | Supported | Most usage | the adapter generates sequence numbers that increase within each ordering key. Pub/Sub has no per-message offset, so a number cannot select an exact message for replay; seeking uses a timestamp or snapshot | | KCL (checkpoint via a DynamoDB lease table) | Consumer framework | Partial | Full surface | the Kinesis Client Library (KCL) uses Pub/Sub subscriptions and acknowledgements. For its separate checkpoint lease table, deploy the DynamoDB adapter or another DynamoDB-compatible table alongside Kinesis | | CreateStream / DeleteStream / DescribeStream | Control plane | Supported | Common | Terraform creates a Pub/Sub topic. A supplied shard count does not create addressable shards; DescribeStream reports the logical stream without a fixed shard set | | Enhanced fan-out (RegisterStreamConsumer / SubscribeToShard) | Fan-out | Supported | Full surface | each enhanced-fan-out consumer maps to its own Pub/Sub subscription, each receiving its own copy of the stream, though the dedicated per-consumer throughput SLA becomes Pub/Sub's own | | PutRecord (partitionKey → shard) | Ingest | Supported | Common | PutRecord publishes with the partition key as Pub/Sub's ordering key, so 'same key → same order' holds (the core guarantee a shard provides); Pub/Sub has no shards and no hash-key ranges, so 'same key → same shard' and ExplicitHashKey have no shardless analog and are out of scope | | PutRecords (batch) | Ingest | Supported | Common | returns a PutRecordsResultEntry for each record in the batch | | Shard-level metrics (EnableEnhancedMonitoring, per-shard CloudWatch) | Observability | Out of scope | Full surface | Kinesis's enhanced per-shard CloudWatch metrics (per-shard IncomingBytes/Records, OutgoingBytes/Records, IteratorAgeMilliseconds) are AWS-specific; no target exposes the Kinesis-named CloudWatch series or the enhanced-monitoring toggle; the broker/topic publishes its own metrics under its own names (Kafka and Event Hubs do expose per-partition metrics), so observability moves to the target's native monitoring | | Resharding (SplitShard / MergeShards / UpdateShardCount) | Resharding | Out of scope | Full surface | Pub/Sub auto-scales and has no addressable shard; SplitShard/MergeShards/UpdateShardCount have no analog, so design for Pub/Sub's own elasticity rather than a fixed shard count | | Server-side encryption (KMS) | Security | Supported | Most usage | at-rest encryption is the target's own: the managed targets always encrypt at rest (so a request for no encryption has no representation there), while a self-hosted broker encrypts per its storage/volume configuration; a customer-managed key maps where the target offers one (CMEK on Pub/Sub and managed Kafka; tier-gated on Event Hubs; the storage layer's key on a self-hosted broker), not necessarily per-stream | | Retention | Storage | Supported | Most usage | retention maps to Pub/Sub's message retention, which caps at \~31 days, well short of Kinesis's 365-day ceiling, so multi-month replay is out of reach on this target | #### Ordered messages without addressable shards The adapter maps the Kinesis stream to a Pub/Sub topic and uses the partition key as an ordering key. This preserves the intended order within a key, but Pub/Sub does not expose Kinesis hash ranges or a fixed set of addressable shards. ExplicitHashKey and split/merge operations cannot be represented by that ordering-key mapping. Reads drain a Pub/Sub subscription. Pub/Sub can seek by timestamp or snapshot; it does not expose a Kafka-style offset for each message. A returned sequence number therefore cannot promise exact-message replay. Review any consumer that persists a sequence number and later expects to resume at exactly that record. #### Consumers, retention and cutover Separate subscriptions give fan-out consumers separate copies and delivery state. Google controls subscription delivery and capacity; the Kinesis dedicated-throughput guarantee does not apply to this target. Kinesis Client Library applications still need their separate DynamoDB lease table through a compatible adapter. Pub/Sub retention is limited to the profile's stated window. Provision subscriptions before publication, test restart and replay behavior, and verify that the consumer can work without addressable shard positions. Existing AWS records and checkpoint positions are not copied. Measure adapter latency, backlog and consumer progress together; topic acceptance alone does not establish end-to-end processing speed. ### Via Managed Service for Apache Kafka | Operation | Area | Support | Depth | Notes | | -------------------------------------------------------------------------------------- | ------------------ | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Capacity mode (PROVISIONED / ON\_DEMAND) | Capacity | Partial | Common | PROVISIONED sets a fixed partition count at deployment. ON\_DEMAND also uses a fixed count on this target; the broker does not automatically scale partitions as Kinesis scales shards | | GetRecords (Limit / NextShardIterator / MillisBehindLatest) | Consume | Partial | Most usage | GetRecords maps to a broker poll from the \{shard, offset} position; NextShardIterator advances the offset and MillisBehindLatest comes from log-end lag; Kinesis's 5-calls/s-per-shard and 2 MB/s-per-shard read quotas are relaxed to the broker's own limits | | GetShardIterator (TRIM\_HORIZON / LATEST / AT\_TIMESTAMP / AT/AFTER\_SEQUENCE\_NUMBER) | Consume | Supported | Most usage | each iterator type maps to a seek: TRIM\_HORIZON to the start, LATEST to the tail, AT\_TIMESTAMP to the timestamp, AT/AFTER\_SEQUENCE\_NUMBER to the offset decoded from the sequence number; the iterator is an opaque token | | Sequence numbers | Consume | Supported | Most usage | the adapter synthesizes Kinesis-shaped sequence numbers that are per-shard monotonic and decode back to a seek position; review applications that compare sequence numbers across shards or use Kinesis Producer Library (KPL) aggregated-record sub-sequence numbers | | KCL (checkpoint via a DynamoDB lease table) | Consumer framework | Partial | Full surface | the Kinesis Client Library (KCL) uses target consumer groups for shard assignment and offset commits. It also requires a DynamoDB lease table for checkpoints; deploy the DynamoDB adapter or another compatible table alongside it | | CreateStream / DeleteStream / DescribeStream | Control plane | Supported | Common | Terraform provisions the stream and shard count; DescribeStream returns that stream configuration | | Enhanced fan-out (RegisterStreamConsumer / SubscribeToShard) | Fan-out | Partial | Full surface | each enhanced-fan-out consumer maps to its own consumer group; SubscribeToShard's server-push becomes a long-lived poll, and the dedicated 2 MB/s-per-shard-per-consumer SLA becomes broker-limited | | PutRecord (partitionKey → shard) | Ingest | Supported | Common | the adapter replicates Kinesis's own partition-key hashing (MD5 into the 128-bit hash-key ranges), so 'same partition key → same shard' holds and ExplicitHashKey is honored | | PutRecords (batch) | Ingest | Supported | Common | returns a PutRecordsResultEntry for each record in the batch | | Shard-level metrics (EnableEnhancedMonitoring, per-shard CloudWatch) | Observability | Out of scope | Full surface | Kinesis's enhanced per-shard CloudWatch metrics (per-shard IncomingBytes/Records, OutgoingBytes/Records, IteratorAgeMilliseconds) are AWS-specific; no target exposes the Kinesis-named CloudWatch series or the enhanced-monitoring toggle; the broker/topic publishes its own metrics under its own names (Kafka and Event Hubs do expose per-partition metrics), so observability moves to the target's native monitoring | | Resharding (SplitShard / MergeShards / UpdateShardCount) | Resharding | Partial | Full surface | UpdateShardCount up maps to adding partitions (Partial: it breaks the hash-range continuity Kinesis preserves across a split); SplitShard/MergeShards and reducing shard count have no analog and are out of scope | | Server-side encryption (KMS) | Security | Supported | Most usage | at-rest encryption is the target's own: the managed targets always encrypt at rest (so a request for no encryption has no representation there), while a self-hosted broker encrypts per its storage/volume configuration; a customer-managed key maps where the target offers one (CMEK on Pub/Sub and managed Kafka; tier-gated on Event Hubs; the storage layer's key on a self-hosted broker), not necessarily per-stream | | Retention | Storage | Supported | Most usage | retention maps to the topic's retention.ms/bytes; Kinesis's 24 h - 365 d range is expressible (365-day retention is a long-retention config, and the storage cost is the broker's) | #### From a shard to a target partition The application calls the Kinesis API on the Tensor9 adapter; the adapter uses Google's Managed Service for Apache Kafka for the retained record log. The mapping assigns each logical Kinesis shard to a target partition. Partition-key hashing chooses a shard, and the target partition supplies the ordered position used to construct the returned sequence number. Consumers receive an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records; obtaining an iterator at a retained position supports replay. These positions belong to the new stream. Existing AWS sequence numbers and checkpoints do not identify positions in a newly provisioned target log. #### Consumer state and capacity The retained log and the consumer's progress are separate state. Kinesis Client Library applications also use a DynamoDB table for leases and checkpoints. Deploy a compatible DynamoDB adapter with this stream and test the consumer's restart and reassignment behavior. Keeping the Kinesis endpoint alone does not provide that table. A fixed target partition count does not reproduce Kinesis split/merge history. Adding partitions changes routing for some keys; plan that change with the consumers instead of assuming existing shard positions remain valid. Enhanced fan-out uses target consumer groups, so the target's capacity replaces Kinesis's dedicated per-consumer throughput guarantee. #### Operating and moving the stream Retention is configured on the target and is bounded by the provider limits in the comparison table. Record size, partition imbalance, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with the application's record sizes and partition distribution. Provision the target stream and consumer checkpoint store before cutover. Drain the old stream, or coordinate publication to both systems while consumers catch up. The move does not copy retained AWS records. Use target partition and adapter metrics to monitor reads, writes and lag; AWS CloudWatch series do not move with the stream. ## On Google Cloud and Private Kubernetes ### Via Strimzi Kafka | Operation | Area | Support | Depth | Notes | | -------------------------------------------------------------------------------------- | ------------------ | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Capacity mode (PROVISIONED / ON\_DEMAND) | Capacity | Partial | Common | PROVISIONED sets a fixed partition count at deployment. ON\_DEMAND also uses a fixed count on this target; the broker does not automatically scale partitions as Kinesis scales shards | | GetRecords (Limit / NextShardIterator / MillisBehindLatest) | Consume | Partial | Most usage | GetRecords maps to a broker poll from the \{shard, offset} position; NextShardIterator advances the offset and MillisBehindLatest comes from log-end lag; Kinesis's 5-calls/s-per-shard and 2 MB/s-per-shard read quotas are relaxed to the broker's own limits | | GetShardIterator (TRIM\_HORIZON / LATEST / AT\_TIMESTAMP / AT/AFTER\_SEQUENCE\_NUMBER) | Consume | Supported | Most usage | each iterator type maps to a seek: TRIM\_HORIZON to the start, LATEST to the tail, AT\_TIMESTAMP to the timestamp, AT/AFTER\_SEQUENCE\_NUMBER to the offset decoded from the sequence number; the iterator is an opaque token | | Sequence numbers | Consume | Supported | Most usage | the adapter synthesizes Kinesis-shaped sequence numbers that are per-shard monotonic and decode back to a seek position; review applications that compare sequence numbers across shards or use Kinesis Producer Library (KPL) aggregated-record sub-sequence numbers | | KCL (checkpoint via a DynamoDB lease table) | Consumer framework | Partial | Full surface | the Kinesis Client Library (KCL) uses target consumer groups for shard assignment and offset commits. It also requires a DynamoDB lease table for checkpoints; deploy the DynamoDB adapter or another compatible table alongside it | | CreateStream / DeleteStream / DescribeStream | Control plane | Supported | Common | Terraform provisions the stream and shard count; DescribeStream returns that stream configuration | | Enhanced fan-out (RegisterStreamConsumer / SubscribeToShard) | Fan-out | Partial | Full surface | each enhanced-fan-out consumer maps to its own consumer group; SubscribeToShard's server-push becomes a long-lived poll, and the dedicated 2 MB/s-per-shard-per-consumer SLA becomes broker-limited | | PutRecord (partitionKey → shard) | Ingest | Supported | Common | the adapter replicates Kinesis's own partition-key hashing (MD5 into the 128-bit hash-key ranges), so 'same partition key → same shard' holds and ExplicitHashKey is honored | | PutRecords (batch) | Ingest | Supported | Common | returns a PutRecordsResultEntry for each record in the batch | | Shard-level metrics (EnableEnhancedMonitoring, per-shard CloudWatch) | Observability | Out of scope | Full surface | Kinesis's enhanced per-shard CloudWatch metrics (per-shard IncomingBytes/Records, OutgoingBytes/Records, IteratorAgeMilliseconds) are AWS-specific; no target exposes the Kinesis-named CloudWatch series or the enhanced-monitoring toggle; the broker/topic publishes its own metrics under its own names (Kafka and Event Hubs do expose per-partition metrics), so observability moves to the target's native monitoring | | Resharding (SplitShard / MergeShards / UpdateShardCount) | Resharding | Partial | Full surface | UpdateShardCount up maps to adding partitions (Partial: it breaks the hash-range continuity Kinesis preserves across a split); SplitShard/MergeShards and reducing shard count have no analog and are out of scope | | Server-side encryption (KMS) | Security | Supported | Most usage | at-rest encryption is the target's own: the managed targets always encrypt at rest (so a request for no encryption has no representation there), while a self-hosted broker encrypts per its storage/volume configuration; a customer-managed key maps where the target offers one (CMEK on Pub/Sub and managed Kafka; tier-gated on Event Hubs; the storage layer's key on a self-hosted broker), not necessarily per-stream | | Retention | Storage | Supported | Most usage | retention maps to the topic's retention.ms/bytes; Kinesis's 24 h - 365 d range is expressible (365-day retention is a long-retention config, and the storage cost is the broker's) | #### From a shard to a target partition The application calls the Kinesis API on the Tensor9 adapter; the adapter uses Apache Kafka (Strimzi) on the target cluster for the retained record log. The mapping assigns each logical Kinesis shard to a target partition. Partition-key hashing chooses a shard, and the target partition supplies the ordered position used to construct the returned sequence number. Consumers receive an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records; obtaining an iterator at a retained position supports replay. These positions belong to the new stream. Existing AWS sequence numbers and checkpoints do not identify positions in a newly provisioned target log. #### Consumer state and capacity The retained log and the consumer's progress are separate state. Kinesis Client Library applications also use a DynamoDB table for leases and checkpoints. Deploy a compatible DynamoDB adapter with this stream and test the consumer's restart and reassignment behavior. Keeping the Kinesis endpoint alone does not provide that table. A fixed target partition count does not reproduce Kinesis split/merge history. Adding partitions changes routing for some keys; plan that change with the consumers instead of assuming existing shard positions remain valid. Enhanced fan-out uses target consumer groups, so the target's capacity replaces Kinesis's dedicated per-consumer throughput guarantee. #### Operating and moving the stream Retention is configured on the target and is bounded by the provider limits in the comparison table. Record size, partition imbalance, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with the application's record sizes and partition distribution. Provision the target stream and consumer checkpoint store before cutover. Drain the old stream, or coordinate publication to both systems while consumers catch up. The move does not copy retained AWS records. Use target partition and adapter metrics to monitor reads, writes and lag; AWS CloudWatch series do not move with the stream. ## On Azure | Operation | Area | Support | Depth | Notes | | -------------------------------------------------------------------------------------- | ------------------ | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Capacity mode (PROVISIONED / ON\_DEMAND) | Capacity | Partial | Common | PROVISIONED sets a fixed partition count at deployment. ON\_DEMAND also uses a fixed count on this target; the broker does not automatically scale partitions as Kinesis scales shards | | GetRecords (Limit / NextShardIterator / MillisBehindLatest) | Consume | Partial | Most usage | GetRecords maps to a broker poll from the \{shard, offset} position; NextShardIterator advances the offset and MillisBehindLatest comes from log-end lag; Kinesis's 5-calls/s-per-shard and 2 MB/s-per-shard read quotas are relaxed to the broker's own limits | | GetShardIterator (TRIM\_HORIZON / LATEST / AT\_TIMESTAMP / AT/AFTER\_SEQUENCE\_NUMBER) | Consume | Supported | Most usage | each iterator type maps to a seek: TRIM\_HORIZON to the start, LATEST to the tail, AT\_TIMESTAMP to the timestamp, AT/AFTER\_SEQUENCE\_NUMBER to the offset decoded from the sequence number; the iterator is an opaque token | | Sequence numbers | Consume | Supported | Most usage | the adapter synthesizes Kinesis-shaped sequence numbers that are per-shard monotonic and decode back to a seek position; review applications that compare sequence numbers across shards or use Kinesis Producer Library (KPL) aggregated-record sub-sequence numbers | | KCL (checkpoint via a DynamoDB lease table) | Consumer framework | Partial | Full surface | the Kinesis Client Library (KCL) uses target consumer groups for shard assignment and offset commits. It also requires a DynamoDB lease table for checkpoints; deploy the DynamoDB adapter or another compatible table alongside it | | CreateStream / DeleteStream / DescribeStream | Control plane | Supported | Common | Terraform provisions the stream and shard count; DescribeStream returns that stream configuration | | Enhanced fan-out (RegisterStreamConsumer / SubscribeToShard) | Fan-out | Partial | Full surface | each enhanced-fan-out consumer maps to its own consumer group; SubscribeToShard's server-push becomes a long-lived poll, and the dedicated 2 MB/s-per-shard-per-consumer SLA becomes broker-limited | | PutRecord (partitionKey → shard) | Ingest | Supported | Common | the adapter replicates Kinesis's own partition-key hashing (MD5 into the 128-bit hash-key ranges), so 'same partition key → same shard' holds and ExplicitHashKey is honored | | PutRecords (batch) | Ingest | Supported | Common | returns a PutRecordsResultEntry for each record in the batch | | Shard-level metrics (EnableEnhancedMonitoring, per-shard CloudWatch) | Observability | Out of scope | Full surface | Kinesis's enhanced per-shard CloudWatch metrics (per-shard IncomingBytes/Records, OutgoingBytes/Records, IteratorAgeMilliseconds) are AWS-specific; no target exposes the Kinesis-named CloudWatch series or the enhanced-monitoring toggle; the broker/topic publishes its own metrics under its own names (Kafka and Event Hubs do expose per-partition metrics), so observability moves to the target's native monitoring | | Resharding (SplitShard / MergeShards / UpdateShardCount) | Resharding | Partial | Full surface | UpdateShardCount up maps to adding partitions (Partial: it breaks the hash-range continuity Kinesis preserves across a split); SplitShard/MergeShards and reducing shard count have no analog and are out of scope | | Server-side encryption (KMS) | Security | Supported | Most usage | at-rest encryption is the target's own: the managed targets always encrypt at rest (so a request for no encryption has no representation there), while a self-hosted broker encrypts per its storage/volume configuration; a customer-managed key maps where the target offers one (CMEK on Pub/Sub and managed Kafka; tier-gated on Event Hubs; the storage layer's key on a self-hosted broker), not necessarily per-stream | | Retention | Storage | Supported | Most usage | retention maps to Event Hubs's own retention; the Kinesis 365-day ceiling is capped: Event Hubs retains up to \~90 days (Premium/Dedicated), so a workload relying on multi-month replay needs review for this target | #### From a shard to a target partition The application calls the Kinesis API on the Tensor9 adapter; the adapter uses Azure Event Hubs for the retained record log. The mapping assigns each logical Kinesis shard to a target partition. Partition-key hashing chooses a shard, and the target partition supplies the ordered position used to construct the returned sequence number. Consumers receive an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records; obtaining an iterator at a retained position supports replay. These positions belong to the new stream. Existing AWS sequence numbers and checkpoints do not identify positions in a newly provisioned target log. #### Consumer state and capacity The retained log and the consumer's progress are separate state. Kinesis Client Library applications also use a DynamoDB table for leases and checkpoints. Deploy a compatible DynamoDB adapter with this stream and test the consumer's restart and reassignment behavior. Keeping the Kinesis endpoint alone does not provide that table. A fixed target partition count does not reproduce Kinesis split/merge history. Adding partitions changes routing for some keys; plan that change with the consumers instead of assuming existing shard positions remain valid. Enhanced fan-out uses target consumer groups, so the target's capacity replaces Kinesis's dedicated per-consumer throughput guarantee. #### Operating and moving the stream Retention is configured on the target and is bounded by the provider limits in the comparison table. Record size, partition imbalance, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with the application's record sizes and partition distribution. Provision the target stream and consumer checkpoint store before cutover. Drain the old stream, or coordinate publication to both systems while consumers catch up. The move does not copy retained AWS records. Use target partition and adapter metrics to monitor reads, writes and lag; AWS CloudWatch series do not move with the stream. ## On OCI | Operation | Area | Support | Depth | Notes | | -------------------------------------------------------------------------------------- | ------------------ | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Capacity mode (PROVISIONED / ON\_DEMAND) | Capacity | Partial | Common | PROVISIONED sets a fixed partition count at deployment. ON\_DEMAND also uses a fixed count on this target; the broker does not automatically scale partitions as Kinesis scales shards | | GetRecords (Limit / NextShardIterator / MillisBehindLatest) | Consume | Partial | Most usage | GetRecords maps to a broker poll from the \{shard, offset} position; NextShardIterator advances the offset and MillisBehindLatest comes from log-end lag; Kinesis's 5-calls/s-per-shard and 2 MB/s-per-shard read quotas are relaxed to the broker's own limits | | GetShardIterator (TRIM\_HORIZON / LATEST / AT\_TIMESTAMP / AT/AFTER\_SEQUENCE\_NUMBER) | Consume | Supported | Most usage | each iterator type maps to a seek: TRIM\_HORIZON to the start, LATEST to the tail, AT\_TIMESTAMP to the timestamp, AT/AFTER\_SEQUENCE\_NUMBER to the offset decoded from the sequence number; the iterator is an opaque token | | Sequence numbers | Consume | Supported | Most usage | the adapter synthesizes Kinesis-shaped sequence numbers that are per-shard monotonic and decode back to a seek position; review applications that compare sequence numbers across shards or use Kinesis Producer Library (KPL) aggregated-record sub-sequence numbers | | KCL (checkpoint via a DynamoDB lease table) | Consumer framework | Partial | Full surface | the Kinesis Client Library (KCL) uses target consumer groups for shard assignment and offset commits. It also requires a DynamoDB lease table for checkpoints; deploy the DynamoDB adapter or another compatible table alongside it | | CreateStream / DeleteStream / DescribeStream | Control plane | Supported | Common | Terraform provisions the stream and shard count; DescribeStream returns that stream configuration | | Enhanced fan-out (RegisterStreamConsumer / SubscribeToShard) | Fan-out | Partial | Full surface | each enhanced-fan-out consumer maps to its own consumer group; SubscribeToShard's server-push becomes a long-lived poll, and the dedicated 2 MB/s-per-shard-per-consumer SLA becomes broker-limited | | PutRecord (partitionKey → shard) | Ingest | Supported | Common | the adapter replicates Kinesis's own partition-key hashing (MD5 into the 128-bit hash-key ranges), so 'same partition key → same shard' holds and ExplicitHashKey is honored | | PutRecords (batch) | Ingest | Supported | Common | returns a PutRecordsResultEntry for each record in the batch | | Shard-level metrics (EnableEnhancedMonitoring, per-shard CloudWatch) | Observability | Out of scope | Full surface | Kinesis's enhanced per-shard CloudWatch metrics (per-shard IncomingBytes/Records, OutgoingBytes/Records, IteratorAgeMilliseconds) are AWS-specific; no target exposes the Kinesis-named CloudWatch series or the enhanced-monitoring toggle; the broker/topic publishes its own metrics under its own names (Kafka and Event Hubs do expose per-partition metrics), so observability moves to the target's native monitoring | | Resharding (SplitShard / MergeShards / UpdateShardCount) | Resharding | Partial | Full surface | UpdateShardCount up maps to adding partitions (Partial: it breaks the hash-range continuity Kinesis preserves across a split); SplitShard/MergeShards and reducing shard count have no analog and are out of scope | | Server-side encryption (KMS) | Security | Supported | Most usage | at-rest encryption is the target's own: the managed targets always encrypt at rest (so a request for no encryption has no representation there), while a self-hosted broker encrypts per its storage/volume configuration; a customer-managed key maps where the target offers one (CMEK on Pub/Sub and managed Kafka; tier-gated on Event Hubs; the storage layer's key on a self-hosted broker), not necessarily per-stream | | Retention | Storage | Supported | Most usage | retention maps to OCI Streaming's own retention window, under OCI quotas; multi-month replay beyond OCI's ceiling needs review for this target | #### From a shard to a target partition The application calls the Kinesis API on the Tensor9 adapter; the adapter uses OCI Streaming for the retained record log. The mapping assigns each logical Kinesis shard to a target partition. Partition-key hashing chooses a shard, and the target partition supplies the ordered position used to construct the returned sequence number. Consumers receive an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records; obtaining an iterator at a retained position supports replay. These positions belong to the new stream. Existing AWS sequence numbers and checkpoints do not identify positions in a newly provisioned target log. #### Consumer state and capacity The retained log and the consumer's progress are separate state. Kinesis Client Library applications also use a DynamoDB table for leases and checkpoints. Deploy a compatible DynamoDB adapter with this stream and test the consumer's restart and reassignment behavior. Keeping the Kinesis endpoint alone does not provide that table. A fixed target partition count does not reproduce Kinesis split/merge history. Adding partitions changes routing for some keys; plan that change with the consumers instead of assuming existing shard positions remain valid. Enhanced fan-out uses target consumer groups, so the target's capacity replaces Kinesis's dedicated per-consumer throughput guarantee. #### Operating and moving the stream Retention is configured on the target and is bounded by the provider limits in the comparison table. Record size, partition imbalance, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with the application's record sizes and partition distribution. Provision the target stream and consumer checkpoint store before cutover. Drain the old stream, or coordinate publication to both systems while consumers catch up. The move does not copy retained AWS records. Use target partition and adapter metrics to monitor reads, writes and lag; AWS CloudWatch series do not move with the stream. [Service Catalog](/service-adapters/catalog).