AWS RabbitMQ: Amazon MQ or Self-Hosted with Support?

For RabbitMQ on AWS, Amazon MQ wins when you run a standard AMQP workload entirely inside AWS and accept its three-node cluster, version list and plugin list. Self-hosting on EC2 or EKS with a support contract wins when you need streams, a different cluster size, your own upgrade timing or a lower infrastructure bill.

AceMQ meets this decision in assessments, and two cases show where it bites. A software vendor that ships RabbitMQ to its customers saw "high levels of connection volatility" against remote Amazon MQ clusters, with channel shutdowns initiated by the host, and its Amazon MQ staging broker carried a default lazy-queue policy that we advised removing. A payments company running a five-node cluster across three Availability Zones could not keep that layout on Amazon MQ, where a cluster is fixed at three nodes.

Prices and limits below were checked on 22 October 2026 against the AWS price lists and the Amazon MQ developer guide.

Every row is a three-node cluster in US East (N. Virginia), on-demand, 730 hours a month. Amazon MQ bills the three brokers at one hourly cluster rate plus $0.10 per GB-month of EBS across the cluster; the mq.m7g disks default to 15, 25 and 45 GB per node. The self-managed column is three EC2 m7g instances of the same size plus 200 GB of gp3 per node at $0.08 per GB-month. Sources: the Amazon MQ price list (published 11 September 2026) and the EC2 on-demand price list (published 22 October 2026).

Amazon MQ's instance rate is more than three times the EC2 price of three equivalent instances, and that gap buys the operations work. Two items sit outside the table. AWS charges nothing for traffic inside an Amazon MQ cluster, while replication between your own EC2 nodes in different Availability Zones is billed at $0.01 per GB in each direction. EKS adds a cluster fee and a Kubernetes operator to run. AceMQ support is quoted per estate, not listed; ask for a quote once you know node count and response time.

• Cluster shape. A cluster is three nodes behind a Network Load Balancer across Availability Zones; the alternative is one broker in one zone. The 99.9% monthly uptime SLA, about 44 minutes a month, covers clustered brokers only. Single-instance brokers have none.
• Streams. Not supported. AWS's documentation warns that creating a stream results in data loss.
• Plugins. The set is AWS's list. Shovel and federation are on it, with limits: only dynamic shovels work, and a private broker cannot be a shovel destination or a federation upstream.
• Alarm thresholds. Amazon MQ sets the memory and disk alarms and you cannot modify them. On mq.m7g.large the memory high watermark is 4.3 GiB of 8 GiB, and publishers block when it is crossed.
• Versions. RabbitMQ 4.3 and 4.2 on mq.m7g only, plus 3.13. AWS's release notes show no 4.0 or 4.1 offering, and new releases arrive after upstream: 4.2.0 shipped on 28 October 2025 and reached Amazon MQ on 20 November 2025; 4.3.0 shipped on 23 April 2026 and reached it on 9 September 2026. RabbitMQ 4.4.0 shipped on 20 October 2026 and is not on AWS's list.
• 4.x gaps. Local random exchanges and message interceptors are unsupported, and per-queue metrics no longer reach CloudWatch on 4.x brokers.

1. Two steps. AWS has supported in-place upgrades from 3.13 to 4.2 since 5 May 2026, and from 4.2 to 4.3. No direct 3.13 to 4.3 step is documented.
2. mq.m7g only. RabbitMQ 4 does not run on mq.m5, so an m5 broker also needs an instance-type change. AWS's upgrade page does not describe the two as one operation, so rehearse on a test broker.
3. Downtime. Amazon MQ blocks all connections during the upgrade, and the outage depends on queue depth. Keep queues short. There is no managed blue-green option; building your own means redirecting clients.
4. Queue defaults. On 4.2 brokers a queue declared without a type becomes a quorum queue.
5. Reconnecting clients. Cluster maintenance takes one node down at a time, so clients must reconnect on their own.

The upstream side of the move is covered in upgrading RabbitMQ 3.x to 4.x without downtime.

You choose the version, node count, plugins and disks, so streams and RabbitMQ 4.4 are available the day they ship. You also carry operating-system and image patching, Erlang and RabbitMQ upgrades, definition backups, monitoring and the pager. In one of our assessments of a self-managed cluster on EC2, the bottleneck was an EBS IOPS ceiling under quorum-queue fsync load. Self-hosting makes disk sizing your problem.

• The workload is standard AMQP, lives entirely in AWS and does not use streams.
• A three-node cluster and a 99.9% SLA meet the availability target.
• The team has no RabbitMQ specialist and wants IAM, CloudWatch and one AWS invoice.
• AWS's version cadence and single maintenance window are acceptable.

If any of those fail, the choice is a specialist host or your own account with someone else operating it. The hosted options are compared in managed RabbitMQ options compared.

AceMQ supports RabbitMQ on EC2 and EKS around the clock with a 15-minute emergency response, and at Stage 3 of our support ladder operates it for you inside your AWS account, so messages stay in your VPC. We also support the application side of Amazon MQ: AWS covers the service, not a consumer that stops acknowledging or a queue design that fills memory. See managed RabbitMQ services for the stages and what each includes.

• AWS: Amazon MQ pricing
• AWS: Amazon MQ price list (US East, published 11 September 2026)
• AWS: EC2 on-demand pricing
• AWS: Amazon MQ SLA
• Amazon MQ: managing RabbitMQ engine versions
• Amazon MQ: upgrading from RabbitMQ 3 to 4
• Amazon MQ: RabbitMQ 4
• Amazon MQ: supported plugins
• Amazon MQ: RabbitMQ broker instance types
• Amazon MQ: RabbitMQ deployment options
• Amazon MQ: release notes
• RabbitMQ: release information