Legacy vendor systems must exchange messages using JMS/AMQP with a city’s cloud workloads, while new cloud-native apps prefer simpler messaging. When is Amazon MQ the right choice?
Select an answer to reveal the explanation.
Short Explanation
Amazon MQ is the bilingual clerk who still speaks JMS/AMQP with old vendor systems; SNS and SQS are the modern intercoms for cloud-native apps. Don’t hire the bilingual clerk for every hallway chat—or pretend a message broker is a website CD rack.
Full Explanation
Amazon MQ is the right managed broker when legacy vendor systems must speak JMS/AMQP with the city’s cloud workloads. It provides compatible message brokers (e.g., ActiveMQ/RabbitMQ families as offered) so municipal integrations can keep protocol-level compatibility. For new cloud-native apps that only need simple pub/sub or queues, prefer Amazon SNS and Amazon SQS instead of forcing a full JMS/AMQP broker.
Always replacing SNS/SQS with Amazon MQ even when no legacy protocol is required fails by concept because it adds broker operational and cost weight without a protocol need. Using Amazon MQ only for storing static website assets instead of S3 fails because MQ is messaging, not object storage for websites. Disabling all messaging and requiring vendors to poll RDS tables over the public Internet fails as an insecure, tightly coupled anti-pattern that abandons brokers entirely.
Exam caveat: Amazon MQ → legacy JMS/AMQP compatibility; SNS/SQS → cloud-native messaging. Do not use MQ as a substitute for S3 or as a default replacement for SNS/SQS when protocols are not required.
Operational check: Verify legacy vendors connect with the required JMS/AMQP endpoints and credentials, cloud-native producers/consumers use SNS/SQS where appropriate, broker durability and failover meet SLAs, and no static web content is being stuffed into queues. If every simple notification runs through a full JMS broker “just because,” the selection is overfit.