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
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 all automated, dramatically reducing operational overhead. Multi-AZ active/standby configurations ensure high availability, while message persistence to EBS volumes guarantees data durability.
Broker Engine Selection and Deployment Configurations
Amazon MQ offers a choice between two engines: ActiveMQ 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. Three deployment configurations are available: 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. Failover typically completes within 60 seconds, with client-side reconnection logic (failover:// transport) handling the switch transparently. Instance types range from mq.m5.large to mq.m5.4xlarge, 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. Message persistence is handled via EBS volumes, ensuring messages survive broker restarts and failovers. ActiveMQ's KahaDB store serves as the default persistence engine, with storage capacity configurable from 20 GB to 200 GB. Dead-letter queue (DLQ) configuration is operationally critical - routing failed messages to a DLQ prevents main queue congestion. Monitoring DLQ depth via CloudWatch metrics and triggering alerts when thresholds are exceeded is a standard operational pattern in practice.
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 is supported only with the ActiveMQ engine. In-transit encryption is secured via TLS, and at-rest encryption uses either AWS KMS customer-managed keys or AWS-managed keys. A weekly 2-hour maintenance window is specified for engine patching and minor version upgrades. With active/standby configurations, rolling updates minimize service interruption during maintenance. Monitoring CpuUtilization, HeapUsage, and StorePercentUsage via CloudWatch metrics to detect capacity pressure early is key to stable operations.