On this page
The decision in one paragraph
The decision in one paragraph
Decide what you need covered before you look at who covers it: the broker, the clients, the connectors, the platform underneath, and the people who wrote the consumers. Open-source Kafka is fully supportable without a Confluent subscription; Confluent Platform support covers Confluent's distribution and its components. Vendor support follows the product; independent support follows your estate, including MSK and Confluent Platform clusters. Price is set by the estate size and the response commitment, not per broker. Read the SLA for what triggers the clock and who answers, then settle the boundary questions before signing, because the boundary is where every dispute lives.
What a Kafka contract actually covers
Broker incidents, configuration and tuning, upgrade guidance and patch advice are in scope on almost every contract. Client code, connectors, Kafka Streams applications and the Kubernetes platform underneath are where contracts differ, and where the real incidents come from. Get the boundary in writing, with examples, before the first ticket.
Open-source Kafka versus Confluent Platform
Apache Kafka is fully supportable as open source; you do not need a Confluent subscription to have a production estate covered. Confluent Platform adds components (Schema Registry, connectors, Control Center, tiered storage) and a support tier that covers them. The question is which components you actually run, because that decides whether vendor support covers your incident or your broker's.
Vendor support versus independent support
Vendor support follows the product: it is authoritative on the distribution and stops at its edge. Independent support follows the estate: self-managed Apache Kafka, Amazon MSK and Confluent Platform under one contract, with the client and connector layer in scope where the contract says so. Most estates that run more than one of those end up with independent cover, sometimes alongside a vendor subscription for the components only the vendor can patch.
| Question | Vendor support (Confluent) | Independent support |
|---|---|---|
| What it follows | The product: Confluent's distribution and its components | The estate: self-managed Apache Kafka, Amazon MSK and Confluent Platform under one contract |
| Where it stops | At the edge of the distribution | Where the contract draws the line; client and connector layers are in scope where the contract says so |
| Fits when | You run Confluent Platform components only the vendor can patch | You run more than one of those platforms, or open-source Kafka, and want one contract across them |
What a Kafka contract costs
Priced on cluster and broker count plus the response tier, from business hours through 24/7 with response targets from 15 minutes, by plan. Self-managed estates with a support contract usually cost less per year than a fully managed service and more than nothing, and the comparison that matters is against the cost of the last outage and the engineer time spent on the next upgrade.
Typical range. Independent support is typically priced at $24,000–72,000 a year, depending on SLA, scope and deployment; AceMQ's own prices are quoted on request. For comparison, Confluent publishes support for its cloud product as a formula: Business is the greater of $29 a month or 5% of monthly usage, and Premier the greater of $1,000 a month or 10% of the first $50,000 of usage, tapering to 3% above $1M a month (read from Confluent's page on 26 October 2026; see the support price index).
How to read the SLA
Four things decide whether an SLA is worth anything: what starts the clock (ticket logged, or engineer engaged), who the first responder is (a senior engineer or a triage tier), what severity definitions say about a broker that is up but lagging, and whether the response commitment covers the platform under the broker. A quick acknowledgement from a triage queue is not an engineer working your problem.
Settle the boundary before you sign
Which clusters and which components, whether client code and connectors are in scope, whether MSK or Confluent Cloud incidents are covered when the platform is the cause, how upgrades are handled, and what a health check at onboarding produces. Every dispute in a support relationship sits on one of those lines; draw them first.
From our engagements. AceMQ has been in business for 10+ years and has 160+ customers. For a global payments platform running Kafka and RabbitMQ at high transaction volumes, it provides L3 support under one SLA covering both, with load-test validation and incident support for problems at the boundary between the two (the case).
Frequently asked questions
Can I get commercial support for open-source Kafka without Confluent?
Yes. Apache Kafka is supportable as open source by independent firms, AceMQ included, with the same 24/7 cover and SLA a vendor subscription offers. A Confluent subscription is needed only for Confluent's own components.
Does Kafka support cover Amazon MSK?
Vendor support does not; AWS supports the MSK service, not your topics, consumers or connectors. Independent support such as AceMQ's covers MSK clusters at the Kafka layer alongside self-managed and Confluent Platform estates.
What should a Kafka support SLA include?
A defined trigger for the response clock, a senior engineer as first responder, severity definitions that treat a lagging cluster as an incident, and explicit scope for clients, connectors and the platform underneath. Response time alone tells you very little.
How much does Kafka support cost?
It is priced on cluster and broker count and the response tier, from business hours to 24/7 with response targets from 15 minutes, by plan, and quoted against the actual estate rather than from a list. The cost post works the comparison against self-managed and fully managed.
