Amazon MQ
Amazon MQ is a managed message broker service. It runs Apache ActiveMQ and RabbitMQ — the open-source brokers themselves, not an AWS reimplementation — so an application that already speaks a standard messaging protocol can move to AWS without rewriting its messaging layer.
- Supports the protocols those brokers support: AMQP 0-9-1, AMQP 1.0, MQTT, OpenWire and STOMP, plus JMS and NMS through the ActiveMQ client libraries
- Works with existing clients, languages and operating systems
- AWS patches, monitors and backs up the broker; the application keeps the API it has
Amazon MQ runs ActiveMQ and RabbitMQ only. An application built against another broker — IBM MQ, TIBCO, MSMQ — is not a drop-in migration; it is a migration to one of those two engines, and the effort depends on how much of the code depends on broker-specific behaviour rather than on a standard protocol.
Availability
Section titled “Availability”Amazon MQ offers deployment modes designed to keep the broker reachable during maintenance and failure:
- ActiveMQ supports active/standby deployments across two Availability Zones, where one instance is always available, and networks of brokers, whose members can be given separate maintenance windows.
- RabbitMQ supports cluster deployments: three broker nodes across multiple Availability Zones behind a Network Load Balancer.
Single-instance brokers are cheaper but go offline during maintenance, which makes them suitable for development rather than production.
Amazon MQ compared with SNS and SQS
Section titled “Amazon MQ compared with SNS and SQS”Both approaches offer topics and queues, and so both support one-to-one and one-to-many designs. The difference is what each optimises for.
| SNS with SQS | Amazon MQ | |
|---|---|---|
| Best for | New applications built for AWS | Existing applications built for a broker |
| Interface | AWS APIs and SDKs | Standard protocols: JMS, AMQP, MQTT, STOMP, OpenWire |
| Scaling | Managed by AWS, effectively unbounded | Sized by broker instance type, chosen and scaled by the team |
| Networking | Public AWS endpoints, controlled by IAM and resource policies | Reached over private networking — VPC, and Direct Connect or VPN from on-premises |
| Operations | No brokers to think about | A broker to size, monitor, upgrade and patch |
Choosing
Section titled “Choosing”Choose SQS and SNS when building something new, when the AWS-native integrations (Lambda triggers, EventBridge targets, event source mappings) are worth having, and when nobody should have to manage broker capacity.
Choose Amazon MQ when migrating an application that already speaks JMS, AMQP, MQTT or STOMP, when a lift-and-shift is the goal and rewriting the messaging layer is not, or when a feature of the broker itself — message selectors, protocol-level transactions, priority queues — is load-bearing in the application.
Amazon MQ is a bridge for organisations moving to the cloud with their messaging contracts intact. It is rarely the right answer for a greenfield AWS design.