.png)
Retains all Kafka architecture limitations
Amazon MSK is essentially a cloud-hosted version of Apache Kafka, and it does not thoroughly cloud-native transform Kafka's architecture 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 typically lags behind the community version by several months to half a year. For some serious issues exposed by the Kafka kernel, Amazon MSK cannot follow up and fix them in a timely manner, 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 can't 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.
