On this page
Short answer
If the workload is small, non-regulated and already in a public cloud, a hosted platform such as CloudAMQP or Amazon MQ for RabbitMQ is the fastest route and usually the cheapest per month. If the messages cannot leave your account, or the estate is large, customised or on a version the platform does not offer, RabbitMQ operated in your own account by a specialist keeps the data and the topology where they are and adds the operations. Hosting with a RabbitMQ specialist sits between the two: a managed platform with engineers who benchmark the workload before go-live and can escalate into the RabbitMQ core team. Running it yourself with a support contract remains right for teams that have a capable platform team and only need cover for the two or three times a year it genuinely breaks. AceMQ provides the in-account option as managed RabbitMQ: your brokers, our pager.
Four ways to have RabbitMQ run for you, on the same criteria
| Hosted platform (CloudAMQP, Amazon MQ) | Operated in your account (AceMQ managed services) | Specialist-hosted (AceMQ SaaS plans) | Self-run with a support contract | |
|---|---|---|---|---|
| Where the brokers live | The provider's account and region | Your cloud account, VPC, datacenter or Kubernetes cluster | AceMQ's platform, with an Enterprise option in your own account | Wherever you put them |
| Who chooses the version | The platform; Amazon MQ in particular supports a limited set of versions and plugins | You, with an upgrade path we plan and execute | AceMQ, on a published cadence, with version rescue for estates arriving from older releases | You |
| Plugins and custom configuration | Restricted to what the platform allows | Anything RabbitMQ supports | Standard set, with exceptions agreed per plan | Anything |
| Who answers an incident | Platform support tiers | Named senior engineer, 24/7, 15-minute emergency SLA, escalation to the RabbitMQ core team | Same engineers and SLA as managed services | Your on-call, with the support contract as escalation |
| Data residency and compliance | Data lives in the provider's account; check the region and the compliance attestations you need | Unchanged: nothing leaves your security boundary | AceMQ's platform, or your own account under the Enterprise plan | Unchanged |
| Existing estate | Migrate into the platform | Managed as-is; no migration is required to start | Migrate, with a readiness benchmark first | As-is |
| Exit | Export definitions and messages, rebuild elsewhere | Runbooks, topology docs and monitoring stay yours; exit is a handover | Handover pack maintained throughout | Nothing to exit |
| Wins when | Small to mid workload, no data-residency constraint, speed matters most | Regulated or large estate, or one that cannot move | You want RabbitMQ specialists behind the console without owning infrastructure | You have a platform team and a low incident rate |
Hosted platforms: CloudAMQP and Amazon MQ for RabbitMQ
Both run RabbitMQ in their own accounts and sell it as a service with tiered plans. CloudAMQP is the specialist: deep RabbitMQ knowledge, a mature console, multi-cloud regions and plugin support across its dedicated plans. Amazon MQ for RabbitMQ is the AWS-native option: single-instance or a three-node cluster across availability zones in one region, IAM and CloudWatch integration, and billing on the AWS invoice. Its constraints are the ones AWS documents: a limited list of supported versions and plugins, and a support model that is AWS's, not a RabbitMQ engineer's.
Where they win: a workload that is already in the cloud, does not carry a data-residency obligation, and needs a broker running this week. Where they stop fitting: the moment the messages cannot leave your account, the estate needs a plugin or a version the platform does not offer, or the incident response you need is a person who already knows your topology. Both require a migration to start and a migration to leave.
CloudAMQP vs Amazon MQ: list prices and limits
Both publish their prices, so the hosted options can be compared on cost before anyone talks to sales. CloudAMQP sells fixed monthly plans; the figures below are its RabbitMQ plans, not the LavinMQ plans on the same page. Amazon MQ bills each broker instance by the hour plus storage, and a three-node cluster runs three instances at three times the hourly price. Amazon MQ rates are the US East (N. Virginia) on-demand rates that AWS uses in its own pricing example. Sources: the CloudAMQP plans page and the Amazon MQ pricing page, both checked on 20 October 2026.
| CloudAMQP (RabbitMQ plans) | Amazon MQ for RabbitMQ | |
|---|---|---|
| Entry price | Little Lemur, a shared broker, is free; Tough Tiger, also shared, is $19 a month | An mq.t3.micro single-instance broker at $0.02704 an hour |
| Smallest dedicated node | Sassy Squirrel, one node, at $50 a month | mq.m7g.medium at $0.1367 an hour, mq.m7g.large at $0.2734, mq.m5.large at $0.288 |
| Three-node cluster | From $297 a month (Big Bunny on three nodes) | Three times the instance price. AWS's own example, an mq.m5.large cluster with 200 GB per node, comes to $702.82 for a 31-day month |
| Private networking | VPC add-on at $99 a month on dedicated plans: VPC peering, AWS or Azure PrivateLink, or Google Private Service Connect | Standard AWS data transfer charges apply; data transfer inside a RabbitMQ cluster is not charged |
| Storage | Extra disk at $0.35 per GB a month, in tiers from 25 GB to 2,000 GB | Amazon EBS at $0.10 per GB-month |
| Limits to check | Shared plans cap queues, queued messages and monthly messages; plugins are offered on dedicated RabbitMQ plans only | A fixed version list (4.3, 4.2 and 3.13), no streams, and a plugin set chosen by AWS |
Other hosted RabbitMQ providers: Stackhero, Elestio and Northflank
Beyond CloudAMQP and Amazon MQ, a handful of smaller platforms host RabbitMQ for you, and they show up in most searches for managed RabbitMQ. Stackhero runs managed RabbitMQ on dedicated, isolated instances and is also sold as a Heroku add-on. Elestio deploys open-source RabbitMQ as a fully managed service with automated backups, TLS, updates and monitoring. Northflank offers RabbitMQ as an add-on on its platform, either in Northflank's cloud or in your own cloud account. One naming note: CloudAMQP's operator, 84codes, also develops LavinMQ, its own AMQP message broker, so a CloudAMQP plan is not automatically a RabbitMQ plan.
All of these are hosted platforms in the same sense as CloudAMQP: the provider runs the broker, you get a connection string, and the parts that cause most incidents, such as queue design, consumer behaviour and client reconnection, stay with your team. They suit development, smaller production workloads and teams already on that platform. For regulated or business-critical messaging, check the same things you would check with any host: which RabbitMQ versions are offered and how fast they patch, whether quorum queues and the plugins you use are available, where the data lives, and who answers at 3am.
Operated in your own account
The brokers stay where they are, on your VMs, your Kubernetes cluster or your cloud account, and a specialist takes over monitoring, patching, upgrades, capacity and the pager. Nothing about data residency, network policy or compliance posture changes, which is why regulated estates choose it. The estate is managed as-is: an undocumented or inherited cluster is assessed and then run, with no migration as a precondition.
It costs more per month than hosting the same shape with a platform, because it is engineer time with no infrastructure leverage, and the honest comparison says so. What the money buys is a named senior engineer who knows the topology, a 15-minute emergency SLA, CVE patching on a documented schedule an auditor accepts, and an exit that is a handover rather than a rebuild. Managed RabbitMQ services sets out the scope and the onboarding phases.
Hosted by a RabbitMQ specialist
The middle option: a managed platform, but operated by people whose only product is RabbitMQ. AceMQ's hosted plans run from a shared sandbox through dedicated single-node and multi-node clusters to an Enterprise plan that can deploy into your own account. Every plan carries the same engineers and SLA as the in-account service, a workload benchmark before go-live so sizing is measured rather than guessed, and in-broker observation after it rather than infrastructure metrics alone. Engagement tiers layer on top for teams that want an engineer reviewing the workload rather than a dashboard.
It fits teams that do not want to own infrastructure at all but have outgrown what a generic platform's support tier can tell them about their own workload. The plans and tiers are described on the hosted RabbitMQ section of the managed services page.
Self-run with a support contract
Still the right answer for many teams. If you have a platform team that can hold the pager, the incident rate is low, and what you need is an expert alongside you when something does break, a 24/7 support contract costs less than any managed option and changes nothing about how you operate. The dividing line is whether anyone on the team wants to own RabbitMQ; if the honest answer is no, a support contract will not fix that. 24/7 RabbitMQ support covers what the contract includes and how far back the version window reaches.
Amazon MQ vs self-managed RabbitMQ: what AWS managed RabbitMQ leaves out
Amazon MQ is RabbitMQ, but not all of it. AWS documents three limits that decide whether it fits. Versions: Amazon MQ supports RabbitMQ 4.3 and 4.2 only on the mq.m7g instance family, and 3.13 as the single remaining 3.x option; if your applications are certified on anything else, that version is not available. Streams: Amazon MQ does not support RabbitMQ streams, and its documentation warns that creating one will result in data loss. Plugins and logging: the plugin set is fixed by AWS, and structured JSON logging is not supported. Checked against the Amazon MQ developer guide on 20 September 2026.
None of that matters for a standard AMQP workload that lives entirely in AWS. It matters the moment the estate uses streams, a community plugin, a version AWS has retired, or a second cloud. In those cases the choice is between a specialist host and keeping the brokers in your own account with someone else operating them: AceMQ managed RabbitMQ services cover both.
Managed RabbitMQ on AWS, Azure and Google Cloud
Only one of the three big clouds sells RabbitMQ as a first-party service, which shapes what “managed RabbitMQ” means in each.
- AWS. Amazon MQ for RabbitMQ is AWS's own managed RabbitMQ, with the version, streams and plugin limits described above. CloudAMQP also runs on AWS and is listed in the AWS Marketplace.
- Azure. Microsoft's own messaging services are Azure Service Bus and Event Hubs, and neither is RabbitMQ. Managed RabbitMQ on Azure comes from CloudAMQP, which runs in Azure regions and is listed in the Azure Marketplace, or from running RabbitMQ yourself on AKS or virtual machines. The trade-offs are in RabbitMQ on Azure: the hosting options.
- Google Cloud. Google's own messaging service is Pub/Sub, which is not RabbitMQ. Managed RabbitMQ on Google Cloud comes from CloudAMQP, also in the Google Cloud Marketplace, or from running RabbitMQ on GKE with the RabbitMQ Cluster Operator.
CloudAMQP lists itself on AWS, Azure and Google Cloud across 131 regions, and connects to your VPC through AWS PrivateLink, Azure Private Link or Google Cloud Private Service Connect. On every cloud, keeping the brokers in your own account remains an option when the data cannot sit in a provider's account.
What to check before you choose a managed RabbitMQ service
- The exact RabbitMQ version on offer, and how quickly the provider moves to new releases and retires old ones. Your client libraries and any certification are tied to it.
- Queue types. Quorum queues for anything durable, and streams if the design uses them; Amazon MQ does not support streams.
- Plugins. Shovel, federation, delayed messages and any community plugin you depend on.
- Cluster shape. Node count, spread across availability zones, and what happens to your queues during the provider's maintenance window.
- Upgrades. Who schedules them, how much notice you get, and whether they are rolling.
- Incident ownership. Whether the support tier diagnoses RabbitMQ behaviour, such as a memory alarm or a consumer that stops acknowledging, or only the infrastructure.
- Residency and exit. Where the data lives, and what leaving involves: exporting definitions, draining queues and repointing every client.
How to decide in one pass
- Can the messages leave your account? If not, hosted platforms are out; choose between operated-in-your-account and self-run with support.
- Does anyone on the team want to own the broker? If yes, self-run with a support contract. If no, one of the managed options.
- Is the estate large, customised, or on a version a platform will not offer? If yes, operated in your account. If no, a hosted option.
- Do you want a specialist behind the console? If the workload is payments-grade or the incident history says generic support was not enough, specialist-hosted. Otherwise a general platform is fine.
Frequently asked questions
What is managed RabbitMQ?
RabbitMQ that someone else operates for you. It comes in two forms: a hosted service, where the provider runs the brokers in its own account and you connect to them, such as CloudAMQP or Amazon MQ, and managed operations, where the brokers stay on your infrastructure and a specialist runs them. Both take patching, upgrades, monitoring and the pager off your team.
Does Azure have a managed RabbitMQ service?
Not a first-party one. Microsoft's own messaging services are Azure Service Bus and Event Hubs. Managed RabbitMQ on Azure comes from CloudAMQP, which runs in Azure regions and is in the Azure Marketplace, or from running RabbitMQ yourself on AKS or virtual machines with someone operating it.
Does Google Cloud have a managed RabbitMQ service?
Not a first-party one. Google's own messaging service is Pub/Sub. Managed RabbitMQ on Google Cloud comes from CloudAMQP, which is in the Google Cloud Marketplace, or from running RabbitMQ on GKE with the RabbitMQ Cluster Operator.
Does Amazon MQ support RabbitMQ streams?
No. The Amazon MQ developer guide states that streams are not supported and that creating a stream will result in data loss. If your design depends on streams or super streams, you need self-managed RabbitMQ, a specialist host, or brokers in your own account operated for you.
Which RabbitMQ versions does AWS managed RabbitMQ support?
As of September 2026 Amazon MQ supports RabbitMQ 4.3 and 4.2, only on the mq.m7g instance family, and RabbitMQ 3.13 on mq.t3, mq.m5 and mq.m7g. Older series are not offered, so an estate pinned to an earlier version cannot move to Amazon MQ without upgrading first.
What is the best managed RabbitMQ service?
The best managed RabbitMQ depends on where the messages may live. For a standard workload already in the cloud, a hosted platform is quickest: CloudAMQP for RabbitMQ expertise, plugins and several clouds, Amazon MQ for an all-AWS estate on one invoice. If the messages cannot leave your account, or the estate is large or customised, RabbitMQ operated in your own account by a specialist fits better. A team that wants to keep the pager needs only a support contract.
Amazon MQ vs RabbitMQ: what is the difference?
Amazon MQ for RabbitMQ is RabbitMQ that AWS runs as a service. Applications use the same AMQP clients, but AWS chooses the versions (4.3, 4.2 and 3.13 as of September 2026), fixes the plugin set and does not support streams. Self-managed RabbitMQ runs any version and plugin, and the operations are yours or a partner's.
Is CloudAMQP or Amazon MQ better for RabbitMQ?
CloudAMQP is the RabbitMQ specialist with broader plugin and version support and multi-cloud regions; Amazon MQ is the AWS-native option with IAM and CloudWatch integration and a narrower supported set of versions and plugins. If you are entirely on AWS and the workload is standard, Amazon MQ is simpler to procure. If you need plugins, version choice or RabbitMQ-specific support, CloudAMQP. If the data cannot leave your account, neither.
What is the difference between managed RabbitMQ and hosted RabbitMQ?
Where the brokers live. Hosted means the provider runs RabbitMQ in its own account and you connect to it. Managed, in AceMQ's usage, means the brokers stay on your infrastructure and a specialist operates them. AceMQ offers both; the page above compares them on the same criteria.
Why does managing RabbitMQ in my own account cost more than hosting it?
Because it is engineer time with no infrastructure leverage: a specialist operates a platform they do not own, on your terms, inside your security boundary. Hosting spreads platform engineering across many tenants. The premium buys data residency, an unchanged compliance posture, and an estate managed as-is with no migration.
What does a fully managed RabbitMQ service include?
The provider deploys the RabbitMQ broker instances, patches and upgrades them, replaces failed broker nodes, handles scaling within its plans, and on cluster tiers spreads the nodes across multiple availability zones. You also get TLS encryption on the endpoints, the RabbitMQ management UI or an equivalent console, and metrics for alerting. Hosted services are usually billed per hour of broker instance plus storage. What stays yours is the application side: exchange and queue design, consumer behaviour, throughput tuning, and checking how definitions and messages are backed up, plus the lock-in that comes with any provider-specific feature.
Which protocols do managed RabbitMQ services support?
RabbitMQ itself speaks AMQP 0-9-1 and, since RabbitMQ 4.0, AMQP 1.0 natively, with MQTT, STOMP and WebSockets available through plugins. Managed services enable different subsets. Amazon MQ for RabbitMQ lists AMQP 0-9-1, AMQP 1.0 and JMS as its supported protocols and does not offer the MQTT plugin. CloudAMQP enables MQTT, STOMP and their WebSocket variants from its console. If IoT devices or browsers connect straight to the broker, check protocol support before choosing a provider.
Can I move between these options later?
Yes, in either direction, and the exit terms matter more than the entry terms. Hosted platforms require exporting definitions and messages and rebuilding elsewhere. AceMQ's managed and hosted services maintain runbooks, topology documentation and a handover pack throughout, so leaving is a handover rather than a rebuild.