Amazon MQ Pricing: Real Costs for 2026 + Calculator

An mq.m5.large RabbitMQ cluster in us-east-1 costs over $700 per month before you send a single message. I've seen teams provision one for a new microservices project without realizing that number, then spend the next two sprints trying to figure out why their AWS bill spiked.

Amazon MQ pricing catches people off guard because the costs aren't where you expect them. You're not paying per message like SQS. You're paying for the broker infrastructure running continuously, plus storage, plus data transfer fees that didn't exist before 2024. And the deployment mode you pick (single instance, active/standby, or 3-node cluster) multiplies that base cost by 1x, 2x, or 3x respectively.

This guide covers every pricing dimension with current 2026 numbers, walks through real monthly cost examples for the most common configurations, and shows you when SQS is actually the cheaper option. For a quick estimate of your specific setup, use the Amazon MQ pricing calculator to model both ActiveMQ and RabbitMQ configurations.

All pricing below reflects US East (N. Virginia) rates as of March 2026 unless noted otherwise. Rates vary by region.

How Amazon MQ Pricing Works

Amazon MQ billing has three dimensions, and understanding their relative weight is the key to understanding your bill. Most guides list all three as if they're equally important. They're not.

According to the official Amazon MQ pricing page: "You pay only for what you use. There are no minimum fees or upfront commitments. You pay for the time your message broker instance runs, the storage you use monthly, and standard data transfer fees."

That hierarchy matters. Broker instance hours typically account for 90%+ of your monthly bill for small-to-medium storage configurations. Storage is often under $5/month. Data transfer is variable but predictable once you understand the model.

Here's the model in plain terms before we dig into the numbers.

Broker Instance Hours: The Dominant Cost

You're charged per second of broker runtime (billed at one-second resolution, despite being described as "hourly"). The rate depends on two factors: instance type and deployment mode.

Deployment modes and their cost multipliers:

• Single instance: 1 broker running. You pay the per-hour rate once. No HA - the broker goes offline during maintenance windows.
• Active/standby (ActiveMQ): 2 brokers running at all times (primary + standby). You pay 2x the single-instance rate. Automatic failover to standby if primary fails.
• 3-node cluster (RabbitMQ): 3 brokers running at all times. You pay 3x the single-instance rate. This is what catches teams off guard - a "single" cluster is three times the cost of one broker.

Most people choose single-instance for dev/test and active/standby or cluster for production. The deployment mode difference is the single biggest cost lever before you even look at instance sizing.

Storage: EFS vs EBS

Amazon MQ supports two storage types, but the choice depends on your engine:

• ActiveMQ: Choose between EFS (durability-optimized, $0.30/GB-month) and EBS (throughput-optimized, $0.10/GB-month)
• RabbitMQ: EBS only at $0.10/GB-month

EBS is 3x cheaper per GB. For most workloads, EBS is the right call unless you have specific durability requirements that need EFS's shared file system model. That said, storage rarely dominates your bill. An mq.m5.large active/standby with 10GB of EFS storage adds $0.19/month in storage charges against a $428.54 broker bill.

The place storage matters is message retention at scale. If you're holding millions of large messages in queue for extended periods, those GB-months add up.

Data Transfer and the Costs That Surprise People

Three data transfer charges apply to Amazon MQ:

Cross-AZ traffic: $0.01/GB in each direction. For active/standby configurations, replication between primary and standby brokers in different AZs incurs this charge. High-throughput brokers can accumulate meaningful cross-AZ costs over a month.

Cross-region data transfer: Standard EC2 data transfer rates apply. For example, us-east-1 to us-west-2 runs $0.02/GB outbound. For cross-region replication configurations, there's an additional $0.10/hour per broker charge on top of the data transfer rate.

Public IPv4 address charges: This is the one teams consistently miss. Since 2024, every Amazon MQ endpoint incurs public IPv4 address charges at $0.005/hour, which works out to approximately $3.65/month per address. A single-instance broker = 1 address (~$3.65/month). An active/standby pair can mean multiple addresses. A 3-node cluster multiplies accordingly.

The IPv4 charge isn't large in isolation, but it's an example of the "hidden" charges that make your actual bill higher than the instance cost alone.

Also worth noting: if your Amazon MQ brokers run in private subnets (which is a good security practice), any internet-bound traffic from those subnets goes through NAT Gateway. That adds NAT Gateway data transfer costs on top of the Amazon MQ charges.

Amazon MQ Pricing Tables by Instance Type

Amazon MQ uses separate instance families for each engine. ActiveMQ runs on the mq.m5 family (Intel x86). RabbitMQ runs on the mq.m7g family (AWS Graviton3), which AWS now recommends for all new RabbitMQ deployments.

One important note: mq.t2.micro and mq.m4.large reached end-of-support on March 17, 2025. If you're still on either, you need to migrate.

ActiveMQ Broker Pricing (mq.m5 and mq.t3 instances)

The mq.t3.micro is evaluation-only and only supports EFS storage. Don't use it for production. The mq.m5.large is the most common production entry point - $429/month for an active/standby pair is what most teams start with.

RabbitMQ Broker Pricing (mq.m7g instances)

The cluster hourly rates above show what you pay per hour for the entire 3-node cluster. AWS prices by individual node at $0.2734/hr for mq.m7g.large, so 3 nodes = $0.8202/hr. That $610/month figure is before storage.

What Amazon MQ Actually Costs: Real Monthly Examples

Amazon MQ pricing tables give you rates. What you actually need is bill estimates. Here are four configurations that cover the majority of real-world deployments, pulled directly from the official AWS pricing examples.

ActiveMQ Single Instance (Dev/Test)

The cheapest starting point for development and testing:

mq.m5.large single instance (us-east-1, 10GB EFS storage, 31 days):

The mq.t3.micro drops this to around $20-25/month, but with only 1 GiB of memory it's really only useful for basic functional testing. Any workload that resembles production should use mq.m5.large at minimum.

A key trade-off: single-instance means zero HA. When AWS patches the broker, it's offline. For dev/test that's acceptable; for anything customer-facing, it's not.

ActiveMQ Active/Standby (Production HA)

This is the most common production configuration for ActiveMQ teams. Based directly on Pricing Example 1 from the AWS pricing page:

mq.m5.large active/standby (us-east-1, EFS storage, 31 days):

The AWS example shows $428.73 (broker + storage only). Add IPv4 charges and you're closer to $436/month. That's the more realistic figure.

$436/month before any data transfer charges. For a message broker that might handle your entire async workload, that's a significant baseline to budget.

RabbitMQ 3-Node Cluster (The 3x Multiplier Explained)

This is where new Amazon MQ users get surprised. A RabbitMQ cluster is three separate broker instances, not one. You're billed for each node individually. Based on Pricing Example 2:

mq.m5.large RabbitMQ cluster (us-east-1, EBS storage, 200GB default limit, 31 days):

The AWS example shows $702.82. Add IPv4 charges and you're at approximately $714/month.

Compare this to the ActiveMQ active/standby: $436 vs. $714/month for the same mq.m5.large instance size. RabbitMQ cluster mode is 64% more expensive because it runs three nodes instead of two. The higher per-node count is also why the default 200GB storage limit hits you harder - 200GB x 3 EBS volumes = 600 GB-Months of storage at $60/month.

Cross-Region Replication (The Most Expensive Config)

If you need true geographic disaster recovery with ActiveMQ, the cross-region replication config adds substantial costs on top of two active/standby pairs. Based on Pricing Example 4:

mq.m5.large active/standby primary (us-east-1) + replica (us-west-2), EFS storage, 31 days:

That's a 135% premium over a single-region active/standby configuration. The $148.80/month cross-region replication charge alone exceeds what many teams pay for their entire dev/test environment.

When it's worth it: true disaster recovery requirements where you need RPO measured in seconds and automated failover across AWS regions. If your DR strategy allows for manual recovery steps or longer RPO windows, multi-AZ active/standby within one region is almost always sufficient.

ActiveMQ vs. RabbitMQ: Which Engine Costs More?

Engine choice is usually driven by protocol requirements, not cost. If you're migrating from an on-premises RabbitMQ deployment, you use RabbitMQ. If you need JMS, AMQP 0-9-1, MQTT, or STOMP, you use ActiveMQ. The protocol requirements come first.

That said, the cost difference between engines is significant at production scale, and it's worth understanding before you provision anything.

Here's the direct cost comparison at the production tier. The mq.m5.large row for RabbitMQ is included for like-for-like comparison with ActiveMQ, but AWS recommends mq.m7g for all new RabbitMQ deployments:

Two things explain the cost difference:

Node count: ActiveMQ active/standby runs 2 nodes. RabbitMQ cluster runs 3. One extra node at $0.288/hr over a month = ~$214 more.

Storage model: ActiveMQ active/standby uses shared EFS storage (one storage volume between two nodes). RabbitMQ cluster uses separate EBS volumes per node. At 200GB default limit, that's 3 volumes x 200GB x $0.10 = $60/month vs. a few cents for a small EFS share.

Switching RabbitMQ from mq.m5 to mq.m7g (Graviton) gets you from $714/month down to approximately $625/month - a 12.5% reduction. I'll cover Graviton more in the optimization section, but it's worth noting upfront: if you're on RabbitMQ and haven't switched to mq.m7g yet, that's money you're leaving on the table.

Amazon MQ vs. SQS: When Does Each Make Financial Sense?

This is the question architects ask before committing to Amazon MQ. The answer is more nuanced than "SQS is cheaper" - because sometimes it isn't, and sometimes the cost comparison is irrelevant.

The pricing models are fundamentally different:

• Amazon MQ: Fixed infrastructure cost. The broker runs 24/7 and you pay for it whether you send 1 message or 1 million that day. A dev team with a light workload pays the same as a high-volume production system for the same instance type.
• SQS: Pure usage-based. Zero messages = zero cost (after the free tier). No infrastructure to run.

The Pricing Model Difference

Amazon MQ charges you from the moment the broker starts. Send zero messages: still paying $20-436+/month. Send 100 million messages: still paying the same broker cost. Storage scales with message retention, but the instance cost is constant.

SQS has 1 million free requests per month, then approximately $0.40 per million requests for Standard queues. There's no minimum infrastructure cost. Zero messages genuinely means zero cost.

This makes Amazon MQ economical only when you have sustained high utilization that justifies the fixed cost, or when protocol requirements force the choice.

Cost Comparison by Message Volume

SQS wins on pure cost for virtually every workload except extremely high-volume scenarios. At 10B messages/month, Amazon MQ (mq.m5.large) starts to look competitive. But by that volume, you're probably past the point where instance sizing matters more than the base pricing model.

For a quick SQS cost estimate, the SQS pricing calculator lets you model request volumes against the tiered pricing structure.

When to Use Each (Decision Framework)

Use SQS when:

• Your application is greenfield and cloud-native
• You don't need AMQP, JMS, MQTT, or STOMP protocol support
• Message volume is unpredictable or bursty
• You want serverless integration with Lambda triggers
• Cost sensitivity is the primary concern

Use Amazon MQ when:

• You're migrating from on-premises RabbitMQ or ActiveMQ (lift-and-shift)
• Your application requires legacy messaging protocols
• You need broker-specific features: message selectors, VirtualTopics (ActiveMQ), exchanges with complex routing (RabbitMQ)
• You have a stable, sustained workload and want managed infrastructure for the broker tier

Cost is rarely the deciding factor when choosing Amazon MQ over SQS. If you're reaching for Amazon MQ, it's almost always because of protocol requirements or a migration path, not because it's cheaper.

Amazon MQ Free Tier: What's Actually Free in 2026

Amazon MQ changed its free tier model in July 2025, and it matters if you're evaluating the service for the first time.

The new model (starting July 15, 2025): New AWS customers receive up to $200 in AWS Free Tier credits that apply to eligible services, including Amazon MQ. At account sign-up, you choose between a free plan (available for 6 months after account creation) and a paid plan. Any remaining credits at upgrade automatically apply to your bills. All credits expire within 12 months of account creation.

What $200 actually covers for Amazon MQ:

• mq.t3.micro single instance at ~$0.027/hr: roughly 7,400 hours (~10 months) of usage
• mq.m5.large single instance at $0.288/hr: roughly 694 hours (~29 days) of usage
• mq.m5.large active/standby at $0.576/hr: roughly 347 hours (~14.5 days) of usage

Put simply: $200 gets you months of evaluation time on the smallest instance, or less than a month on a production instance size.

The free tier gotchas:

The credits cover broker instance hours, but a few things still charge normally:

• Data transfer to/from the internet runs at standard EC2 rates, even on free tier
• Public IPv4 address charges ($0.005/hr per endpoint) apply on top of credits
• Cross-AZ data transfer ($0.01/GB each direction) still charges
• Active/standby and cluster modes consume credits twice and three times as fast - stay on single-instance to stretch the $200

If your AWS account was created before July 15, 2025, you may be on the previous model: 750 hours/month of mq.t3.micro for 12 months for ActiveMQ, plus 20GB EBS storage for RabbitMQ. That was more generous for extended evaluation but less flexible in terms of instance choices.

4 Ways to Reduce Your Amazon MQ Bill

For teams already running Amazon MQ in production, four levers can move the needle without changing your application architecture. These fit within a broader AWS cost optimization strategy - Amazon MQ is often one component of a larger bill. I always recommend going through them in this order - highest ROI first, lowest risk first.

1. Right-Size Your Broker Instance

Most teams that have been running Amazon MQ for six months or more are over-provisioned. The initial sizing is conservative, the workload turns out to be lighter than expected, and no one revisits it.

The CloudWatch metrics to check:

• ActiveMQ: CPUUtilization and HeapUsage
• RabbitMQ: SystemCpuUtilization and RabbitMQMemUsed

If CPUUtilization is consistently below 40-50%, you're a good candidate for downsizing by one instance size. The math on this is compelling: mq.m5.2xlarge to mq.m5.xlarge saves approximately $857/month on an active/standby pair - the difference between a $1,714/month pair and an $857/month pair. Even mq.m5.xlarge to mq.m5.large saves $428/month.

Broker resizing requires a maintenance window. For active/standby configurations, AWS performs a rolling update, so actual downtime is minimized. For single-instance, expect brief downtime during the resize. Plan accordingly, but don't let the maintenance window stop you from capturing real savings.

For the right-sizing analysis to be useful, you need enough historical data. Make sure you have CloudWatch log retention configured so you can look at 30-60 days of utilization before making a sizing decision.

2. Switch to Graviton (mq.m7g)

This one is specific to RabbitMQ and it's the lowest-friction cost reduction available. AWS recommends mq.m7g for all new RabbitMQ deployments - see the mq.m7g instance specifications for full details. If you're still on mq.m5, the switch saves money without changing your application.

The numbers from AWS Pricing Example 5:

The mq.m7g.large runs at $0.2734/hr vs. $0.288/hr for mq.m5.large - about a 5% per-hour savings. The total bill reduction is larger because mq.m7g clusters also have a smaller default storage footprint (15 GiB default vs. 200 GiB for mq.m5 clusters in the examples), though this varies based on your actual configuration.

Migrating is a broker modification that triggers a rolling restart across the three cluster nodes. Cluster mode means one node restarts at a time while the others continue serving traffic, so the migration is operationally low-risk.

Note: mq.m7g is RabbitMQ only. ActiveMQ uses mq.m5 exclusively - there's no Graviton option for ActiveMQ.

3. Use Reserved Capacity

Amazon MQ supports reserved capacity commitments at 1-year and 3-year terms. Similar to EC2 Reserved Instances, you commit to a specific instance type in a specific region in exchange for a discount on the on-demand rate.

Reserved capacity makes sense when:

• Your workload is stable and you're confident the instance type won't change for the commitment period
• You've already right-sized (right-size first, then reserve - reserving an oversized instance locks in the waste)
• You're running the broker 24/7 with no plans to scale down

The specific discount percentages for Amazon MQ reserved capacity aren't published in the same prominent format as EC2 Reserved Instance tables. Check the reservation purchase flow in the Amazon MQ console or AWS Cost Explorer for current 1-year and 3-year rates for your instance type and region. As a reference, commitment-based discount programs across AWS services typically offer 20-40% for 1-year terms and 40-60% for 3-year terms.

One constraint: reserved capacity is per-region and per-instance-type. Committing mq.m5.large in us-east-1 doesn't apply to mq.m5.large in eu-west-1 or to mq.m5.xlarge in any region. Plan your reserved capacity purchases carefully.

4. Optimize Storage Type Selection

This applies to ActiveMQ only - RabbitMQ uses EBS exclusively. If you're running ActiveMQ with EFS storage and don't have specific durability requirements that need EFS, switching to EBS cuts your storage cost by two-thirds.

EFS at $0.30/GB-month vs. EBS at $0.10/GB-month: the difference is real at scale. For a broker retaining 100GB of messages, that's $30/month vs. $10/month - $20/month in pure storage savings.

When to stay on EFS: you specifically need the durability model of shared file storage, or your workload is write-heavy in a pattern that benefits from EFS's durability guarantees. Most general-purpose message broker workloads don't have these requirements.

Storage type selection happens at broker creation and can't be changed in place. To switch, you'd need to create a new broker with EBS and migrate connections over. Factor that operational cost into the ROI calculation.

Regional Pricing: Where Amazon MQ Is Cheapest

Amazon MQ pricing varies by region, and the differences are meaningful enough to affect architecture decisions - particularly for teams with data sovereignty constraints that might be considering a more expensive region.

US East (N. Virginia) is consistently the cheapest AWS region for Amazon MQ. Here's how other major regions compare for an mq.m5.large active/standby configuration:

São Paulo is consistently one of the most expensive AWS regions - typically 25-50% more than us-east-1 across most services. Amazon MQ follows the same pattern. Running the same mq.m5.large active/standby pair in sa-east-1 vs. us-east-1 costs roughly $215/month more. Over a year, that's $2,580 in pure regional premium.

For cross-region replication architectures, the regional premium compounds: you pay the per-region rate for both the primary and replica brokers, plus the $0.10/hour/broker cross-region replication charge. An us-east-1 + sa-east-1 active/standby pair plus cross-region replication runs approximately $1,220/month - versus $1,006/month for the same setup using us-east-1 + us-west-2.

If data sovereignty allows it, us-east-1 or us-west-2 are the most cost-effective regions for Amazon MQ. For EU data residency requirements, eu-west-1 (Ireland) is typically slightly cheaper than eu-central-1 (Frankfurt). Check the official Amazon MQ pricing page and select your target region from the dropdown to verify current rates before committing to a region.

If you want to clean up unused public IPv4 resources across regions as part of this audit, there's a useful guide on how to clean up unused public IPv4 addresses across AWS regions that can help reduce related charges.

Amazon MQ Pricing: Key Takeaways

Here's what to take away from everything above:

1. Broker instance hours dominate your bill at 90%+ of total cost for typical workloads. Focus optimization effort there first.
2. The deployment mode multiplier is the biggest shock for new users. Single instance = 1x, active/standby = 2x, RabbitMQ cluster = 3x the hourly rate.
3. RabbitMQ clusters cost significantly more than ActiveMQ active/standby at the same instance size (~$714 vs. ~$436/month at mq.m5.large). Graviton (mq.m7g) narrows the gap to ~$625/month.
4. SQS is almost always cheaper for cloud-native, protocol-agnostic workloads. Amazon MQ earns its cost premium through legacy protocol support and managed broker operations for migration scenarios.
5. The fastest cost reduction: check CloudWatch CPU metrics, right-size if consistently under 50%, and switch to mq.m7g if on RabbitMQ. No application changes required.

Use the Amazon MQ pricing calculator to model your specific configuration before provisioning. You can compare engine types, deployment modes, and regions side by side to avoid the sticker shock that comes with the first monthly bill.

What's your current Amazon MQ configuration, and which of these optimization levers have you tried? Drop a comment below.

Frequently Asked Questions