Amazon MQ (RabbitMQ) clusterring

Question

There's one similar quiestion was asked before - https://repost.aws/questions/QUqs-K8J5BTOyCLEM_zOniUg/how-to-setup-amazonmq-rabbitmq-for-ha-3-nodes-in-3-servers-instead-of-3-nodes-in-same-server - answering that "three RabbitMQ broker nodes" will be created. I will ask my queistion anyway, since that's a bit more specific than just a "cluster mode" solution.

Does providing 2 subnets instead of 3 (and 2 AZs instead of 3) affect characteristics like availability and durability of the RabbitMQ broker in a cluster mode deployment?

*"Since we don't see any EC2 instances deployed in VPC we've created, we assume these broker nodes are deployed in the Amazon's private network. So the broker endpoint is made available through a service edpoint (+id of the broker), resolvable as a private network IPs and being reachible from the subnets we provide? And so, in case of 2 subnest provided, the only limitation would be having 2 entrypoints instead of 3 and there won't be any other functional limitations. There still will remain 3 broker nodes and not only 2."* - please approve or deny my team's assumption.

re:Post Agent · Accepted Answer

When deploying an Amazon MQ for RabbitMQ cluster, providing 2 subnets instead of 3 (and consequently 2 AZs instead of 3) does affect the characteristics of the broker deployment, particularly in terms of availability and durability.

In a cluster deployment, Amazon MQ creates a logical grouping of three RabbitMQ broker nodes behind a Network Load Balancer. These nodes share users, queues, and a distributed state across multiple Availability Zones. The default configuration ensures high availability and data durability by replicating data across all nodes in the cluster.

However, when you provide only 2 subnets (and thus 2 AZs), the cluster will still have 3 broker nodes, but they will be distributed across only 2 AZs instead of 3. This means that one AZ will have 2 nodes, while the other AZ will have 1 node. This configuration slightly reduces the overall availability and fault tolerance of the cluster compared to a deployment across 3 AZs.

Regarding your team's assumption:

1. It is correct that the broker nodes are deployed in Amazon's managed infrastructure, not in your VPC. You don't see EC2 instances in your account because Amazon MQ manages these resources.

2. The broker endpoint is indeed made available through a service endpoint, which is resolvable to private network IPs and accessible from the subnets you provide.

3. However, the assumption about having only 2 entry points instead of 3 is not entirely accurate. The cluster will still have a single endpoint provided by the Network Load Balancer, regardless of the number of subnets/AZs used.

4. You are correct that there will still be 3 broker nodes, not just 2, even when using only 2 subnets/AZs.

While using 2 subnets instead of 3 doesn't introduce significant functional limitations, it does slightly reduce the overall fault tolerance and availability of the cluster. For maximum availability and durability, it's recommended to use 3 subnets across 3 AZs when possible. However, if your region or specific requirements limit you to 2 AZs, the cluster will still provide a high level of availability and durability, just not quite as robust as a 3-AZ deployment.  
**Sources**  
[Deployment options for Amazon MQ for RabbitMQ brokers - Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/rabbitmq-broker-architecture.html)  
[Amazon MQ for RabbitMQ brokers - Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/rabbitmq-basic-elements.html)  
[Amazon MQ Features | Managed Message Broker Service | Amazon Web Services](https://aws.amazon.com/amazon-mq/features/)  
[Amazon MQ FAQs | Managed Message Broker Service | Amazon Web Services](https://aws.amazon.com/amazon-mq/faqs/)

Amazon MQ (RabbitMQ) clusterring

Relevant content