The best Kafka tool for Amazon MSK Connect is one that calls the MSK Connect API rather than a Kafka Connect REST endpoint that MSK Connect does not expose, signs in to AWS with the instance role or a role in another account, shows each connector beside the topics and consumer groups it uses, decides per person who may create, change or delete a connector whose configuration holds credentials and records who did, and runs as one container in your own VPC, out of the data path. Kpow, the MSK console with the AWS CLI and CloudWatch, Kafbat UI, AKHQ, Lenses, Redpanda Console and Conduktor each cover part of that, and only Kpow and AWS’s own tools reach MSK Connect connectors at all. Scored on the six weighted criteria explained below the rankings, Kpow ranks first with 105 out of 120, ahead of the MSK console, AWS CLI and CloudWatch at 91 and Kafbat UI at 63; Conduktor, listed last, totals 54.
Tools compared
| Rank | Tool | Total (out of 120) | Out of the data path | MSK Connect operations | Production access on request | Audit trail per person | Directory and Kafka sign-in | Many teams, shared clusters | Cost a year, one cluster (modelled) |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Kpow | 105 | One container, no external database, not a proxy | MSK Connect API, cross-account STS, beside topics; no restart call | Temporary policies, staged approvals, masking | Every action and data read, by user | SAML, OpenID, LDAP | Tenants per team, connectors included | $7,380 |
| 2 | MSK console, AWS CLI and CloudWatch | 91 | Nothing to deploy | Every operation incl. restart, per account and region | IAM per connector ARN, no approvals | CloudTrail by IAM identity | Your AWS identity | IAM scoping, no team view | $11,520 |
| 3 | Kafbat UI | 63 | One container | Not reachable; consumer groups only | Read-only clusters, no approvals | Opt-in log, no view in the product | OAuth2, OIDC, LDAP | Roles per resource | $8,640 |
| 4 | AKHQ | 55 | One container | Not reachable; consumer groups only | Group roles, no approvals | Opt-in topic, no reads | LDAP, OIDC | Regex groups | $8,640 |
| 5 | Lenses | 50 | HQ on PostgreSQL plus an agent per cluster | Not described; consumer groups only | Global masking, no approvals | In-product audit log | SSO from Team tier | Group roles | $6,880 for 15 users; custom above |
| 6 | Redpanda Console | 45 | One container | Not reachable; consumer groups only | None in the free build; RBAC licensed | No record on non-Redpanda brokers | OIDC (Enterprise) | One cluster per deployment | $8,640 plus an unpublished licence for sign-in and RBAC |
| 7 | Conduktor | 54 | Console on PostgreSQL; Gateway, a proxy, for data-level controls | On its roadmap; consumer groups only | Masking exemptions, owner approval | 70+ event types in the UI | LDAP, OIDC | Groups; Virtual Clusters need Gateway | $32,880; $122,880 with Gateway Core and Protect |
The tools, ranked for Amazon MSK Connect
Rank 1 Kpow
105 out of 120 Total
Try Kpow in the live demo No signup needed.
- Cost a year
- $4,500 per Kafka cluster with 100 users included, plus about $2,880 in operator time, so $7,380 on one cluster (modelled)
- On MSK Connect
- The MSK Connect API through the AWS SDK, in Community Edition and Enterprise
- Deployment
- One container or JAR, no external database
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- MSK Connect operations ×3 weight, this criterion counts 3 times toward the total
- 8 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Directory and Kafka sign-in
- 9 out of 10
- Many teams, shared clusters
- 9 out of 10
Why these scores for Kpow
- Out of the data path 9 out of 10
- It is one container or JAR whose snapshots, metrics and audit log live in topics on your own cluster, and it reaches MSK Connect through the AWS API and Kafka as an ordinary client, so nothing sits between your connectors and the brokers.
- MSK Connect operations 8 out of 10
- Its documentation describes a view of connector and task status, configuration and metrics through the MSK Connect API, IAM policies for creating, updating and deleting connectors, the default credentials chain, static keys or an STS role in another account, and a region per numbered environment, so connectors in several accounts sit beside the topics they use; it is held below the AWS console because its documentation does not describe the RestartConnector operation AWS added in August 2026.
- Production access on request 9 out of 10
- Temporary policies grant time-boxed access that an admin or a change system calling the Kpow API can create, staged mutations hold any action for approval, and data policies mask fields in inspection, though masking is per resource rather than per viewer.
- Audit trail per person 9 out of 10
- Every action is recorded with the user from the identity provider and the policy that allowed it, including data inspect queries, with a seven-day view in the product, the record written to an audit topic on your own cluster, and webhooks that send it to a SIEM for long-term retention.
- Directory and Kafka sign-in 9 out of 10
- People sign in with SAML, OpenID or LDAP, and Kpow connects to Kafka with the same SASL or TLS settings as any client and to MSK Connect with an IAM principal through the AWS SDK.
- Many teams, shared clusters 9 out of 10
- Tenants scope each team to its own topics, consumer groups and connectors on a shared cluster, and RBAC adds Allow, Deny or Stage per action.
On MSK Connect. Kpow’s MSK Connect documentation covers authentication through the AWS SDK with the default credentials provider chain, static keys set as CONNECT_ACCESS_KEY_ID and CONNECT_SECRET_ACCESS_KEY, or an STS role in another account set with CONNECT_STS_ROLE_ARN, the required CONNECT_AWS_REGION, and two example IAM policies: admin access to every MSK Connect resource in a region, or discovery of everything with changes limited to a list of connector ARNs. MSK Connect support arrived in Kpow 89.1, cross-account STS in 93.1, and the Community Edition setup wizard configures MSK Connect since 90.4.
Where it falls short. Its documentation does not describe calling RestartConnector, so a restart of an MSK Connect connector still goes through the MSK console, the AWS CLI or the SDK. Kpow governs people working through Kpow, so IAM still decides what anyone with console or CLI access can do to the same connectors. RBAC, masking, staged mutations and the full audit log need Kpow Enterprise; Community Edition is free for 3 clusters and 10 users.
Compare Kpow vs Kafbat UIKpow vs AKHQ
Rank 2 MSK console, AWS CLI and CloudWatch
91 out of 120 Total
- Cost a year
- $0 licence and nothing to run; scripting the CLI and reading logs is modelled at 8 hours a month, $11,520 (modelled)
- On MSK Connect
- Every MSK Connect API operation, per account and region
- Deployment
- Nothing to deploy
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 10 out of 10
- MSK Connect operations ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 7 out of 10
- Directory and Kafka sign-in
- 7 out of 10
- Many teams, shared clusters
- 5 out of 10
Why these scores for MSK console, AWS CLI and CloudWatch
- Out of the data path 10 out of 10
- There is nothing to deploy and nothing between the workers and the brokers, since this is AWS’s own control plane, which makes it the best on this criterion.
- MSK Connect operations 9 out of 10
- It is the native surface for every MSK Connect operation, including RestartConnector with only the failed tasks, the history of connector operations, and CloudWatch metrics such as ErroredTaskCount, but each account and region is reached separately, and none of it is joined to the topics and consumer groups the connectors use.
- Production access on request 4 out of 10
- IAM policies can limit each principal’s MSK Connect actions to named connector ARNs, and AWS supports temporary elevated access through roles, but nothing holds a connector deletion for a second person’s approval and nothing masks a field.
- Audit trail per person 7 out of 10
- CloudTrail records each MSK Connect API call with the identity that made it, which names the person when engineers use their own federated role, though reading the trail means CloudTrail or a query over the logs rather than a connector’s own history.
- Directory and Kafka sign-in 7 out of 10
- People use their own AWS identity, federated from the company directory where the account is set up that way, though the console does not connect to Kafka as a client.
- Many teams, shared clusters 5 out of 10
- IAM policies can scope a role to connector ARNs matching a team’s names, but there is no view of a team’s own connectors, topics and groups together.
What it covers. The MSK Connect API creates, describes, updates, restarts and deletes connectors, custom plugins and worker configurations, and DescribeConnector returns one state per connector: RUNNING, CREATING, UPDATING, DELETING, FAILED or RESTARTING. Monitoring MSK Connect lists the CloudWatch metrics, including RunningTaskCount and ErroredTaskCount, kept for 15 months, and the ListConnectorOperations and DescribeConnectorOperation calls that track past and current changes.
Where it falls short. Connector state, the logs that hold a failed task’s error, CloudWatch metrics and the topics a connector writes to sit in different places, and each account and region is a separate session. IAM authorises principals, so it adds no approval step, no masking and no per-team view. Its modelled running cost is 8 engineer-hours a month, $11,520 a year at $120 an hour.
Rank 3 Kafbat UI
63 out of 120 Total
- Cost a year
- $0 licence, about $8,640 in operator time (modelled)
- On MSK Connect
- Not documented; Connect clusters are reached by REST URL
- Sign-in
- OAuth2, OIDC and LDAP, free
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- MSK Connect operations ×3 weight, this criterion counts 3 times toward the total
- 1 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 6 out of 10
- Directory and Kafka sign-in
- 7 out of 10
- Many teams, shared clusters
- 6 out of 10
Why these scores for Kafbat UI
- Out of the data path 9 out of 10
- It is one stateless container with no database and no proxy, the same pass as Kpow.
- MSK Connect operations 1 out of 10
- MSK Connect has no Kafka Connect REST endpoint to point it at and its documentation does not describe the MSK Connect API, so it sees a connector only as the consumer group and topics it leaves on the cluster.
- Production access on request 4 out of 10
- RBAC grants actions per resource and a cluster can be set read-only, but there is no approval step, no time-boxed grant, and its masking applies the same way to every viewer.
- Audit trail per person 6 out of 10
- Its audit log names the logged-in user and records reads when the level is set to ALL, but it writes to a topic or the console with no view in the product, so reading the trail is something you build.
- Directory and Kafka sign-in 7 out of 10
- It supports OAuth2 and OIDC, including Microsoft Entra ID, and LDAP or Active Directory, and its documentation does not list SAML.
- Many teams, shared clusters 6 out of 10
- Roles scope permissions per resource and list the clusters they apply to, with no tenant view of a team’s own resources.
On MSK Connect. Kafbat UI lists self-managed Connect clusters by their REST URL beside each Kafka cluster, and its feature list covers Kafka Connect next to topic browsing, consumer groups and schemas. On MSK it signs in over IAM, as the Amazon MSK page describes, so the cluster side of an MSK Connect pipeline is visible. The Kafbat UI review covers its RBAC and release history.
Where it falls short. MSK Connect connectors cannot be listed, read or changed from it, so their state stays in the AWS console. There is no way to grant production access for an hour and have it expire or to hold a change for approval. Its modelled running cost on one cluster is 6 engineer-hours a month, $8,640 a year at $120 an hour.
Rank 4 AKHQ
55 out of 120 Total
- Cost a year
- $0 licence, about $8,640 in operator time (modelled)
- On MSK Connect
- Not documented; Connect clusters are reached by REST URL
- Security default
- Disabled until you enable it
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- MSK Connect operations ×3 weight, this criterion counts 3 times toward the total
- 1 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 3 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Directory and Kafka sign-in
- 6 out of 10
- Many teams, shared clusters
- 5 out of 10
Why these scores for AKHQ
- Out of the data path 9 out of 10
- It is one stateless container with no database and no proxy, the same pass as Kpow.
- MSK Connect operations 1 out of 10
- It takes a URL for each Connect cluster, MSK Connect exposes none, and its documentation does not cover MSK Connect, so it sees a connector only as the consumer group and topics it leaves on the cluster.
- Production access on request 3 out of 10
- Groups bind actions to resources by regex, but there is no approval step or time-boxed grant, masking is global, and without the JWT signing secret the restriction is in the UI only.
- Audit trail per person 4 out of 10
- Audit events are opt-in to a Kafka topic, reads are not recorded, and there is no view for the trail.
- Directory and Kafka sign-in 6 out of 10
- It supports LDAP, OIDC and header authentication from a proxy, does not list SAML, and ships with security disabled until you enable it.
- Many teams, shared clusters 5 out of 10
- Groups combine resource types with regex patterns on names and clusters, which limits what a role can reach, but there is no tenant view of a team’s own resources.
On MSK Connect. AKHQ takes a list of Connect clusters under each Kafka connection, each with its own URL and optional basic authentication, which fits self-managed Connect but not MSK Connect. The AKHQ review covers the rest.
Where it falls short. Security is off until you configure it, the audit trail is an opt-in topic that does not record reads, and MSK Connect connectors stay in the AWS console. Its modelled running cost on one cluster is 6 engineer-hours a month, $8,640 a year at $120 an hour.
Compare Kpow vs AKHQAKHQ review
Rank 5 Lenses
lenses.io
50 out of 120 Total
- Cost a year
- Team is $4,000 for up to 15 users on one cluster, $6,880 with operator time; 25 engineers needs a custom quote (modelled)
- On MSK Connect
- Not documented
- Deployment
- HQ on PostgreSQL plus an agent and database per cluster
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 4 out of 10
- MSK Connect operations ×3 weight, this criterion counts 3 times toward the total
- 1 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 7 out of 10
- Directory and Kafka sign-in
- 7 out of 10
- Many teams, shared clusters
- 6 out of 10
Why these scores for Lenses
- Out of the data path 4 out of 10
- It runs a central HQ on PostgreSQL plus an agent and an agent database beside every cluster, and HQ has no high-availability option.
- MSK Connect operations 1 out of 10
- Its documentation covers MSK clusters and self-managed Kafka Connect clusters but does not describe MSK Connect, so it sees a connector only as the consumer group and topics it leaves on the cluster.
- Production access on request 4 out of 10
- Its masking is the strictest view-time model, global with no escape even for admins, but no approval step or time-boxed grant is described.
- Audit trail per person 7 out of 10
- Audit logs can be read in the product, with no need to build a consumer first.
- Directory and Kafka sign-in 7 out of 10
- SSO spans Okta, Keycloak, OneLogin, Google and Entra ID, with basic authentication only on Community.
- Many teams, shared clusters 6 out of 10
- Roles attach to groups only, never to individuals, and no scoped view per team is described.
On MSK Connect. Lenses connects to MSK clusters through its agent and manages self-managed Connect clusters with built-in Connect alert rules, but its documentation does not describe MSK Connect. The Lenses review covers its tiers and deployment.
Where it falls short. A central HQ on PostgreSQL plus an agent and an agent database for every cluster is more to run in the VPC, and MSK Connect connectors stay in the AWS console. The Team licence stops at 15 users on one cluster, so a larger team is on a custom quote.
Compare Kpow vs LensesLenses review
Rank 6 Redpanda Console
redpanda.com
45 out of 120 Total
- Cost a year
- $0 for the free build, about $8,640 in operator time (modelled); sign-in and RBAC need an unpublished Enterprise licence
- Licence
- Business Source License
- On MSK Connect
- Not documented
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- MSK Connect operations ×3 weight, this criterion counts 3 times toward the total
- 1 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 2 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 2 out of 10
- Directory and Kafka sign-in
- 4 out of 10
- Many teams, shared clusters
- 3 out of 10
Why these scores for Redpanda Console
- Out of the data path 9 out of 10
- It is a self-hosted container with no database, the same pass as Kpow.
- MSK Connect operations 1 out of 10
- Its Connect support queries the REST API of each configured Connect cluster, MSK Connect exposes none, and Redpanda’s documentation does not mention MSK Connect, so it sees a connector only as the consumer group and topics it leaves on the cluster.
- Production access on request 2 out of 10
- The free community build has no access control of any kind, and RBAC needs a Redpanda Enterprise licence, with no approval step or time-boxed grant described.
- Audit trail per person 2 out of 10
- Redpanda’s audit log is a feature of Redpanda’s own brokers, so on Amazon MSK, Console keeps no record of who did what, with or without an Enterprise licence.
- Directory and Kafka sign-in 4 out of 10
- It connects to Kafka-compatible brokers over the standard SASL mechanisms, but OIDC sign-in for people requires an Enterprise licence and is its only single sign-on protocol.
- Many teams, shared clusters 3 out of 10
- RBAC is licence-gated and each deployment reaches one broker cluster, so there is no single policy across development, staging and production.
On MSK Connect. Redpanda Console is Redpanda’s web console, source-available under the Business Source License. Its Kafka Connect configuration queries every configured Connect cluster through the Connect REST API, which suits self-managed Connect. The Redpanda Console review covers the licence terms in detail.
Where it falls short. Governance is bought from Redpanda, a broker vendor: sign-in and RBAC need an Enterprise licence whose price is not published, and Redpanda’s audit log is a feature of its own brokers, so on Amazon MSK no licence gives Console a record of who changed what. MSK Connect connectors stay in the AWS console.
Rank 7 Conduktor
conduktor.io
54 out of 120 Total
- Cost a year
- 25 Console seats at $1,200 is $30,000 plus $2,880 operator time, so $32,880; Gateway Core adds $60,000 and Gateway Protect, which carries encryption and masking, a further $30,000 (modelled)
- On MSK Connect
- Listed on Conduktor's AWS integration roadmap; not documented
- Deployment
- Console on PostgreSQL 13+; data-level controls through Gateway, a proxy
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 3 out of 10
- MSK Connect operations ×3 weight, this criterion counts 3 times toward the total
- 1 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 6 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 8 out of 10
- Directory and Kafka sign-in
- 7 out of 10
- Many teams, shared clusters
- 7 out of 10
Why these scores for Conduktor
- Out of the data path 3 out of 10
- Console needs PostgreSQL 13 or later, and its encryption, data-level masking and Virtual Clusters only work when client traffic goes through Gateway, a proxy in the data path.
- MSK Connect operations 1 out of 10
- Its Kafka Connect documentation covers self-managed Connect clusters and Confluent Cloud managed connectors, and Conduktor’s own AWS Marketplace announcement lists MSK Connect as on its roadmap, so it sees an MSK Connect connector only as the consumer group and topics it leaves on the cluster.
- Production access on request 6 out of 10
- Masking can exempt users or groups, which beats every other tool here on who sees unmasked data, and cross-team access requests are approved by the owning team, but no expiring grant is described and topic creation that passes policy is a direct API call.
- Audit trail per person 8 out of 10
- Console logs produce, consume and admin requests across more than 70 event types with user, IP and timestamp, browsable in the UI and exported as CloudEvents.
- Directory and Kafka sign-in 7 out of 10
- Its SSO configuration covers LDAP and OIDC, with guides for Okta, Entra ID and Keycloak, and does not describe SAML.
- Many teams, shared clusters 7 out of 10
- Permissions are set per user or group across clusters, but a user in several groups inherits the most permissive grant, and Virtual Clusters for multi-tenancy need Gateway.
On MSK Connect. Conduktor supports MSK clusters with IAM and the AWS Glue Schema Registry, and its Console manages self-managed Connect clusters with auto-restart and connector alerts. Its blog post announcing the AWS Marketplace listing names MSK Connect under the integrations still on its roadmap. The Conduktor review covers the rest.
Where it falls short. Console needs PostgreSQL. Conduktor’s data-level controls, such as encryption, masking of the data itself and virtual clusters for multi-tenancy, run in Gateway, a Kafka proxy that client applications connect through, and MSK Connect workers are Kafka clients too, so routing them through Gateway puts it in front of every connector’s reads and writes. On AWS Marketplace, Conduktor Enterprise lists Console at $1,200 a seat for the first 100 seats, Gateway Core, which carries virtual clusters, at $60,000 a year, and Gateway Protect, the add-on for encryption and masking, at a further $30,000.
Compare Conduktor review
What teams on Amazon MSK Connect need
This page is about tools for Amazon MSK Connect, the feature of Amazon MSK that runs Kafka Connect connectors on workers AWS provisions, patches and scales, on Kafka Connect 2.7.1 or 3.7.x, against an MSK cluster or any Apache Kafka cluster reachable from a VPC, as AWS’s MSK Connect guide describes. It ranks tools for the team that runs those connectors. Tools for the cluster itself are compared in the best Kafka UI tools for Amazon MSK, which carries Belong’s account of running Kpow on MSK from its public talk; no Factor House customer has described its MSK Connect use in public, so this page ranks tools on what the MSK Connect API and each tool’s own documentation say. Self-managed Connect clusters are covered in the best Kafka tools for Apache Kafka Connect.
The fact that decides most of this ranking is that MSK Connect does not hand out a Kafka Connect REST endpoint. An AWS answer on AWS re:Post puts it directly: the endpoint that controls the underlying Kafka Connect processes is not exposed but wrapped in the AWS SDK, so there is no direct Kafka Connect endpoint. Connectors, custom plugins and worker configurations are created, described, updated and deleted through the MSK Connect API instead, under IAM. A Kafka UI that manages Connect by pointing at a worker’s REST URL, which is how the open-source UIs on this page reach Connect, has nothing to point at, and sees an MSK Connect connector only as the consumer group and topics it leaves on the cluster.
Recovery has changed recently. Until August 2026, AWS’s announcement says, recovering from a failure required deleting and recreating the connector. The new RestartConnector operation restarts a connector and all its tasks, or with onlyFailedTasks only the failed ones, but the restart guide requires the connector to be RUNNING with no other lifecycle operation in progress and limits failed-tasks-only restarts to Kafka Connect 3.7 or later, and the troubleshooting page adds that restart is supported only for connectors created after the capability arrived. A connector created earlier still recovers the old way.
Reading a failure also works differently from self-managed Connect. DescribeConnector returns one state for the connector, RUNNING, CREATING, UPDATING, DELETING, FAILED or RESTARTING, rather than a state per task. A failed task shows up as the ErroredTaskCount metric that MSK Connect sends to CloudWatch, and the error itself is in the connector’s log destination, CloudWatch Logs, S3 or Firehose. The logging page warns that MSK Connect rate-limits connector log output and may drop lines during bursts, so an alarm on ErroredTaskCount is the dependable signal and the logs are the place to read the cause.
Out of the data path. MSK Connect workers run in the subnets you give the connector, each taking an IP address from them, as AWS’s worker page notes, and every task is an ordinary Kafka producer or consumer of the cluster named when the connector was created. A tool whose controls work only when client traffic passes through a proxy therefore has to sit between those workers and the brokers, and a connector that copies a database into Kafka then depends on the proxy staying up. Managing MSK Connect needs nothing more than the MSK Connect API and a client connection to Kafka. Kpow is one container with no external database, installed in your own environment and out of the data path. Conduktor Console also connects directly, with a PostgreSQL database of its own; Conduktor’s data-level controls, such as encryption, masking of the data itself and virtual clusters, run in Conduktor Gateway, a Kafka proxy that client applications connect through.
MSK Connect operations. Beyond reaching the API at all, a tool has to cope with how MSK Connect changes connectors. UpdateConnector takes either a new capacity or a new connector configuration in one request, never both, and the update guide says connector.class cannot be changed, so moving to a different connector means a new connector. In autoscaled mode, the troubleshooting page explains, MSK Connect overrides tasks.max in proportion to the workers and their capacity, so the running task count can differ from the configuration a team wrote. MSK Connect also often sits in a different AWS account from the tooling: a tool can use the IAM role attached to its instance with no stored keys, static keys, or an STS AssumeRole into the account that holds the connectors, the three options Kpow’s MSK Connect page documents.
Production access on request. Connector configurations hold credentials: database passwords, keys for the systems a sink writes to. AWS’s config provider tutorial shows how to keep them in Secrets Manager, S3 or Systems Manager and resolve them on the workers at runtime, and the logging page adds that a plugin which does not declare a property as a password type writes its value into the connector logs in clear. IAM decides which principal may call UpdateConnector or DeleteConnector, but when engineers work through a shared tool, IAM sees only the tool’s role. What a tool adds is per person: who may create a connector, who may change its configuration, and access that expires after the task. Those controls are compared across the field in Kafka RBAC tools.
Audit trail per person. MSK Connect API calls reach CloudTrail under the kafkaconnect.amazonaws.com event source, which EventBridge’s MSK Connect reference lists, and each record carries the userIdentity of the caller. For a change made through a shared tool, that identity is the tool’s role or its STS session, the same for every engineer, so the record of which person deleted or reconfigured a connector has to come from the tool. The options are compared in Kafka audit logging tools.
Directory and Kafka sign-in. A tool for MSK Connect holds two kinds of credential: an IAM principal for the MSK Connect API, and a Kafka connection with whatever IAM, SCRAM or TLS settings the cluster enforces. People then sign in through the company directory over SAML, OpenID Connect or LDAP, so a connector change is tied to a named person rather than to the tool’s role.
Many teams, shared clusters. One account and region usually holds many teams’ connectors. IAM can restrict a role to connector ARNs that match a team’s naming, but that limits what can be done, not what each team sees; each team needs its own view of its own connectors, topics and consumer groups.
No tool here leads on every point: the MSK console, AWS CLI and CloudWatch cover every MSK Connect operation, including the new restart and the history of connector operations, and Kpow governs people working through Kpow, so IAM still decides what anyone with console or CLI access can do to the same connectors.
Once several teams share an MSK cluster, IAM policies can't answer the governance questions anymore. Now AI agents are getting access to Kafka too.
Chad Harris, Solutions Architect at Factor House
How a team runs Amazon MSK Connect with Kpow
Installing it in the VPC. Kpow runs as one Docker container, a Java JAR or from the Helm charts, on ECS, EKS or EC2 in a network that reaches the MSK cluster. It needs no external database, because its snapshots, metrics and audit log live in topics on the Kafka cluster.
Connecting MSK Connect. Kpow authenticates to the MSK Connect API through the AWS SDK. On ECS, EKS or EC2 it inherits the attached IAM role through the default credentials provider chain, the approach its documentation recommends; outside AWS it takes static keys, and where Kpow runs in one account and the connectors in another it assumes a role with CONNECT_STS_ROLE_ARN. CONNECT_AWS_REGION sets the region, and each further environment gets its own numbered set of variables matched to its Kafka cluster (MSK Connect provider page).
Granting the tool only what it needs. The same page gives two IAM policies for the principal Kpow uses: admin access to every connector, custom plugin and worker configuration in the region, or the recommended production pattern that lets Kpow list and describe everything but update or delete only a named list of connector ARNs.
Reading connectors beside the cluster. Kpow shows connector and task status, configuration and metrics from the MSK Connect API in the same console as the MSK cluster’s topics and consumer groups, so the connectors and the cluster they write to are managed in one place, and data inspect reads the records on a connector’s dead letter topic like any other topic. The free Community Edition setup wizard has configured MSK Connect since Kpow 90.4.
Deciding who may do what. Kpow’s authorization actions split Connect into CONNECT_CREATE, CONNECT_ALTER_STATE, CONNECT_EDIT_CONFIG, CONNECT_DELETE and CONNECT_INSPECT, and RBAC sets Allow, Deny or Stage per action on resources matched by pattern. Tenants give each team a view limited to its own connectors, topics and groups, a temporary policy grants extra access for a set time and then expires, and staged mutations hold a connector deletion or configuration change until an administrator approves it.
Signing people in. Engineers sign in through SAML, OpenID Connect or LDAP, so every connector action carries a person from the company directory while CloudTrail records Kpow’s role.
Keeping the record and the alerts. The audit log records every connector action with the user from the identity provider, and a webhook sends those records to Slack, Microsoft Teams or any HTTP endpoint, such as a SIEM collector. Alerts on MSK Connect itself stay in CloudWatch, where an alarm on ErroredTaskCount catches a failed task, and a restart goes through the MSK console or the aws kafkaconnect restart-connector command.
Kpow live demo
See the Kpow UI before you connect MSK Connect
The live Kpow demo runs on two Apache Kafka clusters on Amazon MSK. It shows brokers, topics, consumer groups, schema registries and the __oprtr_audit_log topic where Kpow keeps its audit trail, with no signup. Connecting your own MSK Connect connectors is the step to try next.
For platform teams choosing a tool for Amazon MSK Connect.
Try the Kpow demoFAQ
What is the best tool for Amazon MSK Connect?
On this page’s rubric, Kpow, with 105 of 120 points: it calls the MSK Connect API with the instance role, static keys or a cross-account STS role, shows connectors beside the topics and consumer groups they use, splits connector permissions per action and per team, records every action against the person, and runs as one container in your VPC with no external database. The MSK console, AWS CLI and CloudWatch score 91 and remain the most complete surface for MSK Connect operations on their own.
Can Kafbat UI, AKHQ or Redpanda Console manage MSK Connect connectors?
Not as connectors. They manage Kafka Connect through a worker’s REST URL, and MSK Connect wraps Kafka Connect in the AWS SDK with no direct Kafka Connect endpoint, as an AWS answer on AWS re:Post explains. They still show the topics and consumer groups those connectors use on the cluster.
Can I restart a failed MSK Connect connector?
Since August 2026, yes, for connectors created after the capability arrived: RestartConnector restarts the connector and its tasks, or only the failed tasks on Kafka Connect 3.7 or later, while the connector is RUNNING. Older connectors still recover by being deleted and recreated, as AWS’s announcement describes.
Why does my MSK Connect connector say RUNNING when a task has failed?
DescribeConnector reports one state for the whole connector. Failed tasks appear in the ErroredTaskCount metric in CloudWatch, and the cause is in the connector’s logs in CloudWatch Logs, S3 or Firehose, which MSK Connect may thin out during bursts. The monitoring page lists the metrics.
Does Kpow Community Edition support MSK Connect?
Yes. Kpow Community Edition is free on up to 3 clusters and 10 users, and its setup wizard has configured MSK Connect since Kpow 90.4. RBAC, masking, staged approvals and the full audit log need Kpow Enterprise. More free options are compared in the best free Kafka UI tools.
How these tools were scored
Five of the six criteria are the ones Factor House scores on every page for teams that share a Kafka cluster, with each tool’s score copied from the live pages that already score it; the sixth, MSK Connect operations, is specific to this page. They are listed here in order of weight. Each criterion is scored 0 to 10: 10 where a tool is the only one here doing it or clearly the best, 8 for a clean documented pass, 5 or 6 for partial support or support that needs work the reader must verify, 1 to 4 for a weak or indirect form, and 0 where it is absent. The weights add up to 12, so totals are out of 120.
1. Out of the data path (counts three times). The tool should run in your own environment, reach Kafka as an ordinary client and MSK Connect through the AWS API, and keep no data outside your own cluster. Scored lower: tools that need an external database of their own, and tools whose controls work only when application or connector traffic passes through a vendor’s proxy. A self-hosted container with no external database and no proxy scores 9, a tool with a database of its own 6, one with several databases or an agent per cluster 4, and one that needs both a database and a proxy for its controls 3; 10 is kept for an option with nothing to deploy at all, which here is AWS’s own console and CLI. This criterion is scored the same way on every Factor House page that uses it, and only its weight changes with the reader.
2. MSK Connect operations (counts three times). Whether the tool calls the MSK Connect API to list, describe, create, update, restart and delete connectors, with the instance role, static keys or a role in another account, and whether it shows them beside the topics and consumer groups they use. This is not the connector operations criterion on the Apache Kafka Connect page: that one scores what a tool does through the Kafka Connect REST API, which MSK Connect does not expose, so a tool’s score there does not carry over. Tools that document no MSK Connect support score 1, for the indirect view of a connector’s consumer group and topics on the cluster.
3. Production access on request (counts twice). Whether an engineer can be granted access to production for one task and have it expire, whether a destructive change can be held for a second person’s approval, and whether sensitive fields can be masked from people who do not need them.
4. Audit trail per person (counts twice). Whether the tool records each action, reads included, against the person from the identity provider, and whether that record can be read in the product and sent to the systems that keep it long term.
5. Directory and Kafka sign-in (counts once). Whether people sign in through SAML, OpenID Connect or LDAP, and whether the tool connects to Kafka with the same SASL or TLS settings as any client and to the MSK Connect API with an IAM principal.
6. Many teams, shared clusters (counts once). Whether each team can be given its own view of its own topics, consumer groups and connectors on a shared cluster, and whether one deployment reaches several clusters.
Costs are modelled for one production Kafka cluster with its MSK Connect connectors and 25 engineers at $120 per engineer hour, using the same hours per tool class as Factor House’s other comparison pages. MSK Connect’s own charges are the same whichever tool is used, so they are left out. Tools with a licence carry the published price plus 2 hours a month to run. The open-source UIs carry 6 hours a month, $8,640 a year, to run, secure and keep current, and the AWS console with CLI scripts and log queries carries 8 hours a month, $11,520. Kpow’s $7,380 uses the published price of $4,500 per cluster with 100 users included. Lenses publishes a Team price of $4,000 a year for up to 15 users on one cluster, so 25 engineers is a custom quote. Conduktor’s Console is $1,200 a seat on AWS Marketplace, and its Gateway Core and Gateway Protect prices are added for the data-level controls; Conduktor prices Gateway per cluster with a 3-cluster minimum, and the listing does not say how many clusters that figure covers. Kpow Community Edition is free for 3 clusters and 10 users, so a 25-engineer team is on Enterprise.
The criteria map onto MSK Connect’s design in the figure below.
Every option is scored from 0 to 10 on each criterion, from the evidence and sources this page cites, and the reason for each score is on its card. The criteria are weighted: Out of the data path counts three times, MSK Connect operations counts three times, Production access on request counts twice, Audit trail per person counts twice, Directory and Kafka sign-in counts once and Many teams, shared clusters counts once, for a total out of 120. Out of the data path and MSK Connect operations count three times. MSK Connect workers are Kafka clients running in your own subnets, so a tool whose controls work through a proxy sits in front of every connector's reads and writes, and a tool that needs a database of its own is one more stateful service in the VPC; and because MSK Connect exposes no Kafka Connect REST endpoint, a tool that does not call the MSK Connect API cannot see the connectors at all. Production access on request and the per-person audit trail count twice: connector configurations hold credentials, and CloudTrail names the IAM role a shared tool calls with rather than the engineer, so who may change a connector, and who did, has to come from the tool. Directory and Kafka sign-in, and shared clusters, count once. This page is published by Factor House, which makes Kpow. Every option is scored on the same rubric and the same sources: Kpow's per-criterion scores are set the same way as every other option's and are not adjusted, and the weights apply to every option alike. Kpow ranks first on its total of 105 out of 120. The other options follow by total. Conduktor is listed last whatever its total; on its total of 54 it would place fifth.
Related reading
- Kafka: the complete guide
- Kafka Connect
- Best Kafka tools for Apache Kafka Connect
- Best Kafka UI tools for Amazon MSK
- Best Kafka UI tools for AWS Glue Schema Registry
- Best tools to monitor Kafka Connect connectors
- How to diagnose and fix a failed Kafka Connect connector
- Best Kafka management tools for banks