Skip to main content
This article explains Amazon MQ — AWS’s managed message broker service for applications that use Apache ActiveMQ or RabbitMQ. Message brokers let distributed systems and heterogeneous applications (different languages, platforms, or environments) exchange information reliably and asynchronously. Amazon MQ removes the operational burden of installing, running, and maintaining broker software so you can focus on building applications.
A slide titled "Why Do We Need Amazon MQ?" showing applications (Python, Go, Java) on the left connecting through an Amazon MQ icon to messaging brokers on the right (RabbitMQ and Apache ActiveMQ). The right side highlights benefits like simplified Setup, Operation, and Management.
Overview
  • Amazon MQ is a managed replacement for open-source brokers such as RabbitMQ and Apache ActiveMQ. AWS handles provisioning, patching, monitoring, recovery, and underlying EC2 instance management so you don’t need to run the broker infrastructure yourself.
  • Use Amazon MQ when you must preserve compatibility with existing broker clients or require broker features/protocols that a simple queue service cannot provide.
Why choose Amazon MQ
  • Seamless migration: Applications that already use RabbitMQ or ActiveMQ can move to Amazon MQ without code rewrites because the service supports the same protocols and broker behaviors.
  • Managed operations: AWS manages broker software, OS/instances, backups, and recovery, reducing operational overhead.
  • Security and network isolation: Brokers support encryption in transit and at rest, and can be deployed within your Amazon VPC for private endpoints.
How Amazon MQ differs from SQS and other AWS messaging services
  • Amazon SQS is a fully managed queue service optimized for native AWS applications and new designs. It is simple and serverless but uses a different API and semantics.
  • Amazon MQ is intended for lift-and-shift or hybrid scenarios where protocol compatibility (e.g., AMQP, MQTT, STOMP, OpenWire) and broker-specific features are required.
Key capabilities at a glance When to choose Amazon MQ vs SQS Key benefits
  • Decoupling: Producers and consumers can evolve independently, improving scalability and fault tolerance.
  • Reliable delivery: Built-in acknowledgements, redelivery, and dead-letter handling help ensure messages are processed.
  • Durability: Messages are persisted to avoid data loss across restarts or failures.
  • Protocol support: Existing clients can continue to use currently implemented protocols without code changes.
  • Scalability and throughput: Choose broker instance types and configurations to meet throughput and latency requirements.
If you are building a new application in AWS, prefer SQS for a simple, fully managed queue if it meets your needs. Use Amazon MQ when you must preserve compatibility with existing RabbitMQ/ActiveMQ clients or require broker-specific features.
Operational and integration details
  • Administration handled by AWS: provisioning, broker setup, software updates, failure detection, and automated recovery.
  • Network placement: Deploy brokers inside your Amazon VPC for private connectivity and fine-grained network controls.
  • Instance sizing: Multiple broker instance types are available to match CPU, memory, and network needs.
  • Integration: Amazon MQ can integrate with other AWS services. For example, you can have consumers trigger Lambda functions or use CloudWatch for monitoring broker metrics and alarms.
Common use cases
  • Low-latency event messaging: Real-time updates between services requiring broker semantics.
  • Lift-and-shift migrations: Move on-premises broker-based applications to AWS without rewriting message handling logic.
  • Hybrid architectures: Connect legacy systems to AWS-native services while preserving existing client protocols.
  • Event-driven processing: Use brokers to route messages to consumers that invoke downstream processing, including AWS Lambda or containerized consumers.
A presentation slide titled "Why Do We Need Amazon MQ?" showing RabbitMQ and Apache ActiveMQ logos and listing benefits like message queuing/decoupling, reliable delivery, message durability/persistence, and protocol support (MQTT, STOMP, AMQP, OpenWire). The slide is © KodeKloud.
Migration checklist (high level)
  • Inventory existing broker features and client protocols (exchanges, topics, routing keys).
  • Choose matching Amazon MQ engine (RabbitMQ or ActiveMQ) and instance types.
  • Plan network placement (VPC, subnets, security groups) and encryption requirements.
  • Test client connectivity against a staging broker and validate message semantics (durability, acknowledgements).
  • Configure monitoring and alerts (CloudWatch metrics, logs) and plan backups/retention.
A presentation slide titled "Amazon MQ – Use Cases" showing three colored panels. The panels list "Low-latency event messaging," "Migrate with flexible configuration," and "Invoke AWS Lambda functions" with matching icons.
Summary Amazon MQ offers a managed, secure, and scalable way to run RabbitMQ or ActiveMQ brokers in AWS. It’s the right choice when protocol compatibility and broker-specific features matter or when you need a straightforward path to migrate existing broker-based applications to the cloud without rewriting client code. Links and references

Watch Video