Amazon MQ Pricing: $700/Month Before Your First Message

Amazon MQ is the AWS-managed message broker service running either ActiveMQ or RabbitMQ. It is the most expensive entry point in the AWS messaging family by a wide margin — production-grade deployments start at roughly $700/month before a single message moves. The premium pays for protocol compatibility with AMQP, JMS, STOMP, MQTT, and OpenWire — protocols that SQS and SNS do not support. For applications that can speak the AWS-native messaging API, MQ is dramatically more expensive than the equivalent SQS setup; for applications locked to the broker protocols, MQ is the only managed option short of running your own broker on EC2.

This post is the bill story. For the broader messaging-architecture decision — when MQ vs SQS vs SNS vs EventBridge vs Kafka — our reliable queue systems on AWS post covers the trade-offs.

The Five MQ Billing Dimensions

Why $700/Month Is the Realistic Production Entry Point

The math:

• mq.m5.large active/standby HA: $440/month (the smallest broker tier suitable for production HA)
• 200 GB ActiveMQ EFS storage: $60/month (or 200 GB RabbitMQ EBS: $20/month)
• Data transfer: $20–$50/month typical
• CloudWatch monitoring: $10–$30/month for standard alarms and dashboards

Total: ~$700/month for ActiveMQ HA, ~$520/month for RabbitMQ HA, before any message traffic. For workloads that only need a handful of messages per second, this is dramatically more expensive than the SQS equivalent (which would be measured in dollars per month for the same volume).

ActiveMQ vs RabbitMQ on MQ

Both run on Amazon MQ with the same per-broker-hour pricing. The differences:

The Real Comparison: MQ vs SQS vs Self-Managed RabbitMQ

For a workload that needs message queuing, the three managed/quasi-managed options on AWS produce dramatically different bills:

When MQ Is the Right Answer

A 30-Day MQ Bill Cleanup Plan

Week 1 — Broker inventory. List every MQ broker via aws mq list-brokers. Identify brokers whose source applications have been retired or deprecated. Delete the unused brokers.

Week 2 — Right-size active brokers. Review CloudWatch metrics for each broker (CPU utilization, memory, message throughput). Downsize over-provisioned brokers; the broker tier change requires brief downtime but the per-hour cost drops immediately.

Week 3 — Storage audit. For ActiveMQ brokers, audit EFS storage usage. Implement message-retention policies that delete old messages from queues. For RabbitMQ, audit EBS storage and apply queue TTL policies.

Week 4 — Migration evaluation. For each remaining MQ workload, evaluate whether the protocol dependency is genuinely load-bearing. Document workloads where migration to SQS could happen if the cost savings justify the rewrite.

What This Post Doesn’t Cover

• Migration from on-premises ActiveMQ / RabbitMQ to Amazon MQ — operational migration patterns covered in our messaging migration content.
• MSK (Managed Kafka) pricing in depth — different primitive (streaming vs messaging); covered in a separate streaming-platform post.
• Self-managed RabbitMQ HA architecture on EC2 — covered in our messaging architecture content for teams choosing this path.
• MQ Connector / federation patterns — covered in messaging-architecture content; usually not bill-relevant.

If You Only Do One Thing This Week

Audit your MQ brokers for active usage. Run aws mq list-brokers and for each broker check CloudWatch SystemActiveConnections and MessagesEnqueued over the last 30 days. Any broker with sustained low or zero traffic is a candidate for deletion or downsizing. Brokers tend to outlive the applications they serve; an audit twice a year catches the orphans before they accumulate.

For the broader messaging-architecture decision — when MQ vs SQS vs Kafka — the reliable queue systems guide covers the trade-offs and the patterns for migrating between primitives when the workload outgrows the original choice.