MSK Connect: How Managed Kafka Connect on AWS Works and What It Costs

Kafka Connect is how most teams move data between Apache Kafka and databases, object stores and search indexes. Running the Connect workers yourself means patching JVMs, sizing clusters and chasing rebalances. Amazon MSK Connect hands that work to AWS, at a price and with some constraints.

This guide explains what MSK Connect is, how to deploy a connector, how the pricing works, where the limits are and when self-hosting is the better choice. Facts come from the AWS MSK Connect developer guide and the Amazon MSK pricing page, checked on 3 November 2026.

What is MSK Connect?

MSK Connect is a feature of Amazon MSK that runs open-source Kafka Connect for you. AWS currently offers two Kafka Connect versions: 2.7.1 and 3.7.x. You bring the connector code, and AWS provisions, patches, monitors and scales the workers that run it.

It works with more than MSK. According to the AWS documentation, MSK Connect supports any Apache Kafka cluster with connectivity to an Amazon VPC. That includes MSK clusters and independently hosted Kafka clusters.

Four resources make up a deployment:

• Custom plugin: a JAR, or a ZIP of JARs, uploaded to Amazon S3. It holds the connector logic, such as Debezium or an S3 sink.
• Worker configuration: optional worker-level settings, such as converters. AWS provides a default that uses StringConverter for keys and values.
• Connector: the connector configuration, its capacity, the target cluster and the VPC subnets it runs in.
• Service execution role: the IAM role the connector uses to reach other AWS resources, such as an S3 bucket.

A worker is a JVM process that runs the connector logic. Each worker runs tasks in parallel threads. Workers coordinate through Kafka consumer groups and rebalance tasks when one joins or leaves. MSK Connect also restarts failed tasks automatically.

How do you deploy a connector on MSK Connect?

The getting started guide follows five steps:

1. Package the plugin. Build a ZIP of all required JARs, or a single uber JAR. AWS recommends bundling every dependency, because missing ones cause runtime errors.
2. Upload it to S3 and create a custom plugin. MSK Connect copies the object at creation time. Later changes to the S3 object do not affect the plugin.
3. Create a worker configuration if the defaults do not suit you. Most teams set JSON or Avro converters here.
4. Create the IAM service execution role with permissions for whatever the connector touches.
5. Create the connector with its configuration, capacity, cluster details and VPC subnets and security groups.

With the AWS CLI, the kafkaconnect commands cover each step. The connector call looks like this:

aws kafkaconnect create-custom-plugin \
  --name s3-sink-plugin \
  --content-type ZIP \
  --location '{"s3Location":{"bucketArn":"arn:aws:s3:::my-plugins","fileKey":"s3-sink.zip"}}'

aws kafkaconnect create-connector \
  --connector-name orders-to-s3 \
  --kafka-connect-version "3.7.x" \
  --capacity '{"autoScaling":{"minWorkerCount":1,"maxWorkerCount":4,"mcuCount":1,"scaleInPolicy":{"cpuUtilizationPercentage":20},"scaleOutPolicy":{"cpuUtilizationPercentage":80}}}' \
  --connector-configuration file://connector.json \
  --kafka-cluster '{"apacheKafkaCluster":{"bootstrapServers":"b-1.example:9098","vpc":{"subnets":["subnet-a","subnet-b"],"securityGroups":["sg-123"]}}}' \
  --kafka-cluster-client-authentication '{"authenticationType":"IAM"}' \
  --kafka-cluster-encryption-in-transit '{"encryptionType":"TLS"}' \
  --plugins '[{"customPlugin":{"customPluginArn":"arn:aws:kafkaconnect:...","revision":1}}]' \
  --service-execution-role-arn arn:aws:iam::123456789012:role/msk-connect-s3

Each worker takes one IP address from the subnets you provide. With autoscaling, plan for the maximum worker count, not the minimum.

You choose one of two capacity modes. Provisioned fixes the number of workers and MCUs per worker. Autoscaled sets a minimum and maximum worker count and scales on the CpuUtilization metric. In autoscaled mode, MSK Connect overrides your connector’s tasks.max. An optional maximum autoscaling task count caps the tasks, which helps when partitions are limited.

How does MSK Connect pricing work?

You pay for MCU-hours, billed per second. Each MCU provides 1 vCPU and 4 GB of memory, according to the Amazon MSK pricing page. A worker can have 1, 2, 4 or 8 MCUs. Your bill is workers multiplied by MCUs per worker multiplied by the hours they run.

AWS’s own example uses a rate of $0.11 per MCU-hour in US East (N. Virginia). Rates vary by Region, so check the pricing table for yours.

The AWS example scales out to four workers for an eight-hour working day and drops to two overnight. The first two rows are our own arithmetic at the same rate.

The MCU charge is not the whole bill. Standard AWS charges still apply for data transfer and for the log destination you choose. The Kafka cluster itself is billed separately.

Three things drive the cost up. Large connectors need more MCUs per worker. Autoscaling bills you for the extra workers while they run. Many small connectors each need at least one worker, so ten connectors cost at least ten MCUs around the clock.

Key takeaway: MSK Connect removes Connect worker operations on AWS; self-host on Strimzi when you need more control over plugins, versions or cost.

For plain Kafka-to-S3 delivery, compare MSK Connect with Amazon MSK’s newer data delivery feature on Express brokers. AWS charges for it by data volume, with no connector, worker or MCU fees. Its pricing example uses $8 per TB delivered to general purpose S3 buckets.

What are MSK Connect’s limits?

MSK Connect trades control for convenience. These are the limits that matter most in production, taken from the AWS developer guide.

The version list is the first thing to check. Your connector must run on the Java runtime for its Connect version. Features from newer Apache Kafka Connect releases are not available until AWS adds a version.

Authentication is the second. The cluster connection supports only IAM or no authentication. A cluster that relies on SASL/SCRAM or mutual TLS needs a different route.

Updates have improved. The update-connector command can now change capacity, the plugin, the worker configuration or the connector configuration. You can change the worker settings or the connector configuration in one request, but not both. By default, a failed health check rolls the update back.

The quotas are per account and per Region. You can ask AWS to raise them, but the 10-workers-per-connector limit shapes how far one connector can scale out.

When should you self-host Kafka Connect instead?

Self-hosting makes sense when the limits above get in the way. The most common setup on AWS is Kafka Connect on Amazon EKS, managed by the Strimzi operator. Strimzi runs Connect clusters and connectors as Kubernetes resources, so they follow the same GitOps path as your other workloads.

Consider self-hosting when:

• You need a newer Connect version than 3.7.x, or features from recent Kafka releases.
• Your cluster uses SASL/SCRAM or mTLS, which MSK Connect cannot use.
• You run many connectors. One self-hosted Connect cluster can run many connectors on shared workers, rather than paying for workers per connector.
• You want one deployment standard for connectors across every environment, including outside AWS.
• You need your own observability stack, with logging and metrics set up your way.

Self-hosting has its own cost. You own upgrades, JVM tuning, rebalances and plugin dependency conflicts. Connector sprawl is a real risk: our post on reducing connector sprawl describes teams running fifteen to twenty connector JARs in one Connect cluster.

Hyperoptic made this move. Its brokers stayed on Amazon MSK, but OSO engineers moved its connectors from MSK Connect to self-hosted Kafka Connect on Strimzi. Today it runs more than 20 connectors with one deployment standard across environments.

A sensible rule is to start with MSK Connect for a handful of standard connectors on IAM-authenticated clusters. Move to Strimzi when versions, authentication or the number of connectors push against its limits. If you want help with either path, our Kafka support team runs both in production.

Frequently asked questions