Amazon MQ Broker
Does ZopNight manage Amazon MQ Broker?
Amazon MQ bills per broker-instance-hour at the provisioned size plus per-GB storage, running continuously regardless of message volume. A dev broker idling all month costs the same as a busy one. ZopNight discovers brokers on the 6-hour cycle, attributes per-broker cost from Cost Explorer or CUR 2.0, and flags idle and oversized brokers.
Rules that fire on Amazon MQ Broker
No active rule family targets Amazon MQ Broker today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery, cost tracking, and recommendations only. |
Amazon MQ runs managed ActiveMQ and RabbitMQ brokers billed per broker-instance-hour plus storage. Brokers run continuously at their provisioned size, so dev brokers and oversized production instances carry fixed cost regardless of message volume.
Broker-hours, not message counts
Amazon MQ prices like a server, not like a queue service: each broker instance bills hourly at its instance size, storage bills per GB-month, and message volume never appears on the meter. That distinction against SQS or SNS, which charge per request and cost nothing idle, defines the waste profile. A broker exists because some workload speaks AMQP, MQTT, or STOMP and could not move to native AWS messaging; once created, it bills its instance-hours around the clock, and highly available deployments run multiple instances (active/standby for ActiveMQ, 3-node clusters for RabbitMQ), multiplying the fixed floor.
Broker fleet visibility
ZopNight discovers brokers automatically on the 6-hour cycle, with per-broker cost attributed from Cost Explorer or CUR 2.0. Recommendations come in two shapes: idle brokers, whose connection and throughput signals show no workload has spoken to them in weeks (typically leftovers from a migration proof-of-concept or a retired integration), and rightsizing, for brokers provisioned at production sizes to carry trivial message rates. Brokers have no stop verb in the service API, so findings resolve through downsizing or deletion rather than scheduling.
The migration-era leak
Amazon MQ estates are usually born during migrations: lift-and-shift of an on-premises ActiveMQ, or a stepping stone toward SQS. Both journeys shed brokers. The mq.m5.large “temporary” broker that bridged two systems outlives the bridge. Per-environment broker copies mirror production’s multi-AZ deployment into dev and staging, paying high-availability prices for environments that tolerate downtime nightly. And single-consumer brokers persist where a plain SQS queue would cost effectively nothing.
Checking brokers in the console
The Amazon MQ console lists brokers with engine, instance type, and deployment mode. CloudWatch’s broker metrics for connections and enqueue rates separate the working brokers from the idle, and deployment mode is the quick tell for dev environments paying for standby instances they do not need.