Amazon MQ RabbitMQ Cluster

This page describes how Amazon MQ RabbitMQ Cluster maps to services in the environment where the application runs. Some profiles adapt origin API calls; others translate infrastructure or document target-native behavior.

​

Supported environments

API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on.

​

How the targets compare

Each row compares a capability of Amazon MQ RabbitMQ Cluster with its adaptation on each target. A dash means this profile does not state the capability for that target.

​

Cloud Adapter

​

On Akamai, Azure, DigitalOcean, Google Cloud, OCI, Private Kubernetes, and Scaleway

​

Bitnami RabbitMQ

​

How it works

Tensor9 deploys the Bitnami RabbitMQ Helm chart on the customer’s Kubernetes cluster and sets the broker host and port in the generated Amazon MQ outputs. Your application connects directly to that broker over AMQP 0-9-1. It keeps its RabbitMQ client library; clients that pin the AWS certificate chain must trust the target issuer. The deployment uses 3 broker pods, persistent storage and a Kubernetes Service. The customer platform team operates the broker, storage, upgrades and recovery. A disconnected deployment also needs its container images, chart, certificates and other dependencies available locally.

​

Queues and broker configuration

RabbitMQ handles exchanges, bindings, routing keys, publisher confirms, transactions, consumer acknowledgments, prefetch, dead-letter exchanges and TTL. Check queue types and enabled plugins against the selected broker version when importing definitions. Configure quorum queues explicitly, or set the broker’s default queue type. Upstream RabbitMQ defaults to classic queues unless that default is overridden; running RabbitMQ 4.x alone does not select quorum queues. The management HTTP API and console provide access to broker definitions and operational state. Use the Helm chart’s configuration values for broker settings, credentials, TLS and plugin enablement. This mapping does not require a RabbitmqCluster custom resource or the RabbitMQ Cluster Operator.

​

Three-node deployment and replication

The cluster uses three broker pods. A quorum queue replicates its messages using Raft, a protocol that requires agreement from a majority of the queue’s members. With three members, it can continue after losing one, provided the remaining members can communicate and access their storage. Publisher confirms and durable queue configuration are part of this guarantee. Place replicas on separate nodes and failure domains. Three pods sharing one node do not protect against that node failing. Classic queues do not gain replication merely by running on a three-node broker; declare the required queue type explicitly. Size each persistent volume for the retained backlog and recovery requirements. Storage availability and backups remain separate from broker replication: a replicated queue is not a backup against deletion or an incorrect retention policy.

​

Limitations

△ Operational differences

• TLS trust changes. The target uses a self-signed or cert-manager-issued certificate. Configure client trust and certificate renewal before switching endpoints.
• AWS broker management does not move with the messages. Use the target’s monitoring, storage encryption and upgrade scheduling in place of CloudWatch, KMS and the Amazon MQ maintenance window. Broker credentials and TLS configuration are part of the Kubernetes deployment.
• Streams are an optional target feature. Self-operated RabbitMQ supports Streams, but they are not an Amazon MQ queue migration. Core stream queues can use AMQP; the dedicated RabbitMQ Stream protocol additionally needs its plugin, listener and compatible client. Configure and validate that path separately.
• ActiveMQ is outside this mapping. This adapter covers the RabbitMQ engine. Amazon MQ’s ActiveMQ engine uses a different broker and protocols.

​

Cutover and ongoing operation

Export exchanges, queues, bindings, users, virtual hosts and policies through the source management API as definitions.json, then import the supported definitions into the target. Applications that declare their own topology can recreate those definitions when they connect. Definitions do not contain the message backlog. Drain the old broker or use Shovel or Federation for the required continuity. Account for deliveries in flight at cutover and test consumer retry behavior; they are not transferred automatically. The broker and its provisioned volumes run continuously. Plan capacity from backlog, message sizes, publish and consume rates, and recovery tests on the actual cluster. Monitor disk capacity, queue growth and consumer progress after cutover. Provider references: quorum queues, default queue type, and core Streams and the Stream plugin.

​

Existing data and credentials

Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application’s endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.

​

Configure, tune and debug

Start with setup and configuration. Use tuning to understand supported request tags, debugging to investigate a request, and High Fidelity Cloud Emulators to validate a bounded reproduction.