SysPad › Lessons › messaging lessons › Amazon MQ

How Amazon MQ works

Managed message broker for ActiveMQ and RabbitMQ. Drop-in for existing JMS/AMQP apps. Throughput is bounded by the broker instance size, not an elastic service tier.

SQS and SNS are wonderful, if you’re building fresh on AWS. But what about the app that already talks to RabbitMQ or ActiveMQ over JMS and can’t be rewritten? Amazon MQ runs those exact brokers for you, so the app keeps its standard protocols and code and just points at a managed endpoint. It’s the bridge for lift-and-shift.

What you will learn

Why can’t every app just switch to SQS/SNS, and what gap does Amazon MQ fill?
What does "speaks standard protocols" actually buy you?
How is a broker (queues AND topics) different from SQS plus SNS?
When should you choose Amazon MQ over cloud-native messaging?

The migration gap

Plenty of existing systems are built on open-source brokers like ActiveMQand RabbitMQ, using standard APIs and protocols. Moving them to SQS/SNS means rewriting messaging code, often not worth it.

Amazon MQ runs those same broker engines as a managed service. The application connects with the same protocol and the same code; you mostly just change the connection endpoint.

Standard protocols = portability

Amazon MQ supports industry protocols, JMS, AMQP, MQTT, STOMP, and OpenWire. Because these are open standards, your code isn’t locked to a proprietary AWS API, and you keep portability across clouds or back on-prem.

A broker does queues AND topics

A traditional broker handles both queues (point-to-point, like SQS) and topics (pub/sub, like SNS) in one system, plus features such as message selectors, transactions, and various delivery guarantees the broker provides.

⚓ Common for enterprise integration, financial/trading systems, and anything built on JMS or classic enterprise messaging patterns.

When (and when not) to choose it

Choose Amazon MQ when you’re migrating an existing broker-based app, need standard protocols, or depend on broker features SQS/SNS lack. Choose SQS/SNSfor new, cloud-native workloads that want serverless scaling and tight AWS integration.

Flashcards

You have a RabbitMQ/JMS app you can’t rewrite. How do you get it onto AWS with minimal change?: Amazon MQ runs the same broker engine managed; the app keeps its protocol and code and just changes the endpoint.
What protocols does Amazon MQ speak, and why does that matter?: JMS, AMQP, MQTT, STOMP, OpenWire, open standards, so you avoid AWS-API lock-in and keep portability.
How does one broker relate to SQS and SNS?: A broker provides both queues (point-to-point, like SQS) and topics (pub/sub, like SNS) in a single system.
Is Amazon MQ serverless like SQS/SNS?: No, it runs on broker instances you size (active/standby or cluster for HA). SQS/SNS are serverless and auto-scaling.
Greenfield AWS app: Amazon MQ or SQS/SNS?: SQS/SNS, native, serverless, cheaper, and well integrated. Amazon MQ is for migrating existing standard-protocol broker apps.

Sources

Open the SysPad canvas · Official Amazon MQ documentation