Amazon EC2

This guide assumes familiarity with the general clustering guide.


Using RabbitMQ on EC2 is quite similar running it on other platforms. However, the 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 traditional RabbitMQ clustering. It is worth noting that alternative solutions are available and can be 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 and CentOS AMIs.

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:

  • RabbitMQ will work on 32-bit operating system, but for production usage we recommend 64-bit instances.
  • RabbitMQ by default will take advantage of all the processors in the system. However a single strong CPU configuration might behave slightly better than a collection of weak processors.
  • In some cases RabbitMQ requires 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.

Choose operating system

Although RabbitMQ is tested with most major Linux distributions, Ubuntu support for Amazon EC2 seems to be strongest. You can get the list of Ubuntu AMI images here:
You may find more information in Ubuntu EC2 Starters Guide.

Install RabbitMQ

Ubuntu ships with RabbitMQ but it's often not the latest version. If you want the recent version, you may use our Debian repository. Here is a shell script that automates RabbitMQ installation on Ubuntu:

cat <<EOF > /etc/apt/sources.list.d/rabbitmq.list
deb testing main

curl -o /tmp/rabbitmq-release-signing-key.asc
apt-key add /tmp/rabbitmq-release-signing-key.asc
rm /tmp/rabbitmq-release-signing-key.asc

apt-get -qy update
apt-get -qy install rabbitmq-server

Instead of running it manually, you can tell the instance to run this script automatically during the first start. You can do it using the user-data-file command line option for the ec2-run-instances command. For example:

ec2-run-instances ami-XXX \
    --key ${EC2_KEYPAIR} \
    --instance-type m1.large \
    --region eu-west-1 \
Put your chosen AMI id in the place of ami-XXX. The string ${EC2_KEYPAIR} should be replaced with the public ssh keypair name that is going to be used to log in to the instance. You can find more information about ec2-run-instances command in EC2 Getting Started Guide.

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 you should restart RabbitMQ:

$ /etc/init.d/rabbitmq-server restart

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 hostname resolution guide 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 by Erlang distribution for inter-node and CLI tools communication and is allocated from a dynamic range (limited to a single port by default, computed as AMQP port + 20000). See networking guide for details.
  • 15672: HTTP API clients 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)
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.