Amazon EC2

This guide assumes familiarity with the general clustering guide as well the guide on cluster peer discovery.


Using RabbitMQ on EC2 is quite similar running it on other platforms. However, there are certain minor aspects to EC2 that need to be accounted for. They primarily have to do with hostnames and their resolution.

This guide uses manual (CLI-driven) RabbitMQ clustering. Other options exist that are more suitable for automation:

RabbitMQ Chef cookbook and RabbitMQ Puppet module can help with automating cluster provisioning.


Pivotal currently does not provide AMI images with RabbitMQ pre-provisioned. RabbitMQ works well on up-to-date Ubuntu, Debian and CentOS AMIs as long as a compatible version of Erlang/OTP is installed.

Choose Instance Type

First, you need to choose what instance type to run. RabbitMQ will work on every instance type, but there are a few considerations worth bearing in mind:

  • Use 64-bit instances.
  • Depending on the workload and settings, RabbitMQ can require substantial amounts of memory. Make sure that your host does have enough RAM and always have at least a few gigabytes of swap space enabled. Workloads can be simulated using PerfTest. A separate guide about reasoning about node memory usage is available.
  • RabbitMQ can take advantage of all the CPU cores in the system provided the workload uses multiple queues. Other factors should be taken into account (e.g. disk and network I/O throughput).
  • Monitoring RabbitMQ nodes as well as applications that use it on real or simulated workloads will help assess how suitable a particular instance type is.

Choose Operating System

Although RabbitMQ is tested with most major Linux distributions, Ubuntu support for Amazon EC2 seems to be strongest, so that's the distribution this guide will use. See Ubuntu Cloud Images and Ubuntu EC2 Starters Guide.

Install RabbitMQ

Please consult the installation guides for

A wide variety of deployment tools can be used to automate RabbitMQ deployment.

are some popular options.

Persistent Data on EBS Devices

RabbitMQ writes data to the following directories on Ubuntu:

  • /var/lib/rabbitmq/ to store persistent data like the messages or queues
  • /var/log/rabbitmq/ to store logs
See the File and Directory Locations for details.

If you choose to use EBS block device to store RabbitMQ node data directory, just link these directories to your EBS device. Stop RabbitMQ before making any changes to the data directory:

sudo service rabbitmq-server stop

Note that EBS volumes have an IOPS limits, which can impact thoughput and RabbitMQ message store operations. If an EBS volume hits the limit, disk writes will worsen. It is also possible that the RabbitMQ message store compaction (garbage collection of on-disk data) can fall behind disk writes, which means the disk will be filled up quicker than disk space can be reclaimed after messages were consumed and acknowledged. This will eventually lead to resource alarms and publisher throttling. Please make sure the limit is high enough and set up I/O operation rate monitoring.

Default user access

The broker creates a user guest with password guest. Unconfigured clients will in general use these credentials. By default, these credentials can only be used when connecting to the broker as localhost so you will need to take action before connecting from any other machine.

See the documentation on access control for information on how to create more users, delete the guest user, or allow remote access to the guest user.

Hostname Changes

RabbitMQ nodes use hostnames to communicate with each other. Therefore, all node names must be able to resolve names of all cluster peers. This is also true for tools such as rabbitmqctl.

In addition to that, by default RabbitMQ names the database directory using the current hostname of the system. If the hostname changes, a new empty database is created. To avoid data loss it's crucial to set up a fixed and resolvable hostname. Whenever the hostname changes RabbitMQ node must be restarted.

A similar effect can be achieved by using rabbit@localhost as the broker nodename. The impact of this solution is that clustering will not work, because the chosen hostname will not resolve to a routable address from remote hosts. The rabbitmqctl command will similarly fail when invoked from a remote host. A more sophisticated solution that does not suffer from this weakness is to use DNS, e.g. Amazon Route 53 if running on EC2. If you want to use the full hostname for your nodename (RabbitMQ defaults to the short name), and that full hostname is resolveable using DNS, you may want to investigate setting the environment variable RABBITMQ_USE_LONGNAME=true.

See the section on hostname resolution for more information.

Firewalled nodes

The case for firewalled clustered nodes exists when nodes are in a data center or on a reliable network, but separated by firewalls. Again, clustering is not recommended over a WAN or when network links between nodes are unreliable.

In the most common configuration you will need to open a number of standard ports:

  • 4369: epmd, a peer discovery service used by RabbitMQ nodes and CLI tools
  • 5672, 5671: used by AMQP 0-9-1 and 1.0 clients without and with TLS
  • 25672: used for inter-node and CLI tools communication (Erlang distribution server port) and is allocated from a dynamic range (limited to a single port by default, computed as AMQP port + 20000). Unless external connections on these ports are really necessary (e.g. the cluster uses federation or CLI tools are used on machines outside the subnet), these ports should not be publicly exposed. See networking guide for details.
  • 35672-35682: used by CLI tools (Erlang distribution client ports) for communication with nodes and is allocated from a dynamic range (computed as server distribution port + 10000 through server distribution port + 10010). See networking guide for details.
  • 15672: HTTP API clients, management UI and rabbitmqadmin (only if the management plugin is enabled)
  • 61613, 61614: STOMP clients without and with TLS (only if the STOMP plugin is enabled)
  • 1883, 8883: (MQTT clients without and with TLS, if the MQTT plugin is enabled
  • 15674: STOMP-over-WebSockets clients (only if the Web STOMP plugin is enabled)
  • 15675: MQTT-over-WebSockets clients (only if the Web MQTT plugin is enabled)
  • 15692: Prometheus metrics (only if the Prometheus plugin is enabled)
See RabbitMQ Networking guide for details.

Erlang Versions Across the Cluster

All nodes in a cluster must run the same minor version of Erlang: 19.3.4 and 19.3.6 can be mixed but 19.0.1 and 19.3.6 (or 17.5 and 19.3.6) cannot. Compatibility between individual Erlang/OTP patch versions can vary between releases but that's generally rare.

If you have any comments please let us know.

Getting Help and Providing Feedback

If you have questions about the contents of this guide or any other topic related to RabbitMQ, don't hesitate to ask them on the RabbitMQ mailing list.

Help Us Improve the Docs <3

If you'd like to contribute an improvement to the site, its source is available on GitHub. Simply fork the repository and submit a pull request. Thank you!