> ## 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 Data Stream

> Kinesis Data Stream APIs with Cloud Adapter.

Preview

This page describes how Kinesis Data Stream maps to services in the environment where the application runs, including backend choices, supported operations and service-specific behavior.

## Supported environments

* Akamai
* Azure
* DigitalOcean
* Google Cloud
* OCI
* Private Kubernetes
* Scaleway

Check the operation and capability tables for the behavior your application depends on. A supported environment does not imply that every operation of the origin service is available.

## How the backends compare

Each row compares a capability of Kinesis Data Stream with its adaptation on each backend.
A dash means this profile does not state the capability for that backend.

### Cloud Adapter

#### Runtime surface

| Capability | Kinesis Data Stream | Akamai, DigitalOcean, Google Cloud, Private Kubernetes, and Scaleway · Strimzi Kafka | Azure | DigitalOcean · DigitalOcean Managed Kafka | Google Cloud · Pub/Sub | Google Cloud · Managed Service for Apache Kafka | OCI |
| - | - | - | - | - | - | - | - |
| Ordered ingest · partition key → shard | shard (hash-key ranges) | 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) | 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) |
| Sequence numbers · replay position | native | 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 | 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 |
| KCL checkpointing · consumer position | DynamoDB lease table | backend consumer-group offsets + a co-deployed DynamoDB adapter for the lease table | backend consumer-group offsets + a co-deployed DynamoDB adapter for the lease table | backend consumer-group offsets + a co-deployed DynamoDB adapter for the lease table | Pub/Sub subscription acks (not consumer-group offsets) + a co-deployed DynamoDB adapter for the KCL lease table | backend consumer-group offsets + a co-deployed DynamoDB adapter for the lease table | backend consumer-group offsets + a co-deployed DynamoDB adapter for the lease table |
| Retention | 24 h - 365 d | 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 | the managed broker's retention.ms (storage-bounded) | 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) | OCI Streaming's managed retention window (under OCI quotas) |
| Resharding | Yes | 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 | 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 |
| Enhanced fan-out | Yes | 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 | 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 |
| API coverage | full | high | high | high | high | high | high |

#### Limits

| Capability | Kinesis Data Stream | Akamai, DigitalOcean, Google Cloud, Private Kubernetes, and Scaleway · Strimzi Kafka | Azure | DigitalOcean · DigitalOcean Managed Kafka | Google Cloud · Pub/Sub | Google Cloud · Managed Service for Apache Kafka | OCI |
| - | - | - | - | - | - | - | - |
| Capacity mode · PROVISIONED / ON\_DEMAND | Yes | 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 - 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 |

## On Akamai, DigitalOcean, Google Cloud, Private Kubernetes, and Scaleway

### 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 backend; 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 backend 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 backend 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 backend'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 backend's own: the managed backends 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 backend 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) |

#### How it works

Your application keeps calling the Kinesis API, now on the Tensor9 adapter, and the adapter stores the record log on Apache Kafka (Strimzi) on the target cluster. Each Kinesis shard maps to a partition there. Partition-key hashing chooses the shard, and the partition's ordered position becomes part of the sequence number the call returns.

Consumers get an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records, and getting an iterator at a retained position lets you replay. These positions belong to the new stream: existing AWS sequence numbers and checkpoints do not point at anything in the new log.

#### Consumer state and capacity

The record log and each consumer's progress are kept separately. Kinesis Client Library (KCL) applications also keep leases and checkpoints in a DynamoDB table. Deploy a compatible DynamoDB adapter with this stream and test how the consumer restarts and reassigns shards; keeping the Kinesis endpoint alone does not provide that table.

Retention is set on Apache Kafka (Strimzi) on the target cluster and is limited by the provider's limits in the comparison table. Record size, uneven partitions, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with your own record sizes and partition distribution.

#### Limitations

* **Shard split and merge history is not supported.** The partition count is fixed. Adding partitions changes routing for some keys, so plan that change with your consumers instead of assuming existing shard positions stay valid. - **Enhanced fan-out behaves differently: there is no dedicated throughput per consumer.** It uses consumer groups on Apache Kafka (Strimzi) on the target cluster, so that service's capacity applies instead of Kinesis's per-consumer guarantee. - **Moving AWS records, sequence numbers and checkpoints is not supported.** The new stream starts empty, and old positions do not identify records in it.

#### Other considerations

**Before cutover.** Create the stream and the consumer checkpoint store first. Drain the old stream, or publish to both while consumers catch up.

**What to monitor.** Use Apache Kafka (Strimzi) on the target cluster partition metrics and adapter metrics to watch reads, writes and lag; AWS CloudWatch series do not move with the stream.

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### Kinesis Data Streams · PUT payload units

Feature: Kinesis Data Streams.

Estimated monthly service charges by PUT payload units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Kinesis Data Streams · PUT payload units: monthly service charges by PUT payload units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/6ef36ef1f2d1c23b5ed94579acb08be862af6da5256fd33a1d629693e6c941c3-light.svg)

![Kinesis Data Streams · PUT payload units: monthly service charges by PUT payload units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/247cf442203083d76e8906dd79dc4113dd238b3b4c517a6387246ae05cccde05-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| PUT payload units (per second) | Kinesis Data Stream | Target scenario | Strimzi Kafka | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Strimzi Kafka (one copy) | 80.90 | 80.90 |
| 0 | 0.00 | Strimzi Kafka (two copies) | 161.79 | 161.79 |
| 1 | 0.04 | Strimzi Kafka (one copy) | 80.90 | 80.86 |
| 1 | 0.04 | Strimzi Kafka (two copies) | 161.79 | 161.76 |
| 10 | 0.37 | Strimzi Kafka (one copy) | 80.90 | 80.53 |
| 10 | 0.37 | Strimzi Kafka (two copies) | 161.79 | 161.42 |
| 100 | 3.68 | Strimzi Kafka (one copy) | 80.90 | 77.22 |
| 100 | 3.68 | Strimzi Kafka (two copies) | 161.79 | 158.11 |
| 1,000 | 36.79 | Strimzi Kafka (one copy) | 87.49 | 50.70 |
| 1,000 | 36.79 | Strimzi Kafka (two copies) | 174.98 | 138.19 |
| 10,000 | 367.92 | Strimzi Kafka (one copy) | 752.63 | 384.71 |
| 10,000 | 367.92 | Strimzi Kafka (two copies) | 1,505.26 | 1,137.34 |

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 16 vCPU, 87.75 GiB memory and 1,120 GiB SSD at 10,000 per second.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| Strimzi Kafka (one copy) | Origin list price · Provisioned shard-hours | 0.015 | USD/shard-hour |
| Strimzi Kafka (one copy) | Origin list price · PUT payload units | 0.000000014 | USD/25-KiB record units |
| Strimzi Kafka (one copy) | Representative record size | 1,024 | bytes |
| Strimzi Kafka (one copy) | Full-stream consumer copies | 1 | copies |
| Strimzi Kafka (one copy) | Target retained history | 24 | hours |
| Strimzi Kafka (one copy) | Target record envelope | 64 | bytes/record |
| Strimzi Kafka (one copy) | Target price guess · read | 0 | USD/read |
| Strimzi Kafka (one copy) | Target price guess · write | 0 | USD/write |
| Strimzi Kafka (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| Strimzi Kafka (one copy) | Target list price · GiB-month | 0.1 | USD/GiB-month |
| Strimzi Kafka (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Strimzi Kafka (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Strimzi Kafka (one copy) | Target list price · network GiB | 0.12 | USD/network GiB |
| Strimzi Kafka (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Strimzi Kafka (one copy) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| Strimzi Kafka (one copy) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| Strimzi Kafka (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Strimzi Kafka (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Strimzi Kafka (one copy) | Target price guess · input token | 0 | USD/input token |
| Strimzi Kafka (one copy) | Target price guess · output token | 0 | USD/output token |
| Strimzi Kafka (one copy) | Target monthly base charge | 0 | USD/month |
| Strimzi Kafka (one copy) | Approximate target service minimum | 0 | USD/month |
| Strimzi Kafka (one copy) | Minimum primary CPU | 2 | vCPU |
| Strimzi Kafka (one copy) | Minimum primary RAM | 8 | GiB |
| Strimzi Kafka (one copy) | Minimum primary disk | 100 | GiB |
| Strimzi Kafka (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Strimzi Kafka (one copy) | Allocated share of provisioned cost | 1 | fraction |
| Strimzi Kafka (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Strimzi Kafka (one copy) | Planning peak / mean work | 2 | multiplier |
| Strimzi Kafka (one copy) | Planning primary CPU utilization | 0.5 | fraction |
| Strimzi Kafka (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| Strimzi Kafka (one copy) | Planning disk utilization | 0.8 | fraction |
| Strimzi Kafka (one copy) | Maintenance and log disk reserve | 20 | GiB |
| Strimzi Kafka (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Strimzi Kafka (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Strimzi Kafka (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Strimzi Kafka (one copy) | Broker write-equivalent throughput per vCPU | 20 | MiB/vCPU-second |
| Strimzi Kafka (one copy) | Broker replicas per written byte | 3 | replicas |
| Strimzi Kafka (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Strimzi Kafka (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Strimzi Kafka (two copies) | Origin list price · Provisioned shard-hours | 0.015 | USD/shard-hour |
| Strimzi Kafka (two copies) | Origin list price · PUT payload units | 0.000000014 | USD/25-KiB record units |
| Strimzi Kafka (two copies) | Representative record size | 1,024 | bytes |
| Strimzi Kafka (two copies) | Full-stream consumer copies | 1 | copies |
| Strimzi Kafka (two copies) | Target retained history | 24 | hours |
| Strimzi Kafka (two copies) | Target record envelope | 64 | bytes/record |
| Strimzi Kafka (two copies) | Target price guess · read | 0 | USD/read |
| Strimzi Kafka (two copies) | Target price guess · write | 0 | USD/write |
| Strimzi Kafka (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| Strimzi Kafka (two copies) | Target list price · GiB-month | 0.1 | USD/GiB-month |
| Strimzi Kafka (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Strimzi Kafka (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Strimzi Kafka (two copies) | Target list price · network GiB | 0.12 | USD/network GiB |
| Strimzi Kafka (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Strimzi Kafka (two copies) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| Strimzi Kafka (two copies) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| Strimzi Kafka (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Strimzi Kafka (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Strimzi Kafka (two copies) | Target price guess · input token | 0 | USD/input token |
| Strimzi Kafka (two copies) | Target price guess · output token | 0 | USD/output token |
| Strimzi Kafka (two copies) | Target monthly base charge | 0 | USD/month |
| Strimzi Kafka (two copies) | Approximate target service minimum | 0 | USD/month |
| Strimzi Kafka (two copies) | Minimum primary CPU | 2 | vCPU |
| Strimzi Kafka (two copies) | Minimum primary RAM | 8 | GiB |
| Strimzi Kafka (two copies) | Minimum primary disk | 100 | GiB |
| Strimzi Kafka (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Strimzi Kafka (two copies) | Allocated share of provisioned cost | 1 | fraction |
| Strimzi Kafka (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Strimzi Kafka (two copies) | Planning peak / mean work | 2 | multiplier |
| Strimzi Kafka (two copies) | Planning primary CPU utilization | 0.5 | fraction |
| Strimzi Kafka (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| Strimzi Kafka (two copies) | Planning disk utilization | 0.8 | fraction |
| Strimzi Kafka (two copies) | Maintenance and log disk reserve | 20 | GiB |
| Strimzi Kafka (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Strimzi Kafka (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Strimzi Kafka (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Strimzi Kafka (two copies) | Broker write-equivalent throughput per vCPU | 20 | MiB/vCPU-second |
| Strimzi Kafka (two copies) | Broker replicas per written byte | 3 | replicas |
| Strimzi Kafka (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Strimzi Kafka (two copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Payload size determines physical record and byte throughput. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
* A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
* Self-hosted target: Strimzi and Apache Kafka (Apache-2.0, [https://github.com/strimzi/strimzi-kafka-operator/blob/main/LICENSE](https://github.com/strimzi/strimzi-kafka-operator/blob/main/LICENSE)); Kafka replication multiplies disk beyond the copies this model bills. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer's Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* Broker CPU follows write-equivalent bytes; the row-store operations coefficient is not applied.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AmazonKinesis offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json)
* Compute Engine general-purpose machine pricing: [https://cloud.google.com/products/compute/pricing/general-purpose](https://cloud.google.com/products/compute/pricing/general-purpose)
* Disk and image pricing: [https://cloud.google.com/compute/disks-image-pricing](https://cloud.google.com/compute/disks-image-pricing)
* Network pricing: [https://cloud.google.com/vpc/network-pricing](https://cloud.google.com/vpc/network-pricing)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-345e11fb79eca5767bb2e6fcf2891ab45eff792c` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AmazonKinesis offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json), [Compute Engine general-purpose machine pricing](https://cloud.google.com/products/compute/pricing/general-purpose), [Disk and image pricing](https://cloud.google.com/compute/disks-image-pricing), [Network pricing](https://cloud.google.com/vpc/network-pricing).

##### Kinesis Data Streams · Origin provisioned shards

Feature: Kinesis Data Streams.

Estimated monthly service charges by Origin provisioned shards. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Kinesis Data Streams · Origin provisioned shards: monthly service charges by Origin provisioned shards. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/21977c8732aa9d456cee9f91a99496a9af3c31db4984bdc3d69f72be33f7932a-light.svg)

![Kinesis Data Streams · Origin provisioned shards: monthly service charges by Origin provisioned shards. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/7425fbdf8e201783592cc57482b8ba8ba65acea446e718001b13296ef015390d-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| Origin provisioned shards (shard-hours/month) | Kinesis Data Stream | Target scenario | Strimzi Kafka | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Strimzi Kafka (one copy) | 80.90 | 80.90 |
| 0 | 0.00 | Strimzi Kafka (two copies) | 161.79 | 161.79 |
| 730 | 10.95 | Strimzi Kafka (one copy) | 80.90 | 69.95 |
| 730 | 10.95 | Strimzi Kafka (two copies) | 161.79 | 150.84 |
| 7,300 | 109.50 | Strimzi Kafka (one copy) | 80.90 | -28.60 |
| 7,300 | 109.50 | Strimzi Kafka (two copies) | 161.79 | 52.29 |
| 73,000 | 1,095.00 | Strimzi Kafka (one copy) | 80.90 | -1,014.10 |
| 73,000 | 1,095.00 | Strimzi Kafka (two copies) | 161.79 | -933.21 |
| 730,000 | 10,950.00 | Strimzi Kafka (one copy) | 80.90 | -10,869.10 |
| 730,000 | 10,950.00 | Strimzi Kafka (two copies) | 161.79 | -10,788.21 |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| Strimzi Kafka (one copy) | Origin list price · Provisioned shard-hours | 0.015 | USD/shard-hour |
| Strimzi Kafka (one copy) | Origin list price · PUT payload units | 0.000000014 | USD/25-KiB record units |
| Strimzi Kafka (one copy) | Representative record size | 1,024 | bytes |
| Strimzi Kafka (one copy) | Full-stream consumer copies | 1 | copies |
| Strimzi Kafka (one copy) | Target retained history | 24 | hours |
| Strimzi Kafka (one copy) | Target record envelope | 64 | bytes/record |
| Strimzi Kafka (one copy) | Target price guess · read | 0 | USD/read |
| Strimzi Kafka (one copy) | Target price guess · write | 0 | USD/write |
| Strimzi Kafka (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| Strimzi Kafka (one copy) | Target list price · GiB-month | 0.1 | USD/GiB-month |
| Strimzi Kafka (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Strimzi Kafka (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Strimzi Kafka (one copy) | Target list price · network GiB | 0.12 | USD/network GiB |
| Strimzi Kafka (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Strimzi Kafka (one copy) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| Strimzi Kafka (one copy) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| Strimzi Kafka (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Strimzi Kafka (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Strimzi Kafka (one copy) | Target price guess · input token | 0 | USD/input token |
| Strimzi Kafka (one copy) | Target price guess · output token | 0 | USD/output token |
| Strimzi Kafka (one copy) | Target monthly base charge | 0 | USD/month |
| Strimzi Kafka (one copy) | Approximate target service minimum | 0 | USD/month |
| Strimzi Kafka (one copy) | Minimum primary CPU | 2 | vCPU |
| Strimzi Kafka (one copy) | Minimum primary RAM | 8 | GiB |
| Strimzi Kafka (one copy) | Minimum primary disk | 100 | GiB |
| Strimzi Kafka (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Strimzi Kafka (one copy) | Allocated share of provisioned cost | 1 | fraction |
| Strimzi Kafka (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Strimzi Kafka (one copy) | Planning peak / mean work | 2 | multiplier |
| Strimzi Kafka (one copy) | Planning primary CPU utilization | 0.5 | fraction |
| Strimzi Kafka (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| Strimzi Kafka (one copy) | Planning disk utilization | 0.8 | fraction |
| Strimzi Kafka (one copy) | Maintenance and log disk reserve | 20 | GiB |
| Strimzi Kafka (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Strimzi Kafka (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Strimzi Kafka (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Strimzi Kafka (one copy) | Broker write-equivalent throughput per vCPU | 20 | MiB/vCPU-second |
| Strimzi Kafka (one copy) | Broker replicas per written byte | 3 | replicas |
| Strimzi Kafka (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Strimzi Kafka (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Strimzi Kafka (two copies) | Origin list price · Provisioned shard-hours | 0.015 | USD/shard-hour |
| Strimzi Kafka (two copies) | Origin list price · PUT payload units | 0.000000014 | USD/25-KiB record units |
| Strimzi Kafka (two copies) | Representative record size | 1,024 | bytes |
| Strimzi Kafka (two copies) | Full-stream consumer copies | 1 | copies |
| Strimzi Kafka (two copies) | Target retained history | 24 | hours |
| Strimzi Kafka (two copies) | Target record envelope | 64 | bytes/record |
| Strimzi Kafka (two copies) | Target price guess · read | 0 | USD/read |
| Strimzi Kafka (two copies) | Target price guess · write | 0 | USD/write |
| Strimzi Kafka (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| Strimzi Kafka (two copies) | Target list price · GiB-month | 0.1 | USD/GiB-month |
| Strimzi Kafka (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Strimzi Kafka (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Strimzi Kafka (two copies) | Target list price · network GiB | 0.12 | USD/network GiB |
| Strimzi Kafka (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Strimzi Kafka (two copies) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| Strimzi Kafka (two copies) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| Strimzi Kafka (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Strimzi Kafka (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Strimzi Kafka (two copies) | Target price guess · input token | 0 | USD/input token |
| Strimzi Kafka (two copies) | Target price guess · output token | 0 | USD/output token |
| Strimzi Kafka (two copies) | Target monthly base charge | 0 | USD/month |
| Strimzi Kafka (two copies) | Approximate target service minimum | 0 | USD/month |
| Strimzi Kafka (two copies) | Minimum primary CPU | 2 | vCPU |
| Strimzi Kafka (two copies) | Minimum primary RAM | 8 | GiB |
| Strimzi Kafka (two copies) | Minimum primary disk | 100 | GiB |
| Strimzi Kafka (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Strimzi Kafka (two copies) | Allocated share of provisioned cost | 1 | fraction |
| Strimzi Kafka (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Strimzi Kafka (two copies) | Planning peak / mean work | 2 | multiplier |
| Strimzi Kafka (two copies) | Planning primary CPU utilization | 0.5 | fraction |
| Strimzi Kafka (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| Strimzi Kafka (two copies) | Planning disk utilization | 0.8 | fraction |
| Strimzi Kafka (two copies) | Maintenance and log disk reserve | 20 | GiB |
| Strimzi Kafka (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Strimzi Kafka (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Strimzi Kafka (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Strimzi Kafka (two copies) | Broker write-equivalent throughput per vCPU | 20 | MiB/vCPU-second |
| Strimzi Kafka (two copies) | Broker replicas per written byte | 3 | replicas |
| Strimzi Kafka (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Strimzi Kafka (two copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Provisioned capacity alone does not reveal actual record traffic; PUT meter stays independent. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
* A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
* Self-hosted target: Strimzi and Apache Kafka (Apache-2.0, [https://github.com/strimzi/strimzi-kafka-operator/blob/main/LICENSE](https://github.com/strimzi/strimzi-kafka-operator/blob/main/LICENSE)); Kafka replication multiplies disk beyond the copies this model bills. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer's Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* Broker CPU follows write-equivalent bytes; the row-store operations coefficient is not applied.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AmazonKinesis offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json)
* Compute Engine general-purpose machine pricing: [https://cloud.google.com/products/compute/pricing/general-purpose](https://cloud.google.com/products/compute/pricing/general-purpose)
* Disk and image pricing: [https://cloud.google.com/compute/disks-image-pricing](https://cloud.google.com/compute/disks-image-pricing)
* Network pricing: [https://cloud.google.com/vpc/network-pricing](https://cloud.google.com/vpc/network-pricing)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-345e11fb79eca5767bb2e6fcf2891ab45eff792c` / `2026-10-22.planning.2`. Curve: `workload-2`.

Sources: [AWS Price List API, AmazonKinesis offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json), [Compute Engine general-purpose machine pricing](https://cloud.google.com/products/compute/pricing/general-purpose), [Disk and image pricing](https://cloud.google.com/compute/disks-image-pricing), [Network pricing](https://cloud.google.com/vpc/network-pricing).

**Kinesis Data Streams → Strimzi Kafka: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Provisioned shard-hours | 0.00 |
| Origin: PUT payload units | 0.00 |
| Target: Provisioned primary CPU | 46.15 |
| Target: Provisioned primary RAM | 24.74 |
| Target: Provisioned primary disk | 10.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent provisioned resources | 0.00 |
| Target: Independent managed resources | 0.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **80.90** |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario.

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Provisioned shard-hours | 0.015 | USD/shard-hour |
| Origin list price · PUT payload units | 0.000000014 | USD/25-KiB record units |
| Representative record size | 1,024 | bytes |
| Full-stream consumer copies | 1 | copies |
| Target retained history | 24 | hours |
| Target record envelope | 64 | bytes/record |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target list price · GiB-month | 0.1 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target list price · network GiB | 0.12 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.5 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Broker write-equivalent throughput per vCPU | 20 | MiB/vCPU-second |
| Broker replicas per written byte | 3 | replicas |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Provisioned shard-hours | 0 | shard-hour |
| PUT payload units | 0 | 25-KiB record units |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.

* A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.

* Self-hosted target: Strimzi and Apache Kafka (Apache-2.0, [https://github.com/strimzi/strimzi-kafka-operator/blob/main/LICENSE](https://github.com/strimzi/strimzi-kafka-operator/blob/main/LICENSE)); Kafka replication multiplies disk beyond the copies this model bills. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer's Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.

* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.

* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.

* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.

* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.

* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.

* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).

* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.

* Broker CPU follows write-equivalent bytes; the row-store operations coefficient is not applied.

* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: `plan-345e11fb79eca5767bb2e6fcf2891ab45eff792c` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AmazonKinesis offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json), [Compute Engine general-purpose machine pricing](https://cloud.google.com/products/compute/pricing/general-purpose), [Disk and image pricing](https://cloud.google.com/compute/disks-image-pricing), [Network pricing](https://cloud.google.com/vpc/network-pricing).

## On Azure

### Azure Event Hubs

| 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 backend; 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 backend 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 backend 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 backend'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 backend's own: the managed backends 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 backend 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 backend |

#### How it works

Your application keeps calling the Kinesis API, now on the Tensor9 adapter, and the adapter stores the record log on Azure Event Hubs. Each Kinesis shard maps to a partition there. Partition-key hashing chooses the shard, and the partition's ordered position becomes part of the sequence number the call returns.

Consumers get an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records, and getting an iterator at a retained position lets you replay. These positions belong to the new stream: existing AWS sequence numbers and checkpoints do not point at anything in the new log.

#### Consumer state and capacity

The record log and each consumer's progress are kept separately. Kinesis Client Library (KCL) applications also keep leases and checkpoints in a DynamoDB table. Deploy a compatible DynamoDB adapter with this stream and test how the consumer restarts and reassigns shards; keeping the Kinesis endpoint alone does not provide that table.

Retention is set on Azure Event Hubs and is limited by the provider's limits in the comparison table. Record size, uneven partitions, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with your own record sizes and partition distribution.

#### Limitations

* **Shard split and merge history is not supported.** The partition count is fixed. Adding partitions changes routing for some keys, so plan that change with your consumers instead of assuming existing shard positions stay valid. - **Enhanced fan-out behaves differently: there is no dedicated throughput per consumer.** It uses consumer groups on Azure Event Hubs, so that service's capacity applies instead of Kinesis's per-consumer guarantee. - **Moving AWS records, sequence numbers and checkpoints is not supported.** The new stream starts empty, and old positions do not identify records in it.

#### Other considerations

**Before cutover.** Create the stream and the consumer checkpoint store first. Drain the old stream, or publish to both while consumers catch up.

**What to monitor.** Use Azure Event Hubs partition metrics and adapter metrics to watch reads, writes and lag; AWS CloudWatch series do not move with the stream.

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### Kinesis Data Streams · PUT payload units

Feature: Kinesis Data Streams.

Estimated monthly service charges by PUT payload units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: East US; currency: USD.

![Kinesis Data Streams · PUT payload units: monthly service charges by PUT payload units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/d4d3bceb6f8d7b7a7c36b328942e5dddbca638d5fd3b9f32c494a59fd7ba717b-light.svg)

![Kinesis Data Streams · PUT payload units: monthly service charges by PUT payload units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/afb10f8a17507783cd7044019f8910e85e04366356827c86915de70d349cfde8-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| PUT payload units (per second) | Kinesis Data Stream | Azure Event Hubs | Difference |
| -: | -: | -: | -: |
| 0 | 0.00 | 21.90 | 21.90 |
| 1 | 0.04 | 21.97 | 21.94 |
| 10 | 0.37 | 22.64 | 22.27 |
| 100 | 3.68 | 29.26 | 25.58 |
| 1,000 | 36.79 | 139.28 | 102.49 |
| 10,000 | 367.92 | 1,195.74 | 827.82 |

**Curve assumptions**

| Assumption | Value | Unit |
| - | -: | - |
| Origin list price · Provisioned shard-hours | 0.015 | USD/shard-hour |
| Origin list price · PUT payload units | 0.000000014 | USD/25-KiB record units |
| Representative record size | 1,024 | bytes |
| Full-stream consumer copies | 1 | copies |
| Target retained history | 24 | hours |
| Target record envelope | 64 | bytes/record |
| Target price guess · read | 0 | USD/read |
| Target list price · write | 0.000000028 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target price guess · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target list price · resource-hour | 0.03 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |

* Payload size determines physical record and byte throughput. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → East US, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
* A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
* Azure Event Hubs Standard bills throughput-unit hours, sized here from the family's published and delivered bytes and its ingress (write) and egress (read) event rates against one unit's published limits, never below one unit (USD 21.90/month). Ingress events also bill USD 0.028 per million; each family write is one event, and events over 64 KB, which bill as several, are not split. Up to 84 GB of storage per unit is included, so retained data adds no charge. Capture, when enabled, bills USD 0.10 per throughput-unit hour and is not modeled.
* AWS Price List API, AmazonKinesis offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json)
* Azure Retail Prices API: [https://prices.azure.com/api/retail/prices](https://prices.azure.com/api/retail/prices)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-50b2735e718e9d039b897f1878bcc337362c365f` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AmazonKinesis offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices).

##### Kinesis Data Streams · Origin provisioned shards

Feature: Kinesis Data Streams.

Estimated monthly service charges by Origin provisioned shards. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: East US; currency: USD.

![Kinesis Data Streams · Origin provisioned shards: monthly service charges by Origin provisioned shards. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/4962addfbefa9803c3c7d44fd8e447f478bd8e4def4c4dbafd460110b0135bbe-light.svg)

![Kinesis Data Streams · Origin provisioned shards: monthly service charges by Origin provisioned shards. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/f0a39576f6d3bfc1c8dea13a4d7c8591668a17ed023e6fb8e48cc0bf94ea8f17-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| Origin provisioned shards (shard-hours/month) | Kinesis Data Stream | Azure Event Hubs | Difference |
| -: | -: | -: | -: |
| 0 | 0.00 | 21.90 | 21.90 |
| 730 | 10.95 | 21.90 | 10.95 |
| 7,300 | 109.50 | 21.90 | -87.60 |
| 73,000 | 1,095.00 | 21.90 | -1,073.10 |
| 730,000 | 10,950.00 | 21.90 | -10,928.10 |

**Curve assumptions**

| Assumption | Value | Unit |
| - | -: | - |
| Origin list price · Provisioned shard-hours | 0.015 | USD/shard-hour |
| Origin list price · PUT payload units | 0.000000014 | USD/25-KiB record units |
| Representative record size | 1,024 | bytes |
| Full-stream consumer copies | 1 | copies |
| Target retained history | 24 | hours |
| Target record envelope | 64 | bytes/record |
| Target price guess · read | 0 | USD/read |
| Target list price · write | 0.000000028 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target price guess · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target list price · resource-hour | 0.03 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |

* Provisioned capacity alone does not reveal actual record traffic; PUT meter stays independent. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → East US, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
* A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
* Azure Event Hubs Standard bills throughput-unit hours, sized here from the family's published and delivered bytes and its ingress (write) and egress (read) event rates against one unit's published limits, never below one unit (USD 21.90/month). Ingress events also bill USD 0.028 per million; each family write is one event, and events over 64 KB, which bill as several, are not split. Up to 84 GB of storage per unit is included, so retained data adds no charge. Capture, when enabled, bills USD 0.10 per throughput-unit hour and is not modeled.
* AWS Price List API, AmazonKinesis offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json)
* Azure Retail Prices API: [https://prices.azure.com/api/retail/prices](https://prices.azure.com/api/retail/prices)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-50b2735e718e9d039b897f1878bcc337362c365f` / `2026-10-22.planning.2`. Curve: `workload-2`.

Sources: [AWS Price List API, AmazonKinesis offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices).

**Kinesis Data Streams → Azure Event Hubs: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: East US. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Provisioned shard-hours | 0.00 |
| Origin: PUT payload units | 0.00 |
| Target: Target retained physical data | 0.00 |
| Target: Additional broker replica storage | 0.00 |
| Target: Target ingress events | 0.00 |
| Target: Published bytes | 0.00 |
| Target: Delivered bytes | 0.00 |
| Target: Target native provider operations | 0.00 |
| Target: Execution or worker CPU | 0.00 |
| Target: Execution or worker RAM | 0.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: throughput units at planning peak | 21.90 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **21.90** |

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Provisioned shard-hours | 0.015 | USD/shard-hour |
| Origin list price · PUT payload units | 0.000000014 | USD/25-KiB record units |
| Representative record size | 1,024 | bytes |
| Full-stream consumer copies | 1 | copies |
| Target retained history | 24 | hours |
| Target record envelope | 64 | bytes/record |
| Target price guess · read | 0 | USD/read |
| Target list price · write | 0.000000028 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target price guess · GiB-month | 0 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target price guess · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target list price · resource-hour | 0.03 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Provisioned shard-hours | 0 | shard-hour |
| PUT payload units | 0 | 25-KiB record units |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.

* A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.

* Azure Event Hubs Standard bills throughput-unit hours, sized here from the family's published and delivered bytes and its ingress (write) and egress (read) event rates against one unit's published limits, never below one unit (USD 21.90/month). Ingress events also bill USD 0.028 per million; each family write is one event, and events over 64 KB, which bill as several, are not split. Up to 84 GB of storage per unit is included, so retained data adds no charge. Capture, when enabled, bills USD 0.10 per throughput-unit hour and is not modeled.

List prices read: 2026-10-22. Model: `plan-50b2735e718e9d039b897f1878bcc337362c365f` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AmazonKinesis offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices).

## On DigitalOcean

### DigitalOcean Managed 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 backend; 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 backend 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 backend 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 backend'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 backend's own: the managed backends 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 backend 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 managed broker's retention.ms; the ceiling is the broker's configured storage |

#### How it works

Your application keeps calling the Kinesis API, now on the Tensor9 adapter, and the adapter stores the record log on DigitalOcean Managed Kafka. Each Kinesis shard maps to a partition there. Partition-key hashing chooses the shard, and the partition's ordered position becomes part of the sequence number the call returns.

Consumers get an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records, and getting an iterator at a retained position lets you replay. These positions belong to the new stream: existing AWS sequence numbers and checkpoints do not point at anything in the new log.

#### Consumer state and capacity

The record log and each consumer's progress are kept separately. Kinesis Client Library (KCL) applications also keep leases and checkpoints in a DynamoDB table. Deploy a compatible DynamoDB adapter with this stream and test how the consumer restarts and reassigns shards; keeping the Kinesis endpoint alone does not provide that table.

Retention is set on DigitalOcean Managed Kafka and is limited by the provider's limits in the comparison table. Record size, uneven partitions, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with your own record sizes and partition distribution.

#### Limitations

* **Shard split and merge history is not supported.** The partition count is fixed. Adding partitions changes routing for some keys, so plan that change with your consumers instead of assuming existing shard positions stay valid. - **Enhanced fan-out behaves differently: there is no dedicated throughput per consumer.** It uses consumer groups on DigitalOcean Managed Kafka, so that service's capacity applies instead of Kinesis's per-consumer guarantee. - **Moving AWS records, sequence numbers and checkpoints is not supported.** The new stream starts empty, and old positions do not identify records in it.

#### Other considerations

**Before cutover.** Create the stream and the consumer checkpoint store first. Drain the old stream, or publish to both while consumers catch up.

**What to monitor.** Use DigitalOcean Managed Kafka partition metrics and adapter metrics to watch reads, writes and lag; AWS CloudWatch series do not move with the stream.

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### Kinesis Data Streams · PUT payload units

Feature: Kinesis Data Streams.

Estimated monthly service charges by PUT payload units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: nyc (flat in every datacenter); currency: USD.

![Kinesis Data Streams · PUT payload units: monthly service charges by PUT payload units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/a683c6cffe9ebc7ddbc4268ac6086ee4fdc223f030b8ec87d526141ae8ba199a-light.svg)

![Kinesis Data Streams · PUT payload units: monthly service charges by PUT payload units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/e5c0ea10d26e4a6e43f0df803d276a48c94a04773ce701a104aa9481d98b27ff-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| PUT payload units (per second) | Kinesis Data Stream | Target scenario | DigitalOcean Managed Kafka | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | DigitalOcean Managed Kafka (one copy) | 198.40 | 198.40 |
| 0 | 0.00 | DigitalOcean Managed Kafka (two copies) | 414.00 | 414.00 |
| 1 | 0.04 | DigitalOcean Managed Kafka (one copy) | 198.40 | 198.36 |
| 1 | 0.04 | DigitalOcean Managed Kafka (two copies) | 414.00 | 413.96 |
| 10 | 0.37 | DigitalOcean Managed Kafka (one copy) | 198.40 | 198.03 |
| 10 | 0.37 | DigitalOcean Managed Kafka (two copies) | 414.00 | 413.63 |
| 100 | 3.68 | DigitalOcean Managed Kafka (one copy) | 198.40 | 194.72 |
| 100 | 3.68 | DigitalOcean Managed Kafka (two copies) | 414.00 | 410.32 |
| 1,000 | 36.79 | DigitalOcean Managed Kafka (one copy) | 226.42 | 189.63 |
| 1,000 | 36.79 | DigitalOcean Managed Kafka (two copies) | 478.65 | 441.86 |
| 10,000 | 367.92 | DigitalOcean Managed Kafka (one copy) | 2,391.20 | 2,023.28 |
| 10,000 | 367.92 | DigitalOcean Managed Kafka (two copies) | 4,808.20 | 4,440.28 |

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 per second to 16 vCPU, 87.75 GiB memory and 1,120 GiB SSD at 10,000 per second.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| DigitalOcean Managed Kafka (one copy) | Origin list price · Provisioned shard-hours | 0.015 | USD/shard-hour |
| DigitalOcean Managed Kafka (one copy) | Origin list price · PUT payload units | 0.000000014 | USD/25-KiB record units |
| DigitalOcean Managed Kafka (one copy) | Representative record size | 1,024 | bytes |
| DigitalOcean Managed Kafka (one copy) | Full-stream consumer copies | 1 | copies |
| DigitalOcean Managed Kafka (one copy) | Target retained history | 24 | hours |
| DigitalOcean Managed Kafka (one copy) | Target record envelope | 64 | bytes/record |
| DigitalOcean Managed Kafka (one copy) | Target price guess · read | 0 | USD/read |
| DigitalOcean Managed Kafka (one copy) | Target price guess · write | 0 | USD/write |
| DigitalOcean Managed Kafka (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| DigitalOcean Managed Kafka (one copy) | Target list price · GiB-month | 0.215 | USD/GiB-month |
| DigitalOcean Managed Kafka (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| DigitalOcean Managed Kafka (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| DigitalOcean Managed Kafka (one copy) | Target price guess · network GiB | 0 | USD/network GiB |
| DigitalOcean Managed Kafka (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| DigitalOcean Managed Kafka (one copy) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| DigitalOcean Managed Kafka (one copy) | Target list price · GiB-hour | 0.0339726 | USD/GiB-hour |
| DigitalOcean Managed Kafka (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| DigitalOcean Managed Kafka (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| DigitalOcean Managed Kafka (one copy) | Target price guess · input token | 0 | USD/input token |
| DigitalOcean Managed Kafka (one copy) | Target price guess · output token | 0 | USD/output token |
| DigitalOcean Managed Kafka (one copy) | Included before billing · GiB-month | 120 | GiB-month |
| DigitalOcean Managed Kafka (one copy) | Target monthly base charge | 0 | USD/month |
| DigitalOcean Managed Kafka (one copy) | Target service minimum | 148.8 | USD/month |
| DigitalOcean Managed Kafka (one copy) | Minimum primary CPU | 2 | vCPU |
| DigitalOcean Managed Kafka (one copy) | Minimum primary RAM | 8 | GiB |
| DigitalOcean Managed Kafka (one copy) | Minimum primary disk | 100 | GiB |
| DigitalOcean Managed Kafka (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| DigitalOcean Managed Kafka (one copy) | Allocated share of provisioned cost | 1 | fraction |
| DigitalOcean Managed Kafka (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| DigitalOcean Managed Kafka (one copy) | Planning peak / mean work | 2 | multiplier |
| DigitalOcean Managed Kafka (one copy) | Planning primary CPU utilization | 0.5 | fraction |
| DigitalOcean Managed Kafka (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| DigitalOcean Managed Kafka (one copy) | Planning disk utilization | 0.8 | fraction |
| DigitalOcean Managed Kafka (one copy) | Maintenance and log disk reserve | 20 | GiB |
| DigitalOcean Managed Kafka (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| DigitalOcean Managed Kafka (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| DigitalOcean Managed Kafka (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| DigitalOcean Managed Kafka (one copy) | Broker write-equivalent throughput per vCPU | 20 | MiB/vCPU-second |
| DigitalOcean Managed Kafka (one copy) | Broker replicas per written byte | 3 | replicas |
| DigitalOcean Managed Kafka (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| DigitalOcean Managed Kafka (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| DigitalOcean Managed Kafka (two copies) | Origin list price · Provisioned shard-hours | 0.015 | USD/shard-hour |
| DigitalOcean Managed Kafka (two copies) | Origin list price · PUT payload units | 0.000000014 | USD/25-KiB record units |
| DigitalOcean Managed Kafka (two copies) | Representative record size | 1,024 | bytes |
| DigitalOcean Managed Kafka (two copies) | Full-stream consumer copies | 1 | copies |
| DigitalOcean Managed Kafka (two copies) | Target retained history | 24 | hours |
| DigitalOcean Managed Kafka (two copies) | Target record envelope | 64 | bytes/record |
| DigitalOcean Managed Kafka (two copies) | Target price guess · read | 0 | USD/read |
| DigitalOcean Managed Kafka (two copies) | Target price guess · write | 0 | USD/write |
| DigitalOcean Managed Kafka (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| DigitalOcean Managed Kafka (two copies) | Target list price · GiB-month | 0.215 | USD/GiB-month |
| DigitalOcean Managed Kafka (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| DigitalOcean Managed Kafka (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| DigitalOcean Managed Kafka (two copies) | Target price guess · network GiB | 0 | USD/network GiB |
| DigitalOcean Managed Kafka (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| DigitalOcean Managed Kafka (two copies) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| DigitalOcean Managed Kafka (two copies) | Target list price · GiB-hour | 0.0339726 | USD/GiB-hour |
| DigitalOcean Managed Kafka (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| DigitalOcean Managed Kafka (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| DigitalOcean Managed Kafka (two copies) | Target price guess · input token | 0 | USD/input token |
| DigitalOcean Managed Kafka (two copies) | Target price guess · output token | 0 | USD/output token |
| DigitalOcean Managed Kafka (two copies) | Included before billing · GiB-month | 120 | GiB-month |
| DigitalOcean Managed Kafka (two copies) | Target monthly base charge | 0 | USD/month |
| DigitalOcean Managed Kafka (two copies) | Target service minimum | 148.8 | USD/month |
| DigitalOcean Managed Kafka (two copies) | Minimum primary CPU | 2 | vCPU |
| DigitalOcean Managed Kafka (two copies) | Minimum primary RAM | 8 | GiB |
| DigitalOcean Managed Kafka (two copies) | Minimum primary disk | 100 | GiB |
| DigitalOcean Managed Kafka (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| DigitalOcean Managed Kafka (two copies) | Allocated share of provisioned cost | 1 | fraction |
| DigitalOcean Managed Kafka (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| DigitalOcean Managed Kafka (two copies) | Planning peak / mean work | 2 | multiplier |
| DigitalOcean Managed Kafka (two copies) | Planning primary CPU utilization | 0.5 | fraction |
| DigitalOcean Managed Kafka (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| DigitalOcean Managed Kafka (two copies) | Planning disk utilization | 0.8 | fraction |
| DigitalOcean Managed Kafka (two copies) | Maintenance and log disk reserve | 20 | GiB |
| DigitalOcean Managed Kafka (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| DigitalOcean Managed Kafka (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| DigitalOcean Managed Kafka (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| DigitalOcean Managed Kafka (two copies) | Broker write-equivalent throughput per vCPU | 20 | MiB/vCPU-second |
| DigitalOcean Managed Kafka (two copies) | Broker replicas per written byte | 3 | replicas |
| DigitalOcean Managed Kafka (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| DigitalOcean Managed Kafka (two copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Payload size determines physical record and byte throughput. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → nyc (flat in every datacenter), USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
* A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
* DigitalOcean Managed Kafka bills fixed three-broker plans with CPU included and a minimum storage allocation, plus extra storage. The smallest plan (6 GiB of cluster RAM, 120-240 GiB storage) is USD 148.80/month and the next (12 GiB) USD 296.25, about USD 24.80 per GiB of cluster RAM a month, so the model bills the selected RAM at that rate with no CPU charge, without rounding to a plan or to multiples of three nodes. The three brokers already replicate, so a selected standby copy overstates the cluster. Storage above the plan's included 120 GiB bills USD 0.215 per GiB-month in 30 GiB increments. DigitalOcean's documentation page (last verified 17 June 2025) still lists the older USD 147.00 plan.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* Broker CPU follows write-equivalent bytes; the row-store operations coefficient is not applied.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AmazonKinesis offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json)
* DigitalOcean Managed Databases pricing: [https://www.digitalocean.com/pricing/managed-databases](https://www.digitalocean.com/pricing/managed-databases)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-e96780116175bd9af9e4631e78692cc13c7a74a7` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AmazonKinesis offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json), [DigitalOcean Managed Databases pricing](https://www.digitalocean.com/pricing/managed-databases).

##### Kinesis Data Streams · Origin provisioned shards

Feature: Kinesis Data Streams.

Estimated monthly service charges by Origin provisioned shards. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: nyc (flat in every datacenter); currency: USD.

![Kinesis Data Streams · Origin provisioned shards: monthly service charges by Origin provisioned shards. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/7ec68f95c5c85500d1fe95553cac7ff122fcc071968ff8471f064b6c02bbcff3-light.svg)

![Kinesis Data Streams · Origin provisioned shards: monthly service charges by Origin provisioned shards. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/8a48c704fd70f7e4892344ae162a4de338b37119902dcf0f0ed65d90b0ec5ea1-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| Origin provisioned shards (shard-hours/month) | Kinesis Data Stream | Target scenario | DigitalOcean Managed Kafka | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | DigitalOcean Managed Kafka (one copy) | 198.40 | 198.40 |
| 0 | 0.00 | DigitalOcean Managed Kafka (two copies) | 414.00 | 414.00 |
| 730 | 10.95 | DigitalOcean Managed Kafka (one copy) | 198.40 | 187.45 |
| 730 | 10.95 | DigitalOcean Managed Kafka (two copies) | 414.00 | 403.05 |
| 7,300 | 109.50 | DigitalOcean Managed Kafka (one copy) | 198.40 | 88.90 |
| 7,300 | 109.50 | DigitalOcean Managed Kafka (two copies) | 414.00 | 304.50 |
| 73,000 | 1,095.00 | DigitalOcean Managed Kafka (one copy) | 198.40 | -896.60 |
| 73,000 | 1,095.00 | DigitalOcean Managed Kafka (two copies) | 414.00 | -681.00 |
| 730,000 | 10,950.00 | DigitalOcean Managed Kafka (one copy) | 198.40 | -10,751.60 |
| 730,000 | 10,950.00 | DigitalOcean Managed Kafka (two copies) | 414.00 | -10,536.00 |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| DigitalOcean Managed Kafka (one copy) | Origin list price · Provisioned shard-hours | 0.015 | USD/shard-hour |
| DigitalOcean Managed Kafka (one copy) | Origin list price · PUT payload units | 0.000000014 | USD/25-KiB record units |
| DigitalOcean Managed Kafka (one copy) | Representative record size | 1,024 | bytes |
| DigitalOcean Managed Kafka (one copy) | Full-stream consumer copies | 1 | copies |
| DigitalOcean Managed Kafka (one copy) | Target retained history | 24 | hours |
| DigitalOcean Managed Kafka (one copy) | Target record envelope | 64 | bytes/record |
| DigitalOcean Managed Kafka (one copy) | Target price guess · read | 0 | USD/read |
| DigitalOcean Managed Kafka (one copy) | Target price guess · write | 0 | USD/write |
| DigitalOcean Managed Kafka (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| DigitalOcean Managed Kafka (one copy) | Target list price · GiB-month | 0.215 | USD/GiB-month |
| DigitalOcean Managed Kafka (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| DigitalOcean Managed Kafka (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| DigitalOcean Managed Kafka (one copy) | Target price guess · network GiB | 0 | USD/network GiB |
| DigitalOcean Managed Kafka (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| DigitalOcean Managed Kafka (one copy) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| DigitalOcean Managed Kafka (one copy) | Target list price · GiB-hour | 0.0339726 | USD/GiB-hour |
| DigitalOcean Managed Kafka (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| DigitalOcean Managed Kafka (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| DigitalOcean Managed Kafka (one copy) | Target price guess · input token | 0 | USD/input token |
| DigitalOcean Managed Kafka (one copy) | Target price guess · output token | 0 | USD/output token |
| DigitalOcean Managed Kafka (one copy) | Included before billing · GiB-month | 120 | GiB-month |
| DigitalOcean Managed Kafka (one copy) | Target monthly base charge | 0 | USD/month |
| DigitalOcean Managed Kafka (one copy) | Target service minimum | 148.8 | USD/month |
| DigitalOcean Managed Kafka (one copy) | Minimum primary CPU | 2 | vCPU |
| DigitalOcean Managed Kafka (one copy) | Minimum primary RAM | 8 | GiB |
| DigitalOcean Managed Kafka (one copy) | Minimum primary disk | 100 | GiB |
| DigitalOcean Managed Kafka (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| DigitalOcean Managed Kafka (one copy) | Allocated share of provisioned cost | 1 | fraction |
| DigitalOcean Managed Kafka (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| DigitalOcean Managed Kafka (one copy) | Planning peak / mean work | 2 | multiplier |
| DigitalOcean Managed Kafka (one copy) | Planning primary CPU utilization | 0.5 | fraction |
| DigitalOcean Managed Kafka (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| DigitalOcean Managed Kafka (one copy) | Planning disk utilization | 0.8 | fraction |
| DigitalOcean Managed Kafka (one copy) | Maintenance and log disk reserve | 20 | GiB |
| DigitalOcean Managed Kafka (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| DigitalOcean Managed Kafka (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| DigitalOcean Managed Kafka (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| DigitalOcean Managed Kafka (one copy) | Broker write-equivalent throughput per vCPU | 20 | MiB/vCPU-second |
| DigitalOcean Managed Kafka (one copy) | Broker replicas per written byte | 3 | replicas |
| DigitalOcean Managed Kafka (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| DigitalOcean Managed Kafka (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| DigitalOcean Managed Kafka (two copies) | Origin list price · Provisioned shard-hours | 0.015 | USD/shard-hour |
| DigitalOcean Managed Kafka (two copies) | Origin list price · PUT payload units | 0.000000014 | USD/25-KiB record units |
| DigitalOcean Managed Kafka (two copies) | Representative record size | 1,024 | bytes |
| DigitalOcean Managed Kafka (two copies) | Full-stream consumer copies | 1 | copies |
| DigitalOcean Managed Kafka (two copies) | Target retained history | 24 | hours |
| DigitalOcean Managed Kafka (two copies) | Target record envelope | 64 | bytes/record |
| DigitalOcean Managed Kafka (two copies) | Target price guess · read | 0 | USD/read |
| DigitalOcean Managed Kafka (two copies) | Target price guess · write | 0 | USD/write |
| DigitalOcean Managed Kafka (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| DigitalOcean Managed Kafka (two copies) | Target list price · GiB-month | 0.215 | USD/GiB-month |
| DigitalOcean Managed Kafka (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| DigitalOcean Managed Kafka (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| DigitalOcean Managed Kafka (two copies) | Target price guess · network GiB | 0 | USD/network GiB |
| DigitalOcean Managed Kafka (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| DigitalOcean Managed Kafka (two copies) | Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| DigitalOcean Managed Kafka (two copies) | Target list price · GiB-hour | 0.0339726 | USD/GiB-hour |
| DigitalOcean Managed Kafka (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| DigitalOcean Managed Kafka (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| DigitalOcean Managed Kafka (two copies) | Target price guess · input token | 0 | USD/input token |
| DigitalOcean Managed Kafka (two copies) | Target price guess · output token | 0 | USD/output token |
| DigitalOcean Managed Kafka (two copies) | Included before billing · GiB-month | 120 | GiB-month |
| DigitalOcean Managed Kafka (two copies) | Target monthly base charge | 0 | USD/month |
| DigitalOcean Managed Kafka (two copies) | Target service minimum | 148.8 | USD/month |
| DigitalOcean Managed Kafka (two copies) | Minimum primary CPU | 2 | vCPU |
| DigitalOcean Managed Kafka (two copies) | Minimum primary RAM | 8 | GiB |
| DigitalOcean Managed Kafka (two copies) | Minimum primary disk | 100 | GiB |
| DigitalOcean Managed Kafka (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| DigitalOcean Managed Kafka (two copies) | Allocated share of provisioned cost | 1 | fraction |
| DigitalOcean Managed Kafka (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| DigitalOcean Managed Kafka (two copies) | Planning peak / mean work | 2 | multiplier |
| DigitalOcean Managed Kafka (two copies) | Planning primary CPU utilization | 0.5 | fraction |
| DigitalOcean Managed Kafka (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| DigitalOcean Managed Kafka (two copies) | Planning disk utilization | 0.8 | fraction |
| DigitalOcean Managed Kafka (two copies) | Maintenance and log disk reserve | 20 | GiB |
| DigitalOcean Managed Kafka (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| DigitalOcean Managed Kafka (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| DigitalOcean Managed Kafka (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| DigitalOcean Managed Kafka (two copies) | Broker write-equivalent throughput per vCPU | 20 | MiB/vCPU-second |
| DigitalOcean Managed Kafka (two copies) | Broker replicas per written byte | 3 | replicas |
| DigitalOcean Managed Kafka (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| DigitalOcean Managed Kafka (two copies) | Dependent object sink write price guess | 0.000005 | USD/write |

* Provisioned capacity alone does not reveal actual record traffic; PUT meter stays independent. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → nyc (flat in every datacenter), USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
* A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
* DigitalOcean Managed Kafka bills fixed three-broker plans with CPU included and a minimum storage allocation, plus extra storage. The smallest plan (6 GiB of cluster RAM, 120-240 GiB storage) is USD 148.80/month and the next (12 GiB) USD 296.25, about USD 24.80 per GiB of cluster RAM a month, so the model bills the selected RAM at that rate with no CPU charge, without rounding to a plan or to multiples of three nodes. The three brokers already replicate, so a selected standby copy overstates the cluster. Storage above the plan's included 120 GiB bills USD 0.215 per GiB-month in 30 GiB increments. DigitalOcean's documentation page (last verified 17 June 2025) still lists the older USD 147.00 plan.
* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.
* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).
* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.
* Broker CPU follows write-equivalent bytes; the row-store operations coefficient is not applied.
* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
* AWS Price List API, AmazonKinesis offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json)
* DigitalOcean Managed Databases pricing: [https://www.digitalocean.com/pricing/managed-databases](https://www.digitalocean.com/pricing/managed-databases)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-e96780116175bd9af9e4631e78692cc13c7a74a7` / `2026-10-22.planning.2`. Curve: `workload-2`.

Sources: [AWS Price List API, AmazonKinesis offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json), [DigitalOcean Managed Databases pricing](https://www.digitalocean.com/pricing/managed-databases).

**Kinesis Data Streams → DigitalOcean Managed Kafka: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: nyc (flat in every datacenter). Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Provisioned shard-hours | 0.00 |
| Origin: PUT payload units | 0.00 |
| Target: Provisioned primary CPU | 0.00 |
| Target: Provisioned primary RAM | 198.40 |
| Target: Provisioned primary disk after 120 included | 0.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent provisioned resources | 0.00 |
| Target: Independent managed resources | 0.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **198.40** |

Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario.

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Provisioned shard-hours | 0.015 | USD/shard-hour |
| Origin list price · PUT payload units | 0.000000014 | USD/25-KiB record units |
| Representative record size | 1,024 | bytes |
| Full-stream consumer copies | 1 | copies |
| Target retained history | 24 | hours |
| Target record envelope | 64 | bytes/record |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target list price · GiB-month | 0.215 | USD/GiB-month |
| Target price guess · published GiB | 0 | USD/published GiB |
| Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Target price guess · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target list price · GiB-hour | 0.0339726 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Included before billing · GiB-month | 120 | GiB-month |
| Target monthly base charge | 0 | USD/month |
| Target service minimum | 148.8 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.5 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Broker write-equivalent throughput per vCPU | 20 | MiB/vCPU-second |
| Broker replicas per written byte | 3 | replicas |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Provisioned shard-hours | 0 | shard-hour |
| PUT payload units | 0 | 25-KiB record units |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.

* A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.

* DigitalOcean Managed Kafka bills fixed three-broker plans with CPU included and a minimum storage allocation, plus extra storage. The smallest plan (6 GiB of cluster RAM, 120-240 GiB storage) is USD 148.80/month and the next (12 GiB) USD 296.25, about USD 24.80 per GiB of cluster RAM a month, so the model bills the selected RAM at that rate with no CPU charge, without rounding to a plan or to multiples of three nodes. The three brokers already replicate, so a selected standby copy overstates the cluster. Storage above the plan's included 120 GiB bills USD 0.215 per GiB-month in 30 GiB increments. DigitalOcean's documentation page (last verified 17 June 2025) still lists the older USD 147.00 plan.

* Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.

* Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.

* Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured.

* CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.

* No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.

* Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)).

* Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied.

* Broker CPU follows write-equivalent bytes; the row-store operations coefficient is not applied.

* Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: `plan-e96780116175bd9af9e4631e78692cc13c7a74a7` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AmazonKinesis offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json), [DigitalOcean Managed Databases pricing](https://www.digitalocean.com/pricing/managed-databases).

## On Google Cloud

### 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 backend 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 backend'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 backend's own: the managed backends 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 backend 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 backend |

#### How it works

Your application keeps calling the Kinesis API on the Tensor9 adapter, which maps the stream to a Pub/Sub topic and uses each record's partition key as the Pub/Sub ordering key. Records with the same key stay in order. Pub/Sub has no hash ranges and no fixed set of addressable shards.

Reads pull from a Pub/Sub subscription. Separate subscriptions give fan-out consumers their own copy of the messages and their own delivery state. Pub/Sub can replay from a timestamp or a snapshot, but it has no per-message offset, so a returned sequence number cannot promise replay from exactly that record.

#### Limitations

* **`ExplicitHashKey`, shard splits and merges are not supported.** The ordering-key mapping cannot represent them. - **Replay from an exact sequence number is not supported.** Review any consumer that saves a sequence number and later expects to resume at exactly that record. - **Dedicated throughput per consumer is not supported.** Google controls subscription delivery and capacity. - **Retention behaves differently: it is about 31 days at most.** Pub/Sub cannot keep records for the 365 days Kinesis allows. - **You must provide the KCL lease table.** Kinesis Client Library applications still need their DynamoDB lease table, through a compatible DynamoDB adapter.

#### Other considerations

**Before cutover.** Create subscriptions before publishing, test restart and replay, and confirm your consumers work without addressable shard positions. Existing AWS records and checkpoints are not copied.

**What to monitor.** Measure adapter latency, backlog and consumer progress together; a topic accepting a message does not show how fast it is processed end to end.

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### Monthly cost by provisioned Kinesis shards

Reference monthly service charges by Provisioned shards. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Monthly cost by provisioned Kinesis shards: monthly service charges by Provisioned shards. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/a7562c84450d5e0e1288b8f21c21054b7ec92534f651fd106e46d2ba66f025e7-light.svg)

![Monthly cost by provisioned Kinesis shards: monthly service charges by Provisioned shards. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/721699a1667971c699145eb2ed75f59677ec79aa38066fcd695d842e3009e769-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| Provisioned shards (shards) | Kinesis Data Stream | Pub/Sub (one subscription) | Difference |
| -: | -: | -: | -: |
| 1 | 14.63 | 23.17 | 8.54 |
| 2 | 29.26 | 46.34 | 17.08 |
| 4 | 58.52 | 92.67 | 34.15 |
| 8 | 117.03 | 185.34 | 68.31 |
| 16 | 234.07 | 370.68 | 136.62 |
| 64 | 936.27 | 1,482.73 | 546.46 |

**Curve assumptions**

| Assumption | Value | Unit |
| - | -: | - |
| Representative Kinesis record size | 1,024 | bytes |
| Full-stream consumers | 1 | copies |
| Target record envelope overhead | 64 | bytes/record |
| Target publish batch fill | 1 | records/request |
| Target delivery batch fill | 1 | records/request |

* 100 records/s per provisioned source shard, each 1 KiB; one full-stream consumer; 730 hours/month. Pub/Sub retains the physical stream at topic level for 24 hours, including 64 bytes of assumed overhead per record. Source shard count and traffic are authored scenario choices, not measured adapter throughput or semantic equivalence.
* Monthly AWS source usage in us-east-1, priced at the 2026-10-18 reference list rates before free allowances, discounts, credits and tax; not the uploaded invoice total. Rates as of 2026-10-18: us-east-1 → us-central1, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Provisioned Kinesis, 24-hour retention and shared-throughput consumers only; on-demand, enhanced fan-out and extended retention use different pricing.
* Pub/Sub publishes and delivers each full consumer copy, and retains the physical stream for 24 hours at topic level for replay. Steady traffic over 730 hours is assumed.
* Pub/Sub ordering keys do not reproduce addressable shards or exact per-record offsets. This pricing comparison does not qualify semantic compatibility or throughput.
* Source usage is priced at reference rates; source lines are not actual invoice charges. Free or discounted usage still consumes target resources.
* Kinesis Data Streams provisioned pricing: [https://aws.amazon.com/kinesis/data-streams/pricing/](https://aws.amazon.com/kinesis/data-streams/pricing/)
* Pub/Sub throughput and retained-message pricing: [https://cloud.google.com/pubsub/pricing](https://cloud.google.com/pubsub/pricing)

Cost scope: Modeled monthly service usage and selected database allocation; adapter hosting and Tensor9 fees only when explicitly supplied.

Excluded costs and workload features:

* Free allowances, negotiated discounts, credits, tax and one-time migration charges.
* Charges not listed in the breakdown, including additional network transfer, backups and encryption/KMS.
* Application compute changes, operational labor and portfolio-wide sharing or deduplication of infrastructure.
* KCL DynamoDB lease-table costs, replay/redelivery beyond the declared consumer copies, snapshots and extra subscriptions.

Rate snapshot: 2026-10-18. Model: `kinesis-pubsub` / `2026-10-18.4`. Curve: `provisioned-shards`.

Sources: [Kinesis Data Streams provisioned pricing](https://aws.amazon.com/kinesis/data-streams/pricing/), [Pub/Sub throughput and retained-message pricing](https://cloud.google.com/pubsub/pricing).

**Kinesis Data Streams → Google Cloud Pub/Sub: Reference monthly workload.** Monthly AWS usage charges at the 2026-10-18 reference list rates in us-east-1, before free allowances, discounts, credits and tax.

Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Kinesis provisioned shards | 10.95 |
| Origin: Kinesis PUT payload units | 3.68 |
| Target: Pub/Sub published throughput | 10.40 |
| Target: Pub/Sub delivered throughput | 10.40 |
| Target: Pub/Sub 24-hour topic retention | 2.36 |
| **Origin service subtotal** | **14.63** |
| **Target service subtotal** | **23.17** |

Unestimated components: Allocated adapter hosting, Allocated Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled monthly service usage and selected database allocation; adapter hosting and Tensor9 fees only when explicitly supplied.

Excluded costs and workload features:

* Free allowances, negotiated discounts, credits, tax and one-time migration charges.
* Charges not listed in the breakdown, including additional network transfer, backups and encryption/KMS.
* Application compute changes, operational labor and portfolio-wide sharing or deduplication of infrastructure.
* KCL DynamoDB lease-table costs, replay/redelivery beyond the declared consumer copies, snapshots and extra subscriptions.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Provisioned Kinesis shard charges | 10.95 | USD/month |
| Kinesis PUT payload charges | 3.6792 | USD/month |
| Representative Kinesis record size | 1,024 | bytes |
| Full-stream consumers | 1 | copies |
| Target record envelope overhead | 64 | bytes/record |
| Target publish batch fill | 1 | records/request |
| Target delivery batch fill | 1 | records/request |

* Provisioned origin shard-hours: 730 shard-hours/month.

* Inferred original stream records: 262,800,000 records/month.

* Steady 24-hour physical retained stream: 8.755 GiB.

* Provisioned Kinesis, 24-hour retention and shared-throughput consumers only; on-demand, enhanced fan-out and extended retention use different pricing.

* Pub/Sub publishes and delivers each full consumer copy, and retains the physical stream for 24 hours at topic level for replay. Steady traffic over 730 hours is assumed.

* Pub/Sub ordering keys do not reproduce addressable shards or exact per-record offsets. This pricing comparison does not qualify semantic compatibility or throughput.

Rate snapshot: 2026-10-18. Model: `kinesis-pubsub` / `2026-10-18.4`. Scenario: `kinesis-pubsub-reference`.

Sources: [Kinesis Data Streams provisioned pricing](https://aws.amazon.com/kinesis/data-streams/pricing/), [Pub/Sub throughput and retained-message pricing](https://cloud.google.com/pubsub/pricing).

### 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 backend; 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 backend 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 backend 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 backend'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 backend's own: the managed backends 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 backend 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) |

#### How it works

Your application keeps calling the Kinesis API, now on the Tensor9 adapter, and the adapter stores the record log on Google's Managed Service for Apache Kafka. Each Kinesis shard maps to a partition there. Partition-key hashing chooses the shard, and the partition's ordered position becomes part of the sequence number the call returns.

Consumers get an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records, and getting an iterator at a retained position lets you replay. These positions belong to the new stream: existing AWS sequence numbers and checkpoints do not point at anything in the new log.

#### Consumer state and capacity

The record log and each consumer's progress are kept separately. Kinesis Client Library (KCL) applications also keep leases and checkpoints in a DynamoDB table. Deploy a compatible DynamoDB adapter with this stream and test how the consumer restarts and reassigns shards; keeping the Kinesis endpoint alone does not provide that table.

Retention is set on Google's Managed Service for Apache Kafka and is limited by the provider's limits in the comparison table. Record size, uneven partitions, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with your own record sizes and partition distribution.

#### Limitations

* **Shard split and merge history is not supported.** The partition count is fixed. Adding partitions changes routing for some keys, so plan that change with your consumers instead of assuming existing shard positions stay valid. - **Enhanced fan-out behaves differently: there is no dedicated throughput per consumer.** It uses consumer groups on Google's Managed Service for Apache Kafka, so that service's capacity applies instead of Kinesis's per-consumer guarantee. - **Moving AWS records, sequence numbers and checkpoints is not supported.** The new stream starts empty, and old positions do not identify records in it.

#### Other considerations

**Before cutover.** Create the stream and the consumer checkpoint store first. Drain the old stream, or publish to both while consumers catch up.

**What to monitor.** Use Google's Managed Service for Apache Kafka partition metrics and adapter metrics to watch reads, writes and lag; AWS CloudWatch series do not move with the stream.

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### Monthly cost by provisioned Kinesis shards

Reference monthly service charges by Provisioned shards. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Monthly cost by provisioned Kinesis shards: monthly service charges by Provisioned shards. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/268f57d3d53910fc6ea89642a7987b7c0507ffb453efe1c2dde3c1da00b9ab60-light.svg)

![Monthly cost by provisioned Kinesis shards: monthly service charges by Provisioned shards. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/5f3022538b6237358cbc9d465412a98c9b0cd462d254a4a3577fa84415c04e31-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| Provisioned shards (shards) | Kinesis Data Stream | Target scenario | Managed Service for Apache Kafka | Difference |
| -: | -: | - | -: | -: |
| 1 | 14.63 | Managed Service for Apache Kafka (3 vCPU / 12 GiB) | 254.30 | 239.67 |
| 1 | 14.63 | Managed Service for Apache Kafka (6 vCPU / 24 GiB) | 502.40 | 487.77 |
| 2 | 29.26 | Managed Service for Apache Kafka (3 vCPU / 12 GiB) | 260.50 | 231.24 |
| 2 | 29.26 | Managed Service for Apache Kafka (6 vCPU / 24 GiB) | 508.60 | 479.34 |
| 4 | 58.52 | Managed Service for Apache Kafka (3 vCPU / 12 GiB) | 272.91 | 214.39 |
| 4 | 58.52 | Managed Service for Apache Kafka (6 vCPU / 24 GiB) | 521.01 | 462.49 |
| 8 | 117.03 | Managed Service for Apache Kafka (3 vCPU / 12 GiB) | 297.71 | 180.68 |
| 8 | 117.03 | Managed Service for Apache Kafka (6 vCPU / 24 GiB) | 545.81 | 428.78 |
| 16 | 234.07 | Managed Service for Apache Kafka (3 vCPU / 12 GiB) | 347.32 | 113.25 |
| 16 | 234.07 | Managed Service for Apache Kafka (6 vCPU / 24 GiB) | 595.42 | 361.35 |
| 64 | 936.27 | Managed Service for Apache Kafka (3 vCPU / 12 GiB) | 644.98 | -291.29 |
| 64 | 936.27 | Managed Service for Apache Kafka (6 vCPU / 24 GiB) | 893.08 | -43.19 |

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| Managed Service for Apache Kafka (3 vCPU / 12 GiB) | Representative Kinesis record size | 1,024 | bytes |
| Managed Service for Apache Kafka (3 vCPU / 12 GiB) | Full-stream consumers | 1 | copies |
| Managed Service for Apache Kafka (3 vCPU / 12 GiB) | Target record envelope overhead | 64 | bytes/record |
| Managed Service for Apache Kafka (3 vCPU / 12 GiB) | Managed Kafka cluster vCPUs | 3 | vCPU |
| Managed Service for Apache Kafka (3 vCPU / 12 GiB) | Managed Kafka cluster memory | 12 | GiB |
| Managed Service for Apache Kafka (3 vCPU / 12 GiB) | Default-profile local disk allocation | 300 | GiB |
| Managed Service for Apache Kafka (3 vCPU / 12 GiB) | Long-term storage allocation | 8.75473 | GiB-month |
| Managed Service for Apache Kafka (3 vCPU / 12 GiB) | Cross-zone client traffic | 0 | GiB/month |
| Managed Service for Apache Kafka (6 vCPU / 24 GiB) | Representative Kinesis record size | 1,024 | bytes |
| Managed Service for Apache Kafka (6 vCPU / 24 GiB) | Full-stream consumers | 1 | copies |
| Managed Service for Apache Kafka (6 vCPU / 24 GiB) | Target record envelope overhead | 64 | bytes/record |
| Managed Service for Apache Kafka (6 vCPU / 24 GiB) | Managed Kafka cluster vCPUs | 6 | vCPU |
| Managed Service for Apache Kafka (6 vCPU / 24 GiB) | Managed Kafka cluster memory | 24 | GiB |
| Managed Service for Apache Kafka (6 vCPU / 24 GiB) | Default-profile local disk allocation | 600 | GiB |
| Managed Service for Apache Kafka (6 vCPU / 24 GiB) | Long-term storage allocation | 8.75473 | GiB-month |
| Managed Service for Apache Kafka (6 vCPU / 24 GiB) | Cross-zone client traffic | 0 | GiB/month |

* 100 records/s per source shard, each 1 KiB; one full-stream consumer; 24-hour retention; 730 hours/month. The target remains a named 3-vCPU/12-GiB cluster with 300 GiB local disk: its throughput is unqualified. The full retained physical stream is also allocated to single-copy long-term storage, a conservative storage scenario; actual tier placement can reduce it. Three replicas and their inter-zone transfer are priced; same-zone clients and local follower reads are assumed.
* Monthly AWS source usage in us-east-1, priced at the 2026-10-18 reference list rates before free allowances, discounts, credits and tax; not the uploaded invoice total. Rates as of 2026-10-18: us-east-1 → us-central1, USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Provisioned Kinesis with 24-hour retention and shared-read consumers; 730 running hours. Google Managed Kafka uses three replicas across zones.
* Cluster allocation pricing only: throughput, peak load, retention suitability and latency remain unqualified. The curve does not resize compute automatically.
* Compute is USD 0.09 per DCU-hour; one vCPU is 0.6 DCU and one GiB RAM is 0.1 DCU. All local disk is charged, plus the explicitly selected single-copy long-term storage allocation.
* Replication transfers two physical copies at USD 0.01/GiB. Same-zone client traffic assumes local follower reads; extra client traffic must be supplied separately.
* Source usage is priced at reference rates; source lines are not actual invoice charges. Free or discounted usage still consumes target resources.
* Kinesis Data Streams provisioned pricing: [https://aws.amazon.com/kinesis/data-streams/pricing/](https://aws.amazon.com/kinesis/data-streams/pricing/)
* Google Managed Kafka pricing: [https://cloud.google.com/managed-service-for-apache-kafka/pricing](https://cloud.google.com/managed-service-for-apache-kafka/pricing)
* Managed Kafka capacity configuration: [https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/create-cluster](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/create-cluster)

Cost scope: Modeled monthly service usage and selected database allocation; adapter hosting and Tensor9 fees only when explicitly supplied.

Excluded costs and workload features:

* Free allowances, negotiated discounts, credits, tax and one-time migration charges.
* Charges not listed in the breakdown, including additional network transfer, backups and encryption/KMS.
* Application compute changes, operational labor and portfolio-wide sharing or deduplication of infrastructure.
* KCL DynamoDB lease-table costs, Connect clusters, extra replication/consumer copies, unsupported resharding behavior and unqualified cluster capacity.

Rate snapshot: 2026-10-18. Model: `kinesis-managed-kafka` / `2026-10-18.4`. Curve: `provisioned-shards`.

Sources: [Kinesis Data Streams provisioned pricing](https://aws.amazon.com/kinesis/data-streams/pricing/), [Google Managed Kafka pricing](https://cloud.google.com/managed-service-for-apache-kafka/pricing), [Managed Kafka capacity configuration](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/create-cluster).

**Kinesis Data Streams → Google Managed Kafka: Reference monthly workload.** Monthly AWS usage charges at the 2026-10-18 reference list rates in us-east-1, before free allowances, discounts, credits and tax.

Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Kinesis provisioned shards | 10.95 |
| Origin: Kinesis PUT payload units | 3.68 |
| Target: Managed Kafka cluster compute | 197.10 |
| Target: Managed Kafka local disk | 51.00 |
| Target: Selected single-copy long-term storage | 0.88 |
| Target: Managed Kafka inter-zone replication | 5.33 |
| Target: Selected cross-zone client processing | 0.00 |
| **Origin service subtotal** | **14.63** |
| **Target service subtotal** | **254.30** |

Unestimated components: Allocated adapter hosting, Allocated Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled monthly service usage and selected database allocation; adapter hosting and Tensor9 fees only when explicitly supplied.

Excluded costs and workload features:

* Free allowances, negotiated discounts, credits, tax and one-time migration charges.
* Charges not listed in the breakdown, including additional network transfer, backups and encryption/KMS.
* Application compute changes, operational labor and portfolio-wide sharing or deduplication of infrastructure.
* KCL DynamoDB lease-table costs, Connect clusters, extra replication/consumer copies, unsupported resharding behavior and unqualified cluster capacity.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Provisioned Kinesis shard charges | 10.95 | USD/month |
| Kinesis PUT payload charges | 3.6792 | USD/month |
| Representative Kinesis record size | 1,024 | bytes |
| Full-stream consumers | 1 | copies |
| Target record envelope overhead | 64 | bytes/record |
| Managed Kafka cluster vCPUs | 3 | vCPU |
| Managed Kafka cluster memory | 12 | GiB |
| Default-profile local disk allocation | 300 | GiB |
| Long-term storage allocation | 8.75473 | GiB-month |
| Cross-zone client traffic | 0 | GiB/month |

* Provisioned origin shard-hours: 730 shard-hours/month.

* Inferred original stream records: 262,800,000 records/month.

* Steady 24-hour physical retained stream: 8.755 GiB.

* Provisioned Kinesis with 24-hour retention and shared-read consumers; 730 running hours. Google Managed Kafka uses three replicas across zones.

* Cluster allocation pricing only: throughput, peak load, retention suitability and latency remain unqualified. The curve does not resize compute automatically.

* Compute is USD 0.09 per DCU-hour; one vCPU is 0.6 DCU and one GiB RAM is 0.1 DCU. All local disk is charged, plus the explicitly selected single-copy long-term storage allocation.

* Replication transfers two physical copies at USD 0.01/GiB. Same-zone client traffic assumes local follower reads; extra client traffic must be supplied separately.

Rate snapshot: 2026-10-18. Model: `kinesis-managed-kafka` / `2026-10-18.4`. Scenario: `kinesis-managed-kafka-reference`.

Sources: [Kinesis Data Streams provisioned pricing](https://aws.amazon.com/kinesis/data-streams/pricing/), [Google Managed Kafka pricing](https://cloud.google.com/managed-service-for-apache-kafka/pricing), [Managed Kafka capacity configuration](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/create-cluster).

## On OCI

### OCI Streaming

| 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 backend; 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 backend 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 backend 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 backend'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 backend's own: the managed backends 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 backend 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 backend |

#### How it works

Your application keeps calling the Kinesis API, now on the Tensor9 adapter, and the adapter stores the record log on OCI Streaming. Each Kinesis shard maps to a partition there. Partition-key hashing chooses the shard, and the partition's ordered position becomes part of the sequence number the call returns.

Consumers get an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records, and getting an iterator at a retained position lets you replay. These positions belong to the new stream: existing AWS sequence numbers and checkpoints do not point at anything in the new log.

#### Consumer state and capacity

The record log and each consumer's progress are kept separately. Kinesis Client Library (KCL) applications also keep leases and checkpoints in a DynamoDB table. Deploy a compatible DynamoDB adapter with this stream and test how the consumer restarts and reassigns shards; keeping the Kinesis endpoint alone does not provide that table.

Retention is set on OCI Streaming and is limited by the provider's limits in the comparison table. Record size, uneven partitions, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with your own record sizes and partition distribution.

#### Limitations

* **Shard split and merge history is not supported.** The partition count is fixed. Adding partitions changes routing for some keys, so plan that change with your consumers instead of assuming existing shard positions stay valid. - **Enhanced fan-out behaves differently: there is no dedicated throughput per consumer.** It uses consumer groups on OCI Streaming, so that service's capacity applies instead of Kinesis's per-consumer guarantee. - **Moving AWS records, sequence numbers and checkpoints is not supported.** The new stream starts empty, and old positions do not identify records in it.

#### Other considerations

**Before cutover.** Create the stream and the consumer checkpoint store first. Drain the old stream, or publish to both while consumers catch up.

**What to monitor.** Use OCI Streaming partition metrics and adapter metrics to watch reads, writes and lag; AWS CloudWatch series do not move with the stream.

#### Example monthly charges

This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include.

##### Kinesis Data Streams · PUT payload units

Feature: Kinesis Data Streams.

Estimated monthly service charges by PUT payload units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1 (OCI global price list); currency: USD.

![Kinesis Data Streams · PUT payload units: monthly service charges by PUT payload units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/fec647063d65cd4f798fba5dd45d9871a997a5638cf0b2463d3756196fb61520-light.svg)

![Kinesis Data Streams · PUT payload units: monthly service charges by PUT payload units. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/1f8d43f8f2f7a8830e1d6c84185d59da5c8983d6f5493e096d5e82751cdd6255-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| PUT payload units (per second) | Kinesis Data Stream | OCI Streaming | Difference |
| -: | -: | -: | -: |
| 0 | 0.00 | 0.00 | 0.00 |
| 1 | 0.04 | 0.15 | 0.11 |
| 10 | 0.37 | 1.46 | 1.09 |
| 100 | 3.68 | 14.59 | 10.91 |
| 1,000 | 36.79 | 145.93 | 109.13 |
| 10,000 | 367.92 | 1,459.27 | 1,091.35 |

**Curve assumptions**

| Assumption | Value | Unit |
| - | -: | - |
| Origin list price · Provisioned shard-hours | 0.015 | USD/shard-hour |
| Origin list price · PUT payload units | 0.000000014 | USD/25-KiB record units |
| Representative record size | 1,024 | bytes |
| Full-stream consumer copies | 1 | copies |
| Target retained history | 24 | hours |
| Target record envelope | 64 | bytes/record |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target list price · GiB-month | 0.146 | USD/GiB-month |
| Target list price · published GiB | 0.025 | USD/published GiB |
| Target list price · delivered GiB | 0.025 | USD/delivered GiB |
| Target price guess · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |

* Payload size determines physical record and byte throughput. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-ashburn-1 (OCI global price list), USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
* A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
* OCI Streaming bills PUT and GET bytes and retained GB-hours, with no partition charge within the default service limits; beyond them OCI expects at least 10 GB/hour of PUT and GET per 50 partitions. Retention defaults to 24 hours, up to 7 days.
* AWS Price List API, AmazonKinesis offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json)
* OCI price list API: [https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/](https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-9811d8ea456c7e42af3f0509a197ed3539f77d7f` / `2026-10-22.planning.2`. Curve: `workload-1`.

Sources: [AWS Price List API, AmazonKinesis offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json), [OCI price list API](https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/).

##### Kinesis Data Streams · Origin provisioned shards

Feature: Kinesis Data Streams.

Estimated monthly service charges by Origin provisioned shards. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1 (OCI global price list); currency: USD.

![Kinesis Data Streams · Origin provisioned shards: monthly service charges by Origin provisioned shards. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/a8e5a93bb4749a0989affce6f83ebeebcdf417dc218dba1197644f45f472640a-light.svg)

![Kinesis Data Streams · Origin provisioned shards: monthly service charges by Origin provisioned shards. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/68a5ab2602bbaff14291f95f0791014c38f1ec09a3b5e489832e40f29a623e38-dark.svg)

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples.

Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

| Origin provisioned shards (shard-hours/month) | Kinesis Data Stream | OCI Streaming | Difference |
| -: | -: | -: | -: |
| 0 | 0.00 | 0.00 | 0.00 |
| 730 | 10.95 | 0.00 | -10.95 |
| 7,300 | 109.50 | 0.00 | -109.50 |
| 73,000 | 1,095.00 | 0.00 | -1,095.00 |
| 730,000 | 10,950.00 | 0.00 | -10,950.00 |

**Curve assumptions**

| Assumption | Value | Unit |
| - | -: | - |
| Origin list price · Provisioned shard-hours | 0.015 | USD/shard-hour |
| Origin list price · PUT payload units | 0.000000014 | USD/25-KiB record units |
| Representative record size | 1,024 | bytes |
| Full-stream consumer copies | 1 | copies |
| Target retained history | 24 | hours |
| Target record envelope | 64 | bytes/record |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target list price · GiB-month | 0.146 | USD/GiB-month |
| Target list price · published GiB | 0.025 | USD/published GiB |
| Target list price · delivered GiB | 0.025 | USD/delivered GiB |
| Target price guess · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |

* Provisioned capacity alone does not reveal actual record traffic; PUT meter stays independent. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
* Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-ashburn-1 (OCI global price list), USD/month.
* Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
* Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
* Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note.
* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.
* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.
* Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.
* A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.
* OCI Streaming bills PUT and GET bytes and retained GB-hours, with no partition charge within the default service limits; beyond them OCI expects at least 10 GB/hour of PUT and GET per 50 partitions. Retention defaults to 24 hours, up to 7 days.
* AWS Price List API, AmazonKinesis offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json)
* OCI price list API: [https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/](https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/)

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: `plan-9811d8ea456c7e42af3f0509a197ed3539f77d7f` / `2026-10-22.planning.2`. Curve: `workload-2`.

Sources: [AWS Price List API, AmazonKinesis offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json), [OCI price list API](https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/).

**Kinesis Data Streams → OCI Streaming: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.

Scenario source region: us-east-1. Scenario target region: us-ashburn-1 (OCI global price list). Currency: USD.

| Monthly component | USD |
| - | -: |
| Origin: Provisioned shard-hours | 0.00 |
| Origin: PUT payload units | 0.00 |
| Target: Target retained physical data | 0.00 |
| Target: Additional broker replica storage | 0.00 |
| Target: Target ingress events | 0.00 |
| Target: Published bytes | 0.00 |
| Target: Delivered bytes | 0.00 |
| Target: Target native provider operations | 0.00 |
| Target: Execution or worker CPU | 0.00 |
| Target: Execution or worker RAM | 0.00 |
| Target: Selected billable network | 0.00 |
| Target: Independent native resources | 0.00 |
| Target: Independent native resources | 0.00 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **0.00** |

Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.

Excluded costs and workload features:

* Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them.
* Destination application execution and separately billed downstream services; supply those allocations separately.
* Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
* Unmodeled dependent services, task execution and operations outside the selected workload family.

**Scenario assumptions**

| Input | Value | Unit |
| - | -: | - |
| Origin list price · Provisioned shard-hours | 0.015 | USD/shard-hour |
| Origin list price · PUT payload units | 0.000000014 | USD/25-KiB record units |
| Representative record size | 1,024 | bytes |
| Full-stream consumer copies | 1 | copies |
| Target retained history | 24 | hours |
| Target record envelope | 64 | bytes/record |
| Target price guess · read | 0 | USD/read |
| Target price guess · write | 0 | USD/write |
| Target price guess · provider operation | 0 | USD/provider operation |
| Target list price · GiB-month | 0.146 | USD/GiB-month |
| Target list price · published GiB | 0.025 | USD/published GiB |
| Target list price · delivered GiB | 0.025 | USD/delivered GiB |
| Target price guess · network GiB | 0 | USD/network GiB |
| Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Target price guess · vCPU-hour | 0 | USD/vCPU-hour |
| Target price guess · GiB-hour | 0 | USD/GiB-hour |
| Target price guess · resource-hour | 0 | USD/resource-hour |
| Target price guess · resource-month | 0 | USD/resource-month |
| Target price guess · input token | 0 | USD/input token |
| Target price guess · output token | 0 | USD/output token |
| Target monthly base charge | 0 | USD/month |
| Approximate target service minimum | 0 | USD/month |
| Minimum primary CPU | 2 | vCPU |
| Minimum primary RAM | 8 | GiB |
| Minimum primary disk | 100 | GiB |
| Additional full-price standby copy | 0 | 0 or 1 |
| Allocated share of provisioned cost | 1 | fraction |
| Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Planning peak / mean work | 2 | multiplier |
| Planning primary CPU utilization | 0.7 | fraction |
| Resident state reserved in RAM | 0.1 | fraction |
| Planning disk utilization | 0.8 | fraction |
| Maintenance and log disk reserve | 20 | GiB |
| Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Dependent object sink write price guess | 0.000005 | USD/write |
| Provisioned shard-hours | 0 | shard-hour |
| PUT payload units | 0 | 25-KiB record units |

* Translated reads: 0 operations.

* Translated writes: 0 operations.

* Translated resident physical data: 0 GiB-month.

* Native provider operations: 0 operations.

* Published payload: 0 GiB.

* Delivered payload: 0 GiB.

* Allocated execution CPU: 0 vCPU-hour.

* Allocated execution RAM: 0 GiB-hour.

* Independent resource allocation: 0 resource-hour.

* Independent inventory: 0 resource-month.

* Input tokens: 0 tokens.

* Output tokens: 0 tokens.

* Billable network: 0 GiB.

* Dependent object sink retained data: 0 GiB-month.

* Dependent object sink writes: 0 writes.

* Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.

* Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.

* Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.

* Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.

* A declared adapter mapping and cost model do not establish implementation availability or service equivalence.

* This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.

* Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts.

* A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent.

* Retention and consumer copies drive physical work. Origin shard-hours are not proof that a target broker or database meets the same throughput.

* A KCL DynamoDB lease table is a separate workload; enhanced fan-out and extended retention origin prices are outside this provisioned profile.

* OCI Streaming bills PUT and GET bytes and retained GB-hours, with no partition charge within the default service limits; beyond them OCI expects at least 10 GB/hour of PUT and GET per 50 partitions. Retention defaults to 24 hours, up to 7 days.

List prices read: 2026-10-22. Model: `plan-9811d8ea456c7e42af3f0509a197ed3539f77d7f` / `2026-10-22.planning.2`. Scenario: `planning-example`.

Sources: [AWS Price List API, AmazonKinesis offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonKinesis/current/us-east-1/index.json), [OCI price list API](https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/).

## Costs

Estimated monthly service charges for each backend with a published cost model, at one sampled workload from that model's cost curve. Adapter hosting and Tensor9 fees are excluded. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method, what the estimates include and how to read their qualifications.

| Backend | Sampled workload | Price basis | Origin USD/month | Backend USD/month | Difference | Mapping |
| - | - | - | -: | -: | -: | - |
| Azure Event Hubs | PUT payload units: 100 per second | Cited list prices, 2026-10-22 | 3.68 | 29.26 | +25.58 | Service adapter |
| DigitalOcean Managed Kafka | PUT payload units: 100 per second; one copy | Cited list prices, 2026-10-22 | 3.68 | 198.40 | +194.72 | Service adapter |
| Managed Service for Apache Kafka | Provisioned shards: 4 shards; 3 vCPU / 12 GiB | Reference rates, 2026-10-18 | 58.52 | 272.91 | +214.39 | Service adapter |
| OCI Streaming | PUT payload units: 100 per second | Cited list prices, 2026-10-22 | 3.68 | 14.59 | +10.91 | Service adapter |
| Pub/Sub | Provisioned shards: 4 shards; one subscription | Reference rates, 2026-10-18 | 58.52 | 92.67 | +34.15 | Service adapter |
| Strimzi Kafka | PUT payload units: 100 per second; one copy | Cited list prices, 2026-10-22 | 3.68 | 80.90 | +77.22 | Service adapter |

Difference means backend minus origin; a positive difference means the backend costs more. Workloads and target configurations differ by model, so compare each row's difference at its stated workload rather than charges across rows.
Cost curves across workload sizes, with every assumption and exclusion: [Amazon Kinesis costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/kinesis.md).

## Service level agreements

> [!WARNING]
>
> These tables show Tensor9's standard service levels and adapters whose standard terms are still being defined. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment.

Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider's own SLA. Each origin-to-target pair has its own terms or an explicit pending status.

See the [SLA tables](https://docs.tensor9.com/cloud-adapter-early-access/support/service-adapter-slas.md), [measurement rules](https://docs.tensor9.com/cloud-adapter-early-access/support/service-levels.md), and [scaling conditions](https://docs.tensor9.com/cloud-adapter-early-access/support/scaling-and-limits.md).

### Kinesis Data Stream to Azure Event Hubs

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Small record append and iterator requests adapter-added latency | +3 ms monthly p99 | `aws::1.0.0::kinesis`: `GetShardIterator`, `PutRecord` | One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class. |
| Bounded record batch and read page adapter-added latency | +10 ms monthly p99 | `aws::1.0.0::kinesis`: `GetRecords`, `PutRecords` | At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained. |
| Stream configuration requests adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::kinesis`: `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `MergeShards`, `RegisterStreamConsumer`, `SplitShard`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateShardCount`, `UpdateStreamMode` | One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::kinesis`: `GetShardIterator`, `PutRecord`, `GetRecords`, `PutRecords`, `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `MergeShards`, `RegisterStreamConsumer`, `SplitShard`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateShardCount`, `UpdateStreamMode` | For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store's retention are separate responsibilities. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

For `azure::1.0.0::eventhubs`, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter's iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.

#### How the latency targets were chosen

**Small record append and iterator requests: +3 ms monthly p99 (adapter-added).** `GetShardIterator`, `PutRecord`. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations.

**Bounded record batch and read page: +10 ms monthly p99 (adapter-added).** `GetRecords`, `PutRecords`. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes.

**Stream configuration requests: +20 ms monthly p99 (adapter-added).** `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `MergeShards`, `RegisterStreamConsumer`, `SplitShard`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateShardCount`, `UpdateStreamMode`. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom.

Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

#### Data and behavior guarantees

For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store's retention are separate responsibilities.

#### Example and diagnosis

For stream `order-log`, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path.

Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

### Kinesis Data Stream to DigitalOcean Managed Kafka

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Small record append and iterator requests adapter-added latency | +3 ms monthly p99 | `aws::1.0.0::kinesis`: `GetShardIterator`, `PutRecord` | One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class. |
| Bounded record batch and read page adapter-added latency | +10 ms monthly p99 | `aws::1.0.0::kinesis`: `GetRecords`, `PutRecords` | At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained. |
| Stream configuration requests adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::kinesis`: `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `MergeShards`, `RegisterStreamConsumer`, `SplitShard`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateShardCount`, `UpdateStreamMode` | One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::kinesis`: `GetShardIterator`, `PutRecord`, `GetRecords`, `PutRecords`, `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `MergeShards`, `RegisterStreamConsumer`, `SplitShard`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateShardCount`, `UpdateStreamMode` | For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store's retention are separate responsibilities. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

For `digitalocean::1.0.0::database::kafka`, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter's iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.

#### How the latency targets were chosen

**Small record append and iterator requests: +3 ms monthly p99 (adapter-added).** `GetShardIterator`, `PutRecord`. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations.

**Bounded record batch and read page: +10 ms monthly p99 (adapter-added).** `GetRecords`, `PutRecords`. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes.

**Stream configuration requests: +20 ms monthly p99 (adapter-added).** `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `MergeShards`, `RegisterStreamConsumer`, `SplitShard`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateShardCount`, `UpdateStreamMode`. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom.

Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

#### Data and behavior guarantees

For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store's retention are separate responsibilities.

#### Example and diagnosis

For stream `order-log`, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path.

Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

### Kinesis Data Stream to Managed Service for Apache Kafka

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Small record append and iterator requests adapter-added latency | +3 ms monthly p99 | `aws::1.0.0::kinesis`: `GetShardIterator`, `PutRecord` | One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class. |
| Bounded record batch and read page adapter-added latency | +10 ms monthly p99 | `aws::1.0.0::kinesis`: `GetRecords`, `PutRecords` | At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained. |
| Stream configuration requests adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::kinesis`: `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `MergeShards`, `RegisterStreamConsumer`, `SplitShard`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateShardCount`, `UpdateStreamMode` | One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::kinesis`: `GetShardIterator`, `PutRecord`, `GetRecords`, `PutRecords`, `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `MergeShards`, `RegisterStreamConsumer`, `SplitShard`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateShardCount`, `UpdateStreamMode` | For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store's retention are separate responsibilities. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

For `google::1.0.0::managed-kafka`, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter's iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.

#### How the latency targets were chosen

**Small record append and iterator requests: +3 ms monthly p99 (adapter-added).** `GetShardIterator`, `PutRecord`. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations.

**Bounded record batch and read page: +10 ms monthly p99 (adapter-added).** `GetRecords`, `PutRecords`. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes.

**Stream configuration requests: +20 ms monthly p99 (adapter-added).** `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `MergeShards`, `RegisterStreamConsumer`, `SplitShard`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateShardCount`, `UpdateStreamMode`. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom.

Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

#### Data and behavior guarantees

For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store's retention are separate responsibilities.

#### Example and diagnosis

For stream `order-log`, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path.

Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

### Kinesis Data Stream to Pub/Sub

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Small record append and iterator requests adapter-added latency | +3 ms monthly p99 | `aws::1.0.0::kinesis`: `GetShardIterator`, `PutRecord` | One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class. |
| Bounded record batch and read page adapter-added latency | +10 ms monthly p99 | `aws::1.0.0::kinesis`: `GetRecords`, `PutRecords` | At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained. |
| Stream configuration requests adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::kinesis`: `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `RegisterStreamConsumer`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateStreamMode` | One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::kinesis`: `GetShardIterator`, `PutRecord`, `GetRecords`, `PutRecords`, `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `RegisterStreamConsumer`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateStreamMode` | For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store's retention are separate responsibilities. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

For `google::1.0.0::pubsub`, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter's iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.

#### How the latency targets were chosen

**Small record append and iterator requests: +3 ms monthly p99 (adapter-added).** `GetShardIterator`, `PutRecord`. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations.

**Bounded record batch and read page: +10 ms monthly p99 (adapter-added).** `GetRecords`, `PutRecords`. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes.

**Stream configuration requests: +20 ms monthly p99 (adapter-added).** `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `RegisterStreamConsumer`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateStreamMode`. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom.

Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

#### Data and behavior guarantees

For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store's retention are separate responsibilities.

#### Example and diagnosis

For stream `order-log`, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path.

Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

### Kinesis Data Stream to OCI Streaming

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Small record append and iterator requests adapter-added latency | +3 ms monthly p99 | `aws::1.0.0::kinesis`: `GetShardIterator`, `PutRecord` | One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class. |
| Bounded record batch and read page adapter-added latency | +10 ms monthly p99 | `aws::1.0.0::kinesis`: `GetRecords`, `PutRecords` | At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained. |
| Stream configuration requests adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::kinesis`: `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `MergeShards`, `RegisterStreamConsumer`, `SplitShard`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateShardCount`, `UpdateStreamMode` | One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::kinesis`: `GetShardIterator`, `PutRecord`, `GetRecords`, `PutRecords`, `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `MergeShards`, `RegisterStreamConsumer`, `SplitShard`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateShardCount`, `UpdateStreamMode` | For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store's retention are separate responsibilities. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

For `oci::1.0.0::streaming`, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter's iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.

#### How the latency targets were chosen

**Small record append and iterator requests: +3 ms monthly p99 (adapter-added).** `GetShardIterator`, `PutRecord`. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations.

**Bounded record batch and read page: +10 ms monthly p99 (adapter-added).** `GetRecords`, `PutRecords`. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes.

**Stream configuration requests: +20 ms monthly p99 (adapter-added).** `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `MergeShards`, `RegisterStreamConsumer`, `SplitShard`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateShardCount`, `UpdateStreamMode`. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom.

Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

#### Data and behavior guarantees

For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store's retention are separate responsibilities.

#### Example and diagnosis

For stream `order-log`, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path.

Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

### Kinesis Data Stream to Strimzi Kafka

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Small record append and iterator requests adapter-added latency | +3 ms monthly p99 | `aws::1.0.0::kinesis`: `GetShardIterator`, `PutRecord` | One record at most 4 KiB and partition key at most 256 bytes, or one iterator request. Stream/shard catalog is bounded; no resharding in progress for this class. |
| Bounded record batch and read page adapter-added latency | +10 ms monthly p99 | `aws::1.0.0::kinesis`: `GetRecords`, `PutRecords` | At most 100 records and 400 KiB aggregate data in one batch or page. Partial append results and cursor ordering are retained. |
| Stream configuration requests adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::kinesis`: `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `MergeShards`, `RegisterStreamConsumer`, `SplitShard`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateShardCount`, `UpdateStreamMode` | One stream with at most 100 shards, or one page of at most 100 streams. Measures API response/acceptance, not completion of resharding, retention cleanup or encryption changes. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::kinesis`: `GetShardIterator`, `PutRecord`, `GetRecords`, `PutRecords`, `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `MergeShards`, `RegisterStreamConsumer`, `SplitShard`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateShardCount`, `UpdateStreamMode` | For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store's retention are separate responsibilities. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |

**Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

For `strimzi::1.0.0::kafka`, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter's iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.

#### How the latency targets were chosen

**Small record append and iterator requests: +3 ms monthly p99 (adapter-added).** `GetShardIterator`, `PutRecord`. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations.

**Bounded record batch and read page: +10 ms monthly p99 (adapter-added).** `GetRecords`, `PutRecords`. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes.

**Stream configuration requests: +20 ms monthly p99 (adapter-added).** `CreateStream`, `DecreaseStreamRetentionPeriod`, `DeleteStream`, `DescribeStream`, `IncreaseStreamRetentionPeriod`, `MergeShards`, `RegisterStreamConsumer`, `SplitShard`, `StartStreamEncryption`, `StopStreamEncryption`, `UpdateShardCount`, `UpdateStreamMode`. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy.

Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

#### Scaling and target-service capacity

Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom.

Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

#### Data and behavior guarantees

For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store's retention are separate responsibilities.

#### Example and diagnosis

For stream `order-log`, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path.

Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

## Install and run

The documentation and SLAs are public. Downloading and running the Cloud Adapter binary requires an entitled customer account. Set `T9_API_KEY` as described in [Install and Authenticate](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/install-and-authenticate.md), then list the adapters your account may use with this origin:

```sh theme={null}
tensor9 adapt svc list \
  -origin aws::1.0.0::kinesis::stream
```

The result is limited to directed mappings for this origin that your account is entitled to use. Use a returned backend identifier when configuring the adapter or investigating a request.

Request binary access from [hello@tensor9.com](mailto:hello@tensor9.com) if your account does not yet include this direction.

## Existing data and credentials

Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application's endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.

## Configure, tune and debug

Start with [setup](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/overview.md) and [configuration](https://docs.tensor9.com/cloud-adapter-early-access/configuration/overview.md). Use [tuning](https://docs.tensor9.com/cloud-adapter-early-access/tuning/overview.md) to understand supported request tags, [debugging](https://docs.tensor9.com/cloud-adapter-early-access/debugging/overview.md) to investigate a request, and [High Fidelity Cloud Emulators](https://docs.tensor9.com/cloud-adapter-early-access/local-testing/overview.md) to validate a bounded reproduction.

For requests that go through an entitled service adapter, use [tensor9 explain](https://docs.tensor9.com/cloud-adapter-early-access/debugging/explain.md) and [x-t9-explain](https://docs.tensor9.com/cloud-adapter-early-access/debugging/response-headers.md) to inspect the selected mapping.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.