AMQ, three meters in one name.

Red Hat AMQ in 2026 is not a single product. It is a portfolio of three. AMQ Broker is the JMS and AMQP message broker built on Apache ActiveMQ Artemis. AMQ Streams is the streaming platform built on Apache Kafka. AMQ Interconnect is the message router built on Apache Qpid Dispatch. The three products share branding because they share a customer audience: enterprise teams building event driven and integration architectures. They do not share an underlying engine, and they do not share a meter.1

The buyer side complication is that an AMQ line on a renewal proposal can refer to any one of the three, or to two of them, or to all three, or to a generic AMQ pool that does not specify. The proposal that does not specify is the proposal that requires the most careful reading. The defensible position is to insist that the proposal name the specific product, the specific edition, and the specific metric in each line.

For the wider JBoss middleware practice context, see the JBoss and Middleware practice hub. For the EAP companion meter, see the JBoss EAP subscription model article.

AMQ Broker is metered on a core based subscription in 2026, with a defined number of entitled cores per subscription unit and a support tier attached. The meter shape mirrors the JBoss EAP shape: the cores that AMQ Broker is enforceably bound to on each host, summed across the estate, are the entitled cores. The host total is not the meter. The bound cores are. The enforcement mechanism is the same family of mechanisms that applies to EAP: hypervisor CPU pinning, container CPU limits, cloud instance vCPU binding, or operating system level cgroup configuration.2

AMQ Streams is metered differently in 2026. The Kafka based product is typically sold on a per broker or per node count, with a defined number of brokers per subscription unit. The meter follows the natural unit of the Kafka cluster. A buyer that operates a six broker Kafka cluster on AMQ Streams is sized to six broker entitlements. The core based reading is not the typical shape on AMQ Streams; the broker count is. Where the proposal applies a core based read to AMQ Streams it has either pulled the wrong meter template or is doing a topology specific calculation that should be checked carefully.

AMQ Interconnect, where it is in commercial circulation in a given estate, is typically scoped as a component of a broader Red Hat integration agreement rather than as a standalone metered product. The buyer that holds AMQ Broker or AMQ Streams in significant volume and uses AMQ Interconnect as a router between them should expect the Interconnect line to be modest relative to the engine lines, and should treat the Interconnect line accordingly in the renewal arithmetic.

Three counting traps recur on the AMQ line in 2026. The first is the unspecified pool, where the proposal reads AMQ without naming a product, an edition, or a metric. The buyer that signs an unspecified pool pays for capacity that may not match any specific product the deployment actually uses. The defensible response is to refuse the unspecified line and ask the seller side to resolve the line into the specific products, editions, and metrics in use.

The second trap is the core read on the Streams line, where the proposal applies a core based meter to AMQ Streams as if it were AMQ Broker. The Kafka cluster meter is the broker count in most commercial shapes in 2026. A core based read on Streams typically overcounts in an estate with high core density per broker. The defensible response is to read the Streams meter at the broker count and confirm the count against the deployment.3

The third trap is the host read on the Broker line in a virtualized or containerized estate, where the proposal counts every physical core on every host running an AMQ Broker process rather than the bound cores. This is the same trap that recurs on the EAP line and has the same defensible response: demonstrate the binding, document the enforcement, and negotiate the meter at the bound count.

Container topology adds a specific consideration for AMQ Streams. The standard Streams deployment in 2026 is on Kubernetes or OpenShift, with a Kafka operator managing the cluster and the brokers running as pods. The broker count meter reads cleanly here: each broker pod is a broker, the count is the cluster size, and the entitlement covers the count. The number of underlying nodes the brokers run on is not the meter; the number of brokers in the cluster is.4

The OpenShift entitlement on the underlying cluster does not stack with the AMQ Streams entitlement. The two meters read separate things. The OpenShift entitlement covers the platform itself: the cluster nodes, the control plane, the operator framework. The AMQ Streams entitlement covers the brokers running on that platform. A buyer that pays for both is paying for both correctly; a buyer that pays for one as if it included the other is misreading the meter. For the OpenShift side, see the OpenShift edition article; for the wider OpenShift practice, see the OpenShift practice hub.

The audit posture on AMQ follows from the meter mix. A defensible audit response on AMQ Broker presents the bound cores. A defensible audit response on AMQ Streams presents the broker count and the cluster topology. A defensible audit response on AMQ Interconnect presents the component scope and the host count where applicable. The response that mixes the three meters reads no meter cleanly. The response that reads each meter on its own terms holds.

The buyer side reading at AMQ renewal proceeds in five steps. First, inventory the actual AMQ deployments, distinguishing Broker, Streams, and Interconnect by name and by version. Second, apply the appropriate meter to each: bound cores for Broker, broker count for Streams, component scope for Interconnect. Third, sum the meter readings per product and confirm they match the proposed lines on the renewal. Fourth, refuse any unspecified or mixed AMQ pool line and insist on product specific lines. Fifth, sign each product line at its own documented meter, with the documentation retained for any subsequent audit inquiry.5

Across recent practice engagements, the discipline has produced a recoverable correction on AMQ renewals where the proposal applied the wrong meter template to one of the three products or where the proposal left the line unspecified. Where each product was already correctly metered, the correction was smaller and the conversation moved to multi year structuring and tier optimisation.

The corollary on the audit side is that a Red Hat AMQ finding that conflates the three product meters is a finding that does not survive a clean product by product reconciliation. For the audit defense engagement, see audit defense; for the renewal engagement, see renewal negotiation; for direct contact, 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.