Amazon Managed Streaming for Apache Kafka (MSK)

Name: Amazon Managed Streaming for Apache Kafka (MSK)
Brand: Amazon Web Services (AWS)
Rating: 4 (22 reviews)

Leader

Official Global LinkedIn page for Amazon Web Services (AWS).

Est 2006|Valuation $2560B|5 Ref Customers

LinkedIn 10.9M|Website|Web traffic 1.1M|FTEs 148,001|HQ Seattle, Washington, US

MarketsContainer Management

Platform CoversData Integration (ETL/ELT)Infrastructure Monitoring Workflow Automation

Amazon Managed Streaming for Apache Kafka (MSK) screenshot

Published Oct 13, 2026

01Common complaints

1) Need for maximum Kafka configuration control - Several user reports and platform reviews indicate some configuration changes require cluster recreation or are otherwise constrained. 2) Heavy reliance on managed connectors and governance features - If the project requires a broad set of turnkey connectors and extensive governance features, competitor platforms may be more suitable. 3) Expectation of serverless "scale to zero" economics - Some users reported that MSK Serverless did not meet their expectation of scale-to-zero pricing; careful cost modeling is recommended. 4) Roadmap requiring simple in-place ZooKeeper-to-KRaft migration - Community reports indicate that MSK clusters may not support an in-place upgrade path between ZooKeeper-based Kafka and KRaft mode; migration planning may be required. 5) Requirement for multi-cloud managed Kafka with a single control plane - MSK is an AWS-only managed service; multi-cloud control-plane needs may be better served by other vendors.

Deal disqualifiers (poor fit)

Requirement for extensive out-of-the-box managed connectors and governance tooling
Need for complete control of Kafka broker configuration, rapid adoption of the newest Kafka releases, or support for niche plugins requiring deep broker access
Multi-cloud uniformity requirements across AWS, Azure, and GCP

Documented or strongly reported limitations

As a managed service, MSK does not expose all broker-level tuning knobs and plugin options available to self-managed Kafka deployments.
Serverless billing is multi-dimensional; some users have reported cost outcomes that deviate from expectations about minimal usage costs.

Roadmap and migration constraints

Community reports indicate that migrating MSK clusters from ZooKeeper-based Kafka to KRaft may require planned migration steps rather than an in-place upgrade.

Scale considerations

Specific scale constraints are workload-dependent and are typically determined by partition counts, throughput, storage IO, and client/consumer architecture. Vendors typically provide guidance but customers should validate scale behavior with representative workloads.

API and integration constraints

Connector breadth and governance features may require additional tooling or third-party services for feature parity with some competitors.

02Why they buy

Unique selling points supported by evidence

Integration with AWS services (IAM, VPC, CloudWatch) and AWS operational model.
Kafka API compatibility provided as a managed AWS service, facilitating application portability.
Published SLA provisions for multi-AZ deployments and a service-credit structure.

Vendor-provided claims that require validation

Vendor performance and recovery claims (for example, throughput, scaling speed, and recovery-time reductions) are provided in marketing and pricing materials; these claims should be validated with proof-of-concept testing or benchmarking for specific workload profiles.

Areas where competitors have advantages

Competitors often emphasize a broader managed connector set, governance features, and multi-cloud control planes.

Why customers chose MSK (patterns)

Reported selection reasons include:

Reduction in infrastructure and routine operational tasks compared with self-managed Kafka
Integration with AWS security, networking, and monitoring services
Alignment with AWS procurement and account management practices

03Field reports

Review platform availability note

Gartner Peer Insights review pages were not accessible in the sources reviewed, likely due to access restrictions. This report relies on TrustRadius, PeerSpot, and community forums for user-sourced feedback.

TrustRadius

TrustRadius lists Amazon MSK with a high score in the small sample reviewed (the dataset at the time of research included a small number of reviews). The small sample size suggests results should be treated as directional rather than definitive.

PeerSpot — mixed feedback with concrete complaints

PeerSpot reviews for MSK show mixed feedback in the sample reviewed. Representative user-reported limitations include difficulties making certain configuration changes without recreating clusters and limited configuration options in some cases. PeerSpot reviewers also cite stability, scalability, and AWS integration as reasons for choosing MSK in several reviews.

Community forums — practitioner concerns

Common themes in community discussions include: 1) Unexpected charges related to Serverless instances (some users reported accumulating charges that were higher than anticipated) 2) Concerns about MSK Connect pricing (some users reported that connector-related costs can be unexpected and significant) 3) Constraints related to Kafka architecture changes (for example, migration steps between ZooKeeper-based Kafka and KRaft mode have been reported as non-trivial for MSK clusters) 4) Mixed perspectives on AWS-managed services that overlap with AWS-native alternatives

Why some customers consider alternatives or leave

Reported reasons for considering alternatives include:

Configuration limitations compared with self-managed Kafka
Perceived gaps in connector ecosystem breadth and governance features relative to some competitors
Cost concerns for specific components such as Connect and serverless usage profiles

Vendor-supplied case studies (vendor-selected testimonials)

1) Behalf (partner blog) - Reported drivers: security, high availability, operational considerations, low latency, and around-the-clock support. - Note: the partner blog presents vendor-selected outcomes without an independent benchmarking methodology. 2) AWS press and announcements (examples include Riot Games and Intuit descriptions) - Riot Games reported ingesting large-scale data using MSK; Intuit reported migrating from self-managed Kafka to MSK to shift engineering focus. - Critical view: these are selected vendor-supplied testimonials that demonstrate feasibility at scale but do not provide independent performance or cost analysis methodologies. 3) Nexthink (vendor-cited example) - Reported scaling improvements in ingestion bandwidth as presented in vendor-provided customer materials. - Critical view: vendor-curated metrics require validation regarding measurement conditions (compression, replication factor, consumer topology, and measurement methods).

Mixed or negative anecdotes

Publicly accessible negative or mixed experiences are primarily available on review platforms and community forums rather than as formal failed-adoption case studies.

04Best fit

Company sizes

Mid-market to enterprise teams with significant AWS usage and event-driven architectures.
Typical platform maturity: a small team of engineers familiar with Kafka fundamentals, even when infrastructure is managed.

Industries / verticals

Usage examples span gaming, fintech, media distribution, and SaaS products that require CDC and high-throughput ingestion.

Roles and personas

Platform engineering, SRE, and DevOps teams
Data engineering teams implementing CDC and lakehouse ingestion patterns
Backend/microservices engineering teams
Security and IT teams responsible for VPC and IAM controls

Pain points MSK addresses

Operational management of Kafka broker infrastructure
Multi-AZ availability patterns without implementing all broker-level automation
Integration with AWS identity and networking controls

Qualification criteria (good fit)

Strong AWS footprint and preference to operate within AWS accounts and VPCs
Use of Kafka clients or desire for Kafka API compatibility
Willingness to accept some managed-service constraints in exchange for reduced broker-level operations

05The pitch

What the product does (core value proposition in objective terms)

Amazon Managed Streaming for Apache Kafka (Amazon MSK) is Amazon Web Services' managed Apache Kafka offering. The service provisions and operates Kafka clusters and related components such as Kafka Connect via MSK Connect. MSK reduces the infrastructure and operational tasks associated with running Kafka (for example: patching, broker replacement, monitoring integration, and scaling workflows) while maintaining compatibility with Apache Kafka APIs and tooling (source: official vendor documentation). MSK is offered in multiple deployment options: - MSK Provisioned (customers specify broker instance sizes and storage; AWS manages the control plane and many operational tasks) - MSK Serverless (capacity planning is abstracted from the customer; billing is based on published usage metrics such as cluster-hours, partition-hours, data transfer, and storage) - MSK Connect (managed Kafka Connect workers) - MSK Replicator (listed in vendor pricing documentation; technical details are provided in official vendor documentation)

Target market and market positioning

- Primary target: teams using the Apache Kafka ecosystem (Kafka clients, Kafka Streams, Kafka Connect, MirrorMaker, etc.) that require a managed Kafka service within AWS. - Positioning: a managed Kafka service within AWS infrastructure rather than a comprehensive streaming platform with an integrated governance/connector marketplace. - Common use cases: event-driven microservices, change data capture (CDC) pipelines, clickstream/log ingestion, and near-real-time analytics pipelines (source: official vendor documentation).

Get a comprehensive analysis of Amazon Managed Streaming for Apache Kafka (MSK) including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →