AWS Messaging & Integration
MQ
Managed message broker for ActiveMQ and RabbitMQ to migrate existing apps
Amazon MQ is a managed message broker service that runs Apache ActiveMQ and RabbitMQ on AWS without requiring you to provision, operate, or maintain your own broker infrastructure. It is designed specifically for migrating existing applications that use industry-standard messaging protocols (AMQP, MQTT, OpenWire, STOMP) to the cloud without rewriting code. Unlike SQS and SNS, Amazon MQ is protocol-compliant - your existing on-premises broker code can connect to Amazon MQ with minimal changes.
Amazon MQ vs SQS/SNS: Which to Choose
This is the most important architectural decision when working with messaging on AWS. The answer almost always comes down to migration vs new development.
| Dimension | Amazon MQ (ActiveMQ/RabbitMQ) | SQS/SNS |
|---|---|---|
| Primary use case | Lift-and-shift of existing broker-based apps | New cloud-native applications |
| Protocol support | AMQP 0-9-1, AMQP 1.0, MQTT, OpenWire, STOMP, WebSocket | AWS SDK / REST API only |
| Code changes required | Change only the broker endpoint URL | Rewrite messaging code to use AWS SDK |
| Management overhead | Choose instance type, manage storage, patching | Fully serverless - no configuration |
| Throughput | Limited by broker instance size | Virtually unlimited (SQS) |
| Cost model | Pay for broker instances (always running) | Pay per message/request |
| Multi-protocol | Yes - same broker serves MQTT IoT and AMQP apps | No - each service has its own protocol |
| Message ordering | Yes - queues and topics preserve order | SQS FIFO for ordering |
AWS recommendation: use Amazon MQ only when migrating existing applications that use standard messaging protocols. For all new development on AWS, use SQS, SNS, or EventBridge. Amazon MQ carries operational overhead that the native AWS services do not.
ActiveMQ vs RabbitMQ on Amazon MQ
Amazon MQ supports two broker engines with different messaging models and feature sets.
| Feature | ActiveMQ | RabbitMQ |
|---|---|---|
| Architecture | Message broker with queues and topics | Exchanges route to queues (flexible routing) |
| Protocol | OpenWire, AMQP 1.0, MQTT, STOMP, WebSocket | AMQP 0-9-1, MQTT (plugin), STOMP (plugin) |
| Routing | Simple queue/topic model | Exchange types: direct, fanout, topic, headers |
| High availability | Active/standby pair | Cluster deployment across AZs |
| Management UI | ActiveMQ console | RabbitMQ management plugin |
| Message priorities | Yes | Yes (limited) |
| Plugin ecosystem | Limited | Rich plugin ecosystem |
| Typical migration from | Java JMS applications | Applications already using RabbitMQ |
ActiveMQ broker on Amazon MQ runs as an active/standby pair, not a cluster. Failover takes 10-30 seconds during which the broker is unavailable. For applications requiring sub-second failover, RabbitMQ cluster mode (active/active) is a better choice.
Deployment Options and High Availability
Amazon MQ offers different deployment modes depending on your availability requirements.
| Deployment Type | Engine | HA Model | Use Case |
|---|---|---|---|
| Single-instance broker | ActiveMQ or RabbitMQ | No HA - single point of failure | Development and testing |
| Active/standby | ActiveMQ only | Automatic failover, 10-30s downtime | Production workloads tolerating brief failover |
| Cluster (3-node) | RabbitMQ only | Active/active, no downtime failover | Production requiring zero-downtime failover |
# Create an Amazon MQ ActiveMQ active/standby broker
aws mq create-broker \
--broker-name my-production-broker \
--engine-type ACTIVEMQ \
--engine-version 5.15.16 \
--deployment-mode ACTIVE_STANDBY_MULTI_AZ \
--host-instance-type mq.m5.large \
--publicly-accessible false \
--subnet-ids subnet-abc123 subnet-def456 \
--security-groups sg-xyz789 \
--users '[{"Username":"admin","Password":"your-password","Groups":["admin"]}]'
# Get broker endpoints
aws mq describe-broker \
--broker-id broker-id-here \
--query 'BrokerInstances[*].Endpoints'Amazon MQ brokers are deployed inside your VPC with no public endpoint by default (and you should keep it that way). Applications in private subnets connect to the broker endpoint. Never expose Amazon MQ to the internet.
Instance Types and Sizing
| Instance Class | Use Case | Approximate Cost (us-east-1) |
|---|---|---|
| mq.t3.micro | Development, very low volume | ~$18/month single, ~$36 active/standby |
| mq.m5.large | Production small workloads | ~$200/month single, ~$400 active/standby |
| mq.m5.xlarge | Production medium workloads | ~$400/month single |
| mq.m5.2xlarge | High throughput production | ~$800/month single |
| mq.m5.4xlarge | Very high throughput | ~$1,600/month single |
Unlike SQS and SNS which scale automatically, Amazon MQ is bound by the instance type you choose. You must monitor broker memory, CPU, and network usage and scale up proactively. A full broker queue can cause message loss or producer backpressure.
Storage is a critical sizing consideration. ActiveMQ uses KahaDB on EBS storage. If the disk fills up, the broker stops accepting new messages. Monitor StoragePercentUsage CloudWatch metric and alert at 70%.
Migration Pattern: On-Premises to Amazon MQ
The typical migration pattern for on-premises message brokers to Amazon MQ follows a blue/green approach.
| Phase | Activity | Risk |
|---|---|---|
| 1. Deploy | Create Amazon MQ broker matching on-prem config (queues, topics, users) | Low - no traffic yet |
| 2. Connect producers | Update producer connection strings to Amazon MQ endpoint | Medium - producers now send to both or new only |
| 3. Drain on-prem | Let consumers drain existing on-prem messages | Low - consumers still processing |
| 4. Migrate consumers | Point consumers at Amazon MQ | Low - now fully on AWS |
| 5. Decommission | Shut down on-prem broker after stability period | Low |
For ActiveMQ migrations, most JMS-based Java applications only need the broker URL changed in application.properties or the JMS connection factory configuration. No code changes are required when using standard OpenWire protocol.
Interview Focus Points
- 1When would you choose Amazon MQ over SQS/SNS, and why does AWS recommend against Amazon MQ for new applications?
- 2What is the difference between ActiveMQ and RabbitMQ deployment options on Amazon MQ?
- 3How does Amazon MQ high availability work for ActiveMQ vs RabbitMQ?
- 4What happens to an Amazon MQ broker when the EBS storage fills up?
- 5Walk me through how you would migrate an on-premises ActiveMQ broker to Amazon MQ with minimal downtime.
- 6What protocols does Amazon MQ support and why does that matter for legacy application migration?
- 7How would you monitor Amazon MQ in production? What are the key CloudWatch metrics?
- 8What is the cost model difference between Amazon MQ and SQS for a workload processing 1 million messages per day?