Amazon MQ cost: broker instance hours plus storage

Quick answer

Amazon MQ bills broker instance hours by instance size, plus storage. A single-instance broker is cheapest; an active-standby deployment roughly doubles instance cost for automatic failover. It suits teams needing managed ActiveMQ or RabbitMQ with standard protocols; for high-throughput cloud-native messaging, SQS or Kinesis is usually cheaper.

Amazon MQ is managed ActiveMQ and RabbitMQ, aimed at teams that need standard messaging protocols (JMS, AMQP, MQTT, STOMP) without running the broker themselves. Its pricing is the familiar managed-instance shape: broker hours plus storage.

Broker hours and deployment

Deployment	Instances	Trade
Single-instance broker	1	Cheapest, no automatic failover
Active-standby (ActiveMQ)	2	~2x cost, automatic failover
Cluster (RabbitMQ)	3	Higher cost, higher availability

You pay per broker instance-hour by size, plus storage for messages. A single-instance broker is cheapest and fine for dev or non-critical use. Active-standby runs a second instance for automatic failover, roughly doubling instance cost, and a RabbitMQ cluster runs three nodes for higher availability at higher cost.

When Amazon MQ fits

Choose Amazon MQ when you need the standard protocols and semantics of ActiveMQ or RabbitMQ, often to lift-and-shift an existing application or integrate with systems that speak those protocols. For new cloud-native messaging without a protocol requirement, SQS, SNS, and EventBridge are serverless and usually cheaper, since you avoid always-on broker instances.

Controlling Amazon MQ cost

Right-size the broker instance to real throughput, use single-instance brokers for non-production and active-standby only where failover is required, and clean up message storage. Because the broker is always on, the main lever is not over-sizing or over-replicating it, the same discipline as any managed instance.

FAQ

How is Amazon MQ priced?

By broker instance-hour, based on instance size, plus storage for messages. A single-instance broker is cheapest; an active-standby deployment runs a second instance and roughly doubles instance cost, and a RabbitMQ cluster runs three nodes at higher cost.

Does Amazon MQ active-standby cost more?

Yes, roughly double the single-instance cost, because it runs a second broker instance for automatic failover. Use active-standby where high availability is required and single-instance for dev and non-critical workloads to avoid the doubled cost.

When should I use Amazon MQ instead of SQS?

When you need the standard protocols and semantics of ActiveMQ or RabbitMQ (JMS, AMQP, MQTT, STOMP), typically to lift-and-shift an existing application or integrate with systems that speak them. For new cloud-native messaging without a protocol requirement, SQS is serverless and usually cheaper.

How do I reduce Amazon MQ cost?

Right-size the broker instance to real throughput, use single-instance brokers for non-production and active-standby only where failover is required, and manage message storage. Since the broker is always on, avoiding over-sizing and over-replicating it is the main lever.

Is Amazon MQ or SQS cheaper?

SQS is usually cheaper for suitable workloads because it is serverless and bills per request with no always-on broker, while Amazon MQ bills broker instance-hours continuously. Choose Amazon MQ when you specifically need its protocols; otherwise SQS avoids the broker cost.

Does C3X estimate Amazon MQ cost?

C3X prices the aws_mq_broker resource, including its instance type and deployment mode, from your Terraform, so broker instance and standby cost appear before deploy. Storage depends on message volume, which you provide as a usage assumption.

What to do next

Price your broker before you deploy. C3X reads your Terraform and prices Amazon MQ and the rest of your stack against a live catalog. Start with the quickstart.