AMQ Streams, priced per broker.

JBoss AMQ Streams licensing meters by core on the host running the Kafka broker. The distribution packages Apache Kafka, the Strimzi operator that runs Kafka on Kubernetes, AMQ Streams Connect for source and sink connectors, Mirror Maker for cross cluster replication, and the schema registry. The producers and consumers, the applications that publish to and read from Kafka topics, sit outside the entitlement; they are not metered. The metering attaches to the brokers themselves and to the broker side support components like Connect and Mirror Maker.1

The product is sold standalone and inside the broader JBoss middleware portfolio. On OpenShift, AMQ Streams runs as a Strimzi managed cluster on worker nodes; the worker nodes consume both the OpenShift entitlement and the AMQ Streams entitlement on the cores carrying the brokers. On RHEL, the installation runs as a systemd managed Kafka service on RHEL hosts; the hosts consume both the RHEL entitlement and the AMQ Streams entitlement on the cores.

For the broader middleware practice context, see the JBoss and middleware practice hub. For the benchmarking observations that underlie the unit price ranges, see the benchmarking service hub.

Three counting traps recur on AMQ Streams estates. Each is correctable through reshape before audit or renewal.

The first trap is counting cores on every worker node in an OpenShift cluster rather than only the nodes carrying brokers. The Strimzi operator's standard deployment pattern places brokers on a dedicated node pool or via node affinity rules; only those nodes consume the AMQ Streams entitlement. Operators sometimes treat the entire cluster as in scope, which inflates the count beyond what the operator and the deployment topology actually require. The reshape is to confirm the broker node placement and entitle only those nodes.

The second trap is licensing replica brokers separately when the cluster is a single logical Kafka cluster. A standard Kafka deployment runs three or five brokers per logical cluster for high availability. All brokers across the logical cluster are in scope under the standard rule because each broker is an active member of the cluster. The reshape sits in confirming that the broker count reflects the actual cluster topology rather than an inflated headroom estimate.2

The third trap is treating Connect workers and Mirror Maker as separate entitlements. The AMQ Streams entitlement covers Kafka Connect workers, Mirror Maker 2 instances, the registry, and the Strimzi operator itself as part of the broker side bundle. Operators sometimes carry parallel entitlement against Connect workers or registries on the assumption that they are out of scope; the reshape is to confirm they are covered and to retire the parallel entitlement.

Red Hat OpenShift Streams for Apache Kafka is a managed Kafka service that sits on top of OpenShift Dedicated. The economic shape is fundamentally different from the self managed AMQ Streams entitlement; OpenShift Streams meters by throughput and storage rather than by broker core, and the broker infrastructure is managed by Red Hat rather than by the operator. The choice between AMQ Streams and OpenShift Streams is a build versus buy decision on the operational side of Kafka, not a runtime choice.

The break point sits at the operational maturity of the team plus the absolute scale of the deployment. Estates with strong platform teams and stable Kafka topology benefit from the self managed AMQ Streams entitlement because the per core cost is lower than the managed service throughput cost at scale. Estates that lack a dedicated Kafka platform team or run modest Kafka workloads with high variability benefit from OpenShift Streams because the operational lift is delegated.3

The seller side at renewal has used the managed service to expand the relationship beyond the AMQ Streams entitlement alone. The buyer side reading is that the managed service has real operational value where the team capacity is constrained but does not displace the AMQ Streams entitlement on estates with mature platform operations. For the surrounding integration runtime context that often pairs with Kafka on event driven architectures, see the Apache Camel licensing note.

Apache Kafka is an upstream open source project. The community distribution runs the same broker code as AMQ Streams, with the paid build providing support, certified compatibility within the Red Hat platform, and a long term maintenance commitment. The boundary against community use is consequential because Kafka is normally a production critical messaging backbone and the support value is real when a broker partition gets stuck under load.

Three boundary patterns work in operational practice. The first is paid build on production messaging, community build on development and non production data movement. This is the common pattern. The reshape requires technical separation, particularly on shared OpenShift clusters where the broker node pools need to enforce the entitlement boundary against any community Kafka workload running elsewhere in the cluster.

The second is paid build on the cross domain messaging fabric, community build on local team Kafka deployments. Large estates often run a central paid Kafka fabric alongside team owned community Kafka clusters for local use cases. The reshape works when the central fabric is technically separated from the team clusters and when the team clusters do not produce to or consume from the paid fabric.

The third is paid build only on long term support versions. Where the paid build's maintenance commitment is the actual value, the reshape is to license only the clusters that pin to a long term version and let the rest run the community release. This pattern works on estates with the engineering capacity to manage community Kafka in production. For the surrounding service mesh context on OpenShift estates where Kafka brokers sit alongside mesh managed traffic, see the OpenShift service mesh licensing note. For the sibling decision platform note that often paires with Kafka on event driven business rules estates, see the Decision Manager licensing note.

The renewal posture on an AMQ Streams estate has three components worth preparing before the seller side prices the next term. The first is the broker inventory, which should resolve every broker to its host or worker node and confirm that broker count reflects actual cluster topology. The second is the bundle reconciliation, which should retire any parallel entitlement on Connect workers, Mirror Maker, or registry components that the broker entitlement already covers. The third is the community boundary, with the technical enforcement documented for each environment.

The seller side at renewal often positions AMQ Streams as the strategic event streaming platform and pairs the renewal with an OpenShift Streams managed service pitch or a broader integration bundle. The buyer side reading is that the strategic framing carries real value where the platform team is constrained and real friction where it is not. For estates already mature on Kafka operations, the standalone AMQ Streams entitlement is the cleaner posture.

One industry context shifts the conversation materially. Financial services estates with regulatory weight on messaging audit trails face documentation pressure that often pushes the count toward the full production estate. For the surrounding audit context, see the financial services audit considerations note.

For estates evaluating AMQ Streams licensing ahead of a renewal or audit, the engagement is normally a subscription assessment scoped to the Kafka estate plus a community boundary review and an OpenShift entitlement chain check. To begin, see the contact page.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.