.png)
Retains all Kafka architecture limitations
Amazon MSK is essentially a cloud-hosted version of Apache Kafka, and it does not thoroughly transform Kafka's architecture into a cloud-native one like AutoMQ does. Therefore, the difficulties in scaling, high costs, resource waste caused by over-provisioning, and related performance and stability issues caused by Kafka itself also exist in MSK.
Lags behind the Kafka community's updates
Amazon MSK often falls behind the community version by several months to as much as six months. For some serious issues exposed by the Kafka kernel, Amazon MSK cannot address and resolve them promptly, which will seriously affect the production stability of the customer's existing MSK clusters.
SLA does not cover Kafka faults
Amazon MSK's SLA only covers MSK code. You won't receive compensation for outages caused by Kafka itself.
Mandatory multi-AZ deployment
Even in test or AZ-tolerant scenarios, multi-AZ deployment is mandatory. However, Kafka's data-intensive nature results in high cross-AZ traffic costs, increasing user expenses.
Incompatibility with Kubernetes
Amazon MSK cannot be deployed in your Kubernetes cluster, limiting seamless integration with other Kubernetes applications and data infrastructure for users managing Kafka via Kubernetes.
Vendor lock-in
Choosing Amazon MSK means facing high future migration and transformation costs when moving Kafka to other clouds or implementing multi-cloud deployments.
