> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # Amazon MQ RabbitMQ Single > AWS Amazon MQ RabbitMQ Single. A single-instance RabbitMQ broker running on one node in one availability zone, which restarts in place rather than failing over. **On this page** * [Coverage by target cloud](#coverage-by-target-cloud) * [How the targets compare](#how-the-targets-compare) * [Infrastructure-only adaptation](#infrastructure-only-adaptation) * [On Google Cloud, Azure, OCI, and Private Kubernetes](#on-google-cloud-azure-oci-and-private-kubernetes) ## Coverage by target cloud | Target | Available | | ------------------ | --------- | | Google Cloud | ✓ | | Azure | ✓ | | OCI | ✓ | | Private Kubernetes | ✓ | ## How the targets compare Each row compares a capability of Amazon MQ RabbitMQ Single with its adaptation on each target. A dash means this row is not stated for that target. ### Infrastructure-only adaptation | Capability | Amazon MQ RabbitMQ Single | Google Cloud, Azure, OCI, and Private Kubernetes | | ------------------- | ----------------------------------------- | ------------------------------------------------------------------------------ | | AMQP protocol | AMQP 0-9-1 (RabbitMQ) | native; same broker engine, client unchanged | | Broker topology | single-instance | single node | | High availability | none; Amazon MQ single-instance is non-HA | none (single node; size the cluster topology for HA) | | Managed broker | Yes | No - you self-manage the broker on Kubernetes | | Management API + UI | Yes | Yes - RabbitMQ management plugin (console URL differs) | | TLS | Yes | Yes - self-signed / cert-manager issuer (trust chain differs from AWS-managed) | | API coverage | full | high | ## On Google Cloud, Azure, OCI, and Private Kubernetes | Operation | Area | Support | Depth | Notes | | ---------------------------------------------------------------------------------- | ----------------- | ------------ | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | CloudWatch logs / KMS / maintenance window / VPC placement / minor-version upgrade | AWS control plane | Out of scope | Full surface | these AWS-managed settings are omitted. Configure logging, monitoring, encryption at rest and upgrades with the target cluster's tools | | Management API + UI | Admin | Supported | Most usage | the RabbitMQ management plugin is enabled (the same HTTP API Amazon MQ exposes on 443/15671); the management console URL differs from Amazon MQ's | | Plugins (Shovel / Federation / Consistent-Hash / Prometheus / OAuth2) | Admin | Supported | Most usage | because you operate the broker, you can enable any RabbitMQ plugin, a wider set than Amazon MQ's curated list (Management, dynamic Shovel, Federation, Consistent-Hash-Exchange, OAuth2, LDAP, Prometheus). Amazon MQ's private-broker Shovel/Federation restriction does not apply on the target cluster | | Consumer acks / QoS prefetch | Delivery | Supported | Most usage | RabbitMQ handles acknowledgements and prefetch directly; consumer\_timeout sets the delivery acknowledgement timeout | | Dead-letter exchanges / TTL | Delivery | Supported | Most usage | native RabbitMQ dead-letter exchanges and message/queue TTL | | Publisher confirms | Delivery | Supported | Most usage | native RabbitMQ publisher confirms | | Transactions (Tx.Select / Tx.Commit / Tx.Rollback) | Delivery | Supported | Full surface | native AMQP 0-9-1 transactions on the same broker engine; publisher confirms are the recommended higher-throughput path | | ActiveMQ engine | Engine | Out of scope | Full surface | Amazon MQ's ActiveMQ engine is a different protocol and is out of scope; only RabbitMQ is supported | | Bindings + routing keys | Messaging | Supported | Common | native RabbitMQ routing, unchanged | | Exchanges (direct / fanout / topic / headers) | Messaging | Supported | Common | native RabbitMQ; every exchange type works unchanged | | Queues (classic / quorum / lazy) | Messaging | Supported | Common | RabbitMQ queue types run on one node; replication across nodes requires a cluster | | Streams (RabbitMQ 3.9+) | Messaging | Supported | Full surface | The target supports RabbitMQ Streams as an optional feature beyond the Amazon MQ queue mapping. Core streams can use AMQP; the dedicated Stream protocol needs its plugin, listener and compatible client. Configure and validate Streams separately. | | Authentication (authentication\_strategy=SIMPLE) | Security | Supported | Most usage | SIMPLE is the default strategy. The broker's declared user block (username/password) is written into a Kubernetes secret, and RabbitMQ's internal user backend authenticates against it unchanged | | LDAP authentication | Security | Partial | Full surface | RabbitMQ's LDAP auth-backend plugin (rabbitmq\_auth\_backend\_ldap) is available on the self-operated broker; enable it and point it at your directory. Configure the LDAP server connection on RabbitMQ directly | | TLS | Security | Supported | Most usage | TLS is on (Amazon MQ RabbitMQ is always-TLS); the certificate is self-signed or cert-manager-issued rather than AWS-managed, so the trust chain differs. Pin or trust the cluster's issuer | | Connect (AMQP 0-9-1) | Wire protocol | Supported | Common | your AMQP client (pika, amqplib, the RabbitMQ Java client) connects without changes. Bitnami RabbitMQ runs the same broker engine as Amazon MQ, so the protocol is native; Tensor9 writes the target broker endpoint into the generated Amazon MQ resource outputs | #### 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 1 broker pod, 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. #### Single-node deployment and recovery This target runs one broker pod. Its persistent volume retains messages across pod replacement, but there is no second broker to serve clients while it is unavailable. A single-member quorum queue loses availability if its only node fails. Use the clustered mapping when the application needs broker failover. 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.
The Bitnami RabbitMQ Helm chart deploys 1 broker pod with a persistent volume. There is no second broker or replicated queue member to take over. The Bitnami RabbitMQ Helm chart deploys 1 broker pod with a persistent volume. There is no second broker or replicated queue member to take over.
#### 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](https://www.rabbitmq.com/docs/quorum-queues), [default queue type](https://www.rabbitmq.com/docs/vhosts), and [core Streams and the Stream plugin](https://www.rabbitmq.com/docs/stream-core-plugin-comparison). [Service Catalog](/service-adapters/catalog).