AWS First Steps
LanguageEnglish

Amazon MQ

A fully managed message broker service offering Apache ActiveMQ and RabbitMQ, enabling migration of existing messaging applications to the cloud with minimal code changes

About 5 min read

Overview

Amazon MQ is a fully managed service providing two open-source message broker engines: Apache ActiveMQ and RabbitMQ. It supports industry-standard protocols including JMS, AMQP, STOMP, MQTT, and OpenWire, allowing existing on-premises messaging applications to migrate to the cloud without significant code rewrites. Broker provisioning, patching, failure detection, and failover are automated, reducing operational overhead. Multi-AZ active/standby configurations provide high availability, and ActiveMQ messages are persisted by default to Amazon EFS, which replicates data across multiple AZs.

Broker Engine Selection and Deployment Configurations

Amazon MQ offers a choice between two engines: ActiveMQ (the overview page and the FAQ use Apache ActiveMQ Classic) and RabbitMQ. ActiveMQ provides strong compatibility with existing Java applications using the JMS (Java Message Service) API and can handle complex routing and message transformation on the broker side based on Enterprise Integration Patterns (EIP). RabbitMQ's strength lies in flexible message routing through its Exchange types (Direct, Topic, Fanout, Headers), centered on the AMQP 0-9-1 protocol. Deployment configurations include single instance, active/standby (Multi-AZ), and RabbitMQ cluster deployment. Active/standby is recommended for production, automatically failing over to the standby broker when the primary fails. Clients use the Failover Transport (failover://) and are configured to connect to either endpoint of the redundant pair. For ActiveMQ, instance types include mq.t3.micro for evaluation and the mq.m5 family for production, sized according to message throughput and concurrent connection requirements.

ActiveMQ Network of Brokers and Persistence

The ActiveMQ engine supports a Network of Brokers configuration that logically connects multiple broker instances to forward messages between them. This is useful for relaying messages across geographically distributed systems or distributing broker load. Each broker maintains its own local queues and topics while forwarding messages to consumers on other brokers through network connectors. The developer guide states that ActiveMQ brokers use Amazon EFS storage by default and can also use Amazon EBS, while active/standby deployments use EFS and EBS is limited to single-instance brokers on the mq.m5 family. Persistent messages are kept across broker restarts and failovers. The storage capacity limit per broker depends on the instance type and is listed on the quotas page. Configuring a dead-letter queue (DLQ) routes failed messages to the DLQ and helps prevent main queue congestion. One operational pattern is to monitor DLQ depth via CloudWatch metrics and trigger alerts when thresholds are exceeded.

Authentication, Encryption, and Maintenance Windows

Amazon MQ security is structured across three layers: network, authentication, and encryption. Brokers are deployed in private subnets within a VPC, with security groups restricting access sources. Public access can be enabled but VPC-internal deployment is recommended for production. Authentication uses SimpleAuthenticationPlugin with username/password for ActiveMQ, and native user management for RabbitMQ; LDAP integration with an existing directory service is available on both engines (as of October 2026). In-transit encryption is secured via TLS, and data at rest is always encrypted; the developer guide states that you choose an AWS owned key (the default), an AWS managed key, or a customer managed key in AWS KMS. A weekly start time is specified for the maintenance window, during which engine patching and minor version upgrades are performed; the developer guide states that maintenance lasts up to two hours depending on the scheduled operations. In active/standby deployments, maintenance is performed one instance at a time so that at least one instance remains available, and clients connected to the active instance may experience a brief failover. AWS states in the developer guide that new brokers are not accepted on a version within 30 days of its end-of-support date, and that brokers on a version that reaches end of support are upgraded automatically to the next supported version during the maintenance window (as of October 2026). Monitoring CpuUtilization, HeapUsage, and StorePercentUsage via CloudWatch metrics helps detect capacity pressure early.

References (Official AWS Resources)

The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.

If this page and the official documentation disagree, treat the official documentation as authoritative.

Share

Related Terms

Amazon SQSAmazon SNSAmazon EventBridgeAmazon MSK

Related Services

Amazon SQSAmazon SNSAmazon EventBridgeAmazon MSKAWS Lambda

Related Articles

Event-Driven Architecture - Building Loosely Coupled Systems with Amazon EventBridgeLearn how to build event-driven architectures using Amazon EventBridge.Event Integration with Amazon EventBridge Pipes - Connection Patterns for Sources and TargetsThis article introduces design patterns that connect event sources such as SQS, DynamoDB Streams, and Kinesis directly to targets, with filtering and enrichment in between.Getting Started with Event Streaming on Amazon MSK Serverless - Building a Zero-Ops Kafka EnvironmentThis article introduces a method for building a Kafka environment that needs no cluster management with IAM authentication, and simplifying event streaming through integration with EventBridge Pipes.Notification Design with Amazon SNS - Topic and Subscription PatternsLearn how to choose between Standard and FIFO topics, implement the SQS fan-out pattern, and use subscription filters for conditional routing.Building Pub/Sub Messaging with Amazon SNS - Fan-Out Patterns and FilteringLearn about topic-based messaging with SNS, subscription filters, and the SQS fan-out pattern for scalable event distribution.

Similar Terms and Articles

Amazon MQA fully managed message broker service supporting Apache ActiveMQ and RabbitMQRunning a Message Broker with Amazon MQ - Choosing Between ActiveMQ and RabbitMQ and Migration PatternsCompare ActiveMQ and RabbitMQ selection criteria, explore migration patterns from on-premises, and learn about high-availability configurations. Also covers when to use SQS/SNS instead.Building an Apache Kafka Streaming Platform with Amazon MSK - Cluster Design and OperationsThis article covers designing managed Apache Kafka clusters, choosing between them and MSK Serverless, and data integration patterns with MSK Connect.Building Asynchronous Messaging with Amazon SQS - Designing Standard and FIFO QueuesLearn how to choose between Standard and FIFO queues, use DLQs for failed message handling, and automate processing with Lambda event source mappings.