- Coverage by target cloud
- How the targets compare
- On Google Cloud and Private Kubernetes
- On Google Cloud
- On Azure
- On OCI
- On Private Kubernetes
Coverage by target cloud
How the targets compare
Each row compares a capability of MSK (Kafka) with its adaptation on each target. A dash means this row is not stated for that target.Infrastructure-only adaptation
On Google Cloud and Private Kubernetes
Via Strimzi Kafka
Connecting Kafka clients to Apache Kafka on Kubernetes cluster (via the Strimzi operator)
Producers and consumers connect directly to Apache Kafka on Kubernetes cluster (via the Strimzi operator) using the Kafka protocol. Tensor9 supplies the target bootstrap endpoint; there is no Tensor9 message proxy between client and broker. Broker metadata can return additional advertised addresses, so clients need network access and TLS trust for those addresses as well as the bootstrap address. Authentication changes with the broker: SASL/SCRAM and mutual TLS are supported. Replace MSK IAM authentication and manage the broker’s access-control lists. Check producer acknowledgment, idempotence and transaction settings against the target-specific support table. A Kafka-compatible endpoint does not by itself guarantee every Kafka administrative or transactional feature.State and operating responsibility
You configure the replication factor and minimum in-sync replicas (ISR), monitor replica health, and operate storage, recovery and upgrades. Topic partitions hold the retained log and consumer-group offsets record progress. A new broker does not contain the source records, offsets or consumer-group state. Coordinate producer and consumer cutover, and use a separately planned replication process if retained history must move. Source offsets cannot be applied blindly to a different log. Review topic creation, retention, partition counts and broker configuration on the target. AWS IAM authentication, MSK Connect and Glue Schema Registry require separate decisions; changing bootstrap servers does not replace those dependencies. Configure the target’s monitoring, backup or recovery procedures and certificate rotation before production cutover. Performance depends on the chosen broker, storage and workload; this profile has no Tensor9 broker benchmark.Via Bitnami Kafka
Connecting Kafka clients to Apache Kafka on Kubernetes cluster (via the Bitnami Kafka chart)
Producers and consumers connect directly to Apache Kafka on Kubernetes cluster (via the Bitnami Kafka chart) using the Kafka protocol. Tensor9 supplies the target bootstrap endpoint; there is no Tensor9 message proxy between client and broker. Broker metadata can return additional advertised addresses, so clients need network access and TLS trust for those addresses as well as the bootstrap address. Authentication changes with the broker: SASL/SCRAM and mutual TLS are supported. Replace MSK IAM authentication and manage the broker’s access-control lists. Check producer acknowledgment, idempotence and transaction settings against the target-specific support table. A Kafka-compatible endpoint does not by itself guarantee every Kafka administrative or transactional feature.State and operating responsibility
You configure the replication factor and minimum in-sync replicas (ISR), monitor replica health, and operate storage, recovery and upgrades. Topic partitions hold the retained log and consumer-group offsets record progress. A new broker does not contain the source records, offsets or consumer-group state. Coordinate producer and consumer cutover, and use a separately planned replication process if retained history must move. Source offsets cannot be applied blindly to a different log. Review topic creation, retention, partition counts and broker configuration on the target. AWS IAM authentication, MSK Connect and Glue Schema Registry require separate decisions; changing bootstrap servers does not replace those dependencies. Configure the target’s monitoring, backup or recovery procedures and certificate rotation before production cutover. Performance depends on the chosen broker, storage and workload; this profile has no Tensor9 broker benchmark.On Google Cloud
Via Managed Service for Apache Kafka
Connecting Kafka clients to Google Managed Service for Apache Kafka
Producers and consumers connect directly to Google Managed Service for Apache Kafka using the Kafka protocol. Tensor9 supplies the target bootstrap endpoint; there is no Tensor9 message proxy between client and broker. Broker metadata can return additional advertised addresses, so clients need network access and TLS trust for those addresses as well as the bootstrap address. Authentication changes with the broker: clients authenticate through Google Cloud IAM over SASL_SSL/OAUTHBEARER; MSK IAM, SASL/SCRAM, and mTLS each need a one-time client-side handler and credential swap. Check producer acknowledgment, idempotence and transaction settings against the target-specific support table. A Kafka-compatible endpoint does not by itself guarantee every Kafka administrative or transactional feature.State and operating responsibility
Google operates durability and HA; capacity is cluster-wide vCPU/memory rather than a broker instance type you pick, and the cluster is reachable only inside your VPC. Topic partitions hold the retained log and consumer-group offsets record progress. A new broker does not contain the source records, offsets or consumer-group state. Coordinate producer and consumer cutover, and use a separately planned replication process if retained history must move. Source offsets cannot be applied blindly to a different log. Review topic creation, retention, partition counts and broker configuration on the target. AWS IAM authentication, MSK Connect and Glue Schema Registry require separate decisions; changing bootstrap servers does not replace those dependencies. Configure the target’s monitoring, backup or recovery procedures and certificate rotation before production cutover. Performance depends on the chosen broker, storage and workload; this profile has no Tensor9 broker benchmark.On Azure
How it works
Your Kafka client connects directly to Azure Event Hubs at<namespace>.servicebus.windows.net:9093. Standard and Premium tiers expose this Kafka endpoint. Produce and consume code remain unchanged; configure the new bootstrap address and credentials. Tensor9 does not proxy these connections.
Event Hubs differs from Kafka in administration, transactions, authentication and capacity settings. Review those differences below before selecting this target.
Estimating namespace capacity
MSK capacity is declared as a broker count and instance type, with storage and placement per broker. Event Hubs capacity is set on a namespace using throughput units or processing units. Tensor9 estimates namespace capacity from broker count multiplied by vCPUs per broker. Brokers with at least 16 vCPUs each, such askafka.m5.4xlarge, select Premium processing units. Smaller brokers select Standard throughput units. Basic is excluded because it has no Kafka endpoint.
The conversion is reported as a lossy translation because machine size does not determine your workload’s messaging throughput. Load-test the generated capacity and adjust it using measured traffic.
Provision topics as Event Hubs
The generated Terraform creates the namespace. It creates no Event Hubs because an MSK cluster resource does not declare topics: Kafka topics are created by producers or administrators at runtime.aws_msk_configuration contains server.properties settings, not a topic list.
Each Kafka topic needs an Event Hub inside the namespace. Provision these before producing messages; this target does not create them automatically on first use.
Configure authentication
Configure clients to use an Event Hubs Shared Access Signature (SAS) policy or Microsoft Entra identity. MSK’s SASL/SCRAM, mutual TLS and IAM configurations do not transfer directly. Namespace authentication is configured separately from the generated stack. Credentials use the appliance’s secrets mechanism; the generated Terraform contains no SAS key or connection string. Event Hubs requires TLS and encrypts stored data by default, so MSK’sencryption_info is not translated. Configure a customer-managed encryption key separately on Azure if required.
Limitations
△ Where MSK and Event Hubs diverge, read before you adopt- Transactions and exactly-once are not complete. Produce and consume over the Kafka wire are unchanged, but the Event Hubs Kafka surface does not offer full Kafka transaction and idempotent-producer semantics. An application that relies on exactly-once delivery through Kafka transactions needs these limitations resolved before it can use this target.
- Partition count is fixed at creation on Standard. On Standard, an Event Hub’s partition count is set when it is created and cannot be changed afterwards. Premium and Dedicated allow increasing it (but never decreasing), which is what Kafka itself allows. Size partitions for the consumer parallelism you expect to need, because on Standard the only way to change your mind is a new hub.
- Capacity and partitions are sized independently. On Kafka, partitions set both parallelism and much of your throughput headroom. On Event Hubs, throughput is bought separately as throughput units (Standard) or processing units (Premium), independent of partition count. Sizing one does not size the other, and a partition count copied across from MSK does not bring its throughput with it.
- Consumer-group offsets live in a different store. Event Hubs keeps its own consumer-group offset store rather than Kafka’s
__consumer_offsetstopic. Committing and reading offsets works through the Kafka client as usual; tooling that reads the offsets topic directly, or that reasons about its retention and compaction, does not port. - Kafka administration is only partly supported. Topics are Event Hubs, created up front, and the broker-administration and ACL surface differs from Kafka’s. Code that provisions topics or manages ACLs through AdminClient at runtime should be treated as needing rework rather than assumed to work.
- There is no Kafka version to pin. MSK’s
kafka_versionhas no counterpart: Event Hubs tracks its own supported Kafka protocol version and you do not choose or freeze it. A stack that pins a version for compatibility reasons is relying on something this target cannot promise. - Custom server.properties do not transfer. MSK’s
configuration_info(retention hours, default partition counts and the rest ofserver.properties) has no namespace-level equivalent. The settings that do exist live per Event Hub and are tuned after provisioning, so a carefully tuned cluster configuration is re-expressed rather than migrated. - Broker placement across availability zones has no analog. An Event Hubs namespace is a regional service with no brokers to place, so MSK’s per-broker subnet and availability-zone distribution has nothing to map onto. If your MSK topology was chosen for zone-level placement, that reasoning does not transfer.
Other considerations
- Update client endpoint and authentication. Repoint the bootstrap servers at the namespace’s Kafka endpoint on port 9093 and switch the SASL configuration to a SAS policy or a Microsoft Entra identity. Produce and consume paths, serializers and partitioning logic remain unchanged.
- Data does not migrate; the namespace starts empty. Provisioning creates a fresh namespace. Messages still in MSK do not move, and Kafka’s retention means the window is finite anyway, so plan a cutover in which producers switch over and consumers drain the old cluster, rather than expecting a copy.
- Capacity is the number to revisit after launch. The emitted SKU and capacity are estimated from your broker fleet, not measured from your traffic. Watch throughput-unit utilisation once real load arrives; Standard’s throughput units and Premium’s processing units are both adjustable.
- Naming is deterministic, so re-planning is stable. The namespace name derives from the stack’s persisted logical identity and the original cluster name, so the same stack compiles to the same namespace every time. A re-plan does not propose replacing infrastructure that has not changed.