RabbitMQ brokers should use cluster deployment mode
Checks that an Amazon MQ for RabbitMQ broker uses cluster deployment: three broker nodes across Availability Zones with data replicated to every node. A node failure, a zone outage or a maintenance window then leaves the broker running, where a single-instance broker goes offline and can lose messages.
- service
- MQ
- severity
- Low
- scope
- evaluated in every region
How to fix it
- Replaces the resource: A broker's deployment mode is fixed at creation: create a cluster broker with this one's users, queues and policies, repoint clients, drain or shovel the messages, then delete it.
- Can break clients: Cluster nodes restart one at a time during maintenance and drop their connections, so clients that do not reconnect automatically lose the broker.
In the console
Amazon MQ → Brokers → Create brokers → RabbitMQ → Select deployment mode (fixed at creation)
- Deployment mode
- Cluster deployment
- Broker instance type
- An mq.m7g type, mq.m7g.large or larger for production
- RabbitMQ access
- An administrator user; then recreate the flagged broker's users, virtual hosts, queues and policies
With the AWS CLI
aws mq create-broker --broker-name <new-broker-name> --engine-type RABBITMQ --engine-version <engine-version> --deployment-mode CLUSTER_MULTI_AZ --host-instance-type <instance-type> --auto-minor-version-upgrade --no-publicly-accessible --subnet-ids <subnet-id> --users Username=<username>,Password=<password> --region <region>With Terraform
resource "aws_mq_broker" "cluster" {
broker_name = var.broker_name
engine_type = "RabbitMQ"
engine_version = var.engine_version
host_instance_type = var.host_instance_type
deployment_mode = "CLUSTER_MULTI_AZ"
subnet_ids = var.subnet_ids
auto_minor_version_upgrade = true
user {
username = var.username
password = var.password
}
}
See which of your accounts this check is failing on.
Book a live scan