RabbitMQ 4.4.0 Message Broker on AWS User Guide

Overview

This guide covers launching and using the RabbitMQ 4.4.0 Message Broker on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg streaming and messaging listing on AWS Marketplace. You pick it as the software version when you subscribe.

RabbitMQ is an open source message broker (MPL-2.0) that runs on Erlang/OTP. Producers publish messages to exchanges, the broker routes them into queues, and consumers read from the queues. This image serves AMQP 0-9-1 and AMQP 1.0 over TLS, so any maintained AMQP client library works with it (pika, the Java and .NET clients, amqplib, Bunny, and others).

What the cloudimg image adds:

• AMQP over TLS only. Clients on the network reach the broker on 5671 (AMQPS: TLS 1.3 or 1.2 with AEAD cipher suites only). Plain AMQP (5672) is switched off in RabbitMQ's own configuration (listeners.tcp = none). The MQTT, STOMP, Web-MQTT, Web-STOMP, Stream and Prometheus plugins are not enabled. Nothing answers on those ports, even if a security group allows them.
• A certificate made on your instance. At first boot the broker gets a TLS key and an end-entity certificate for this instance's own names and addresses. The certificate cannot sign other certificates. You pin it in your clients (Step 5), or replace it with one from your own CA (Step 12).
• No default account. RabbitMQ's built-in guest user is never created. First boot generates two logins unique to your instance:
• cloudimg-admin, the administrator. It works the console and the HTTP API, but it can use AMQP only from the instance itself.
• cloudimg-app, an application user. It is confined to the cloudimg-app virtual host and to queue and exchange names that start with app..

Only salted password hashes ever reach the broker. * Erlang distribution kept on the instance. The node is rabbit@localhost. Its peer discovery daemon (epmd, 4369), the inter-node and CLI port (25672) and the CLI tools listen on 127.0.0.1 only. The Erlang cookie, the shared secret that lets a process control the node, is minted on your instance at first boot (Step 10). No two instances share one. * A broker that refuses to run unsafely. * Before every start, a configuration gate refuses an unsafe change. Examples: a plain-text listener, a console bound to the network, a non-loopback guest, the ANONYMOUS login mechanism, a refused plugin, or Erlang distribution off loopback. * After every start, a guard checks the running broker: its users, its passwords, its listeners and anonymous access. If the broker is unsafe, the guard stops it. * The management console over HTTPS. The console listens on 127.0.0.1 only. nginx serves it on 443 with the same certificate. nginx refuses requests for host names that are not this instance's, and blocks cross-site requests and WebSocket upgrades. * No telemetry, and no access to the instance metadata service. RabbitMQ has no telemetry and no metrics plugin is enabled. The broker (with the epmd it starts), nginx and the boot service run with the EC2 instance metadata address blocked (Step 11). * A pinned supply chain. RabbitMQ 4.4.0 and Erlang/OTP 27.3.4.19 come from Team RabbitMQ's signed apt repositories. The release signing key is pinned by fingerprint, and every package is pinned to its exact version and held. Ubuntu 24.04 LTS is fully patched at build time.

What is on the image:

• RabbitMQ 4.4.0 (the rabbitmq-server package; configuration in /etc/rabbitmq/, data in /var/lib/rabbitmq/mnesia).
• Erlang/OTP 27.3.4.19.
• nginx, the HTTPS front door of the console.
• The cloudimg helpers: rabbitmq-probe (an AMQP test client), rabbitmq-selfcheck, rabbitmq-config-gate, rabbitmq-guard, rabbitmq-set-hostname and rabbitmq-install-cert.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites

• An AWS account subscribed to the listing, an EC2 key pair, and a VPC subnet with a route to the internet (or a private route you use for management).
• A security group that allows:

Port	Protocol	Source	Purpose
22	TCP	your admin network	SSH
443	TCP	your admin network	the management console and HTTP API (HTTPS)
5671	TCP	the networks your applications connect from	AMQP over TLS (AMQPS)

Nothing else needs to be open. The broker does not serve 5672, 15672, 4369, 25672, 1883, 61613, 5552, 15692 or 80, so opening them achieves nothing.

Step 1: Launch the instance

1. In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration.
2. Pick RabbitMQ 4.4.0 Message Broker on Ubuntu 24.04 as the software version, and pick your Region.
3. Choose Launch through EC2.
4. Choose m5.large (or larger for many connections or high message rates), your key pair and a security group as above.

With the AWS CLI (replace the values in angle brackets):

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=rabbitmq-broker}]'

The image requires IMDSv2 (session tokens). First boot takes about a minute after the instance is running:

1. The boot service reads the instance's EC2 names.
2. It creates the Erlang cookie, the logins and the certificate.
3. The broker starts and loads the logins.
4. The guard checks the broker.

Step 2: Connect to your instance

Version	SSH user
RabbitMQ 4.4.0 Message Broker on Ubuntu 24.04	ubuntu

ssh -i <your-key.pem> ubuntu@<public-ip>

The login banner shows where the logins and the certificate are.

Step 3: Check the services and the listening set

systemctl is-active rabbitmq-metadata-names rabbitmq-firstboot rabbitmq-server nginx
sudo ss -tlnp | grep -E ':(22|443|1883|4369|5552|5671|5672|15672|15692|25672|61613) '
sudo ss -ulnp | grep -E 'beam|epmd|nginx' || echo 'no UDP socket'

active
active
active
active
LISTEN 0      4096       127.0.0.1:4369       0.0.0.0:*    users:(("epmd",pid=1125,fd=3))
LISTEN 0      1024       127.0.0.1:15672      0.0.0.0:*    users:(("beam.smp",pid=1054,fd=30))
LISTEN 0      128        127.0.0.1:25672      0.0.0.0:*    users:(("beam.smp",pid=1054,fd=19))
LISTEN 0      511          0.0.0.0:443        0.0.0.0:*    users:(("nginx",pid=1059,fd=5),("nginx",pid=1058,fd=5),("nginx",pid=1057,fd=5))
LISTEN 0      4096         0.0.0.0:22         0.0.0.0:*    users:(("sshd",pid=1255,fd=3),("systemd",pid=1,fd=59))
LISTEN 0      128                *:5671             *:*    users:(("beam.smp",pid=1054,fd=38))
LISTEN 0      4096           [::1]:4369          [::]:*    users:(("epmd",pid=1125,fd=4))
LISTEN 0      4096            [::]:22            [::]:*    users:(("sshd",pid=1255,fd=4),("systemd",pid=1,fd=60))
no UDP socket

The four units:

• rabbitmq-metadata-names reads this instance's EC2 names for the certificate.
• rabbitmq-firstboot prepares the cookie, the logins and the certificate.
• rabbitmq-server is the broker, the Erlang VM beam.smp.
• nginx serves the console on 443.

The broker listens on 5671 (AMQPS) on every address. Everything else it opens is on 127.0.0.1 only: the console backend (15672, for nginx), Erlang distribution (25672) and epmd (4369).

Step 4: Your endpoint and logins

Everything generated for your instance is in /root/rabbitmq-credentials.txt, which only root can read. View it all with sudo cat /root/rabbitmq-credentials.txt. These lines are not secret:

sudo grep -E '^RABBITMQ_(HOST|AMQPS_ENDPOINT|AMQPS_PORT|MGMT_URL|PRIVATE_IP|ADMIN_USER|APP_USER|APP_VHOST|APP_PREFIX|TLS_CERT_FILE|TLS_CERT_SHA256|TLS_PUBKEY_SHA256)=' /root/rabbitmq-credentials.txt

RABBITMQ_HOST=54.210.149.54
RABBITMQ_AMQPS_ENDPOINT=amqps://54.210.149.54:5671
RABBITMQ_AMQPS_PORT=5671
RABBITMQ_MGMT_URL=https://54.210.149.54/
RABBITMQ_PRIVATE_IP=172.31.91.20
RABBITMQ_ADMIN_USER=cloudimg-admin
RABBITMQ_APP_USER=cloudimg-app
RABBITMQ_APP_VHOST=cloudimg-app
RABBITMQ_APP_PREFIX=app.
RABBITMQ_TLS_CERT_FILE=/etc/rabbitmq/tls/rabbitmq.crt
RABBITMQ_TLS_CERT_SHA256=77:87:22:5D:8F:BC:8E:66:E2:5C:93:3F:B0:6A:CE:63:B6:51:78:41:89:24:00:C6:1B:15:AF:45:46:20:F6:3B
RABBITMQ_TLS_PUBKEY_SHA256=3c0bdcdd3671b8cdc2bd37b37b7e835a625ff090880affc8c6883ab9185feef8

The file also holds RABBITMQ_ADMIN_PASSWORD and RABBITMQ_APP_PASSWORD. It does not hold the Erlang cookie (Step 10).

Give applications the cloudimg-app login or a scoped user of their own (Step 8), never the administrator's. Keep passwords in files with mode 0600, not in shell history or on command lines. Every user on a machine can see a command line through ps.

Step 5: Check the certificate and pin it in your client

The broker's certificate is self-signed, made on your instance:

sudo openssl x509 -in /etc/rabbitmq/tls/rabbitmq.crt -noout -subject -enddate -ext subjectAltName,basicConstraints
sudo openssl x509 -in /etc/rabbitmq/tls/rabbitmq.crt -noout -fingerprint -sha256

subject=CN = rabbitmq-broker, O = cloudimg
notAfter=Feb 10 06:04:15 2029 GMT
X509v3 Subject Alternative Name:
    IP Address:54.210.149.54, DNS:ec2-54-210-149-54.compute-1.amazonaws.com, IP Address:172.31.91.20, DNS:ip-172-31-91-20.ec2.internal, IP Address:127.0.0.1, DNS:localhost
X509v3 Basic Constraints: critical
    CA:FALSE
sha256 Fingerprint=77:87:22:5D:8F:BC:8E:66:E2:5C:93:3F:B0:6A:CE:63:B6:51:78:41:89:24:00:C6:1B:15:AF:45:46:20:F6:3B

CA:FALSE means it is an end-entity certificate that cannot sign anything else. The SHA-256 fingerprint is the RABBITMQ_TLS_CERT_SHA256 value in your credentials file, and the same certificate is served on 5671 and on 443.

The certificate is public; the private key never leaves the instance. Copy the certificate to each client machine:

client-host$ ssh -i <your-key.pem> ubuntu@<public-ip> 'sudo cat /etc/rabbitmq/tls/rabbitmq.crt' > rabbitmq.crt
client-host$ openssl x509 -in rabbitmq.crt -noout -fingerprint -sha256

Compare the fingerprint with RABBITMQ_TLS_CERT_SHA256 before you trust the file. Then set your client's CA file or trust store to only this file, with host name checking on. Your client will then refuse any other server, including a server in the middle that presents a different certificate.

The certificate covers the instance's public and private IPv4 addresses, its EC2 DNS names, localhost and 127.0.0.1. An EC2 stop and start gives the instance a new public IP. At the next boot, the certificate is re-issued for the new names with the same key:

• Clients that pin the public key (RABBITMQ_TLS_PUBKEY_SHA256) keep working.
• Clients that pin the certificate file need the new copy.

Step 6: Test on the instance

rabbitmq-probe is a small AMQP client. It reads passwords from a file (or from the credentials file with --identity) and trusts only the broker's certificate:

sudo rabbitmq-probe connect --identity app
sudo rabbitmq-probe roundtrip --identity app --queue app.guide-test
sudo rabbitmq-probe declare --identity app --queue orders || true
sudo rabbitmq-probe connect --identity app --vhost / || true

OPEN ok vhost=cloudimg-app tls=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384
ROUNDTRIP OK queue=app.guide-test bytes=56 tls=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384
CHANNEL-CLOSE 403 ACCESS_REFUSED - configure access to queue 'orders' in vhost 'cloudimg-app' refused for user 'cloudimg-app'
REFUSED 530 NOT_ALLOWED - access to vhost '/' refused for user 'cloudimg-app'

These four commands show that:

• the application user logs in;
• it declares a queue named app.guide-test, publishes a message and reads it back;
• it is refused a queue outside app.*;
• it is refused the / virtual host.

rabbitmq-probe exits non-zero on a refusal, hence the || true.

Step 7: Connect a client from another machine

On the client machine, put the application password in a file that only you can read. Copy the certificate as in Step 5:

client-host$ umask 077
client-host$ ssh -i <your-key.pem> ubuntu@<public-ip> "sudo sed -n 's/^RABBITMQ_APP_PASSWORD=//p' /root/rabbitmq-credentials.txt" > app.password

This example uses Python and pika (sudo apt-get install python3-pika on Ubuntu, or pip install pika):

# pika_demo.py - publish and consume through your cloudimg RabbitMQ broker over AMQPS (pika 1.x).
# Usage: python3 pika_demo.py <broker-host> <rabbitmq.crt> <user> <password-file> <vhost> <queue>
# The password is read from a file, never the command line; TLS trusts ONLY the broker's own certificate.
import ssl
import sys

import pika

host, cafile, user, pwfile, vhost, queue = sys.argv[1:7]
with open(pwfile) as f:
    password = f.read().strip()

ctx = ssl.create_default_context(cafile=cafile)      # verify against this one certificate, nothing else
ctx.minimum_version = ssl.TLSVersion.TLSv1_2
params = pika.ConnectionParameters(
    host=host, port=5671, virtual_host=vhost,
    credentials=pika.PlainCredentials(user, password),
    ssl_options=pika.SSLOptions(ctx, server_hostname=host),
)
conn = pika.BlockingConnection(params)
ch = conn.channel()
ch.queue_declare(queue=queue, durable=True)
ch.basic_publish(exchange="", routing_key=queue, body=b"hello from pika",
                 properties=pika.BasicProperties(delivery_mode=2))
method, props, body = ch.basic_get(queue=queue, auto_ack=True)
print("received:", body.decode())
conn.close()

client-host$ python3 pika_demo.py <public-ip> rabbitmq.crt cloudimg-app app.password cloudimg-app app.pika-demo
received: hello from pika

For <broker-host>, use a name the certificate covers: the public or private IP, an EC2 DNS name, or your own DNS name once you have added it (Step 12).

The AMQP URL form is amqps://cloudimg-app:<password>@<public-ip>:5671/cloudimg-app, and most libraries accept it. Build it inside your program from the password file. Do not write it in a configuration file or on a command line.

Step 8: Management over HTTPS, and scoped users and virtual hosts

Open https://<public-ip>/ in a browser and sign in as cloudimg-admin with RABBITMQ_ADMIN_PASSWORD. The certificate is self-signed, so the browser warns until you trust rabbitmq.crt or install a CA certificate (Step 12).

The HTTP API is served at the same address. On the instance:

1. Keep the administrator login in a curl configuration file that only you can read.
2. Copy the certificate where your user can read it.
3. Check the API. A request with no login gets 401.

umask 077
sudo cat /etc/rabbitmq/tls/rabbitmq.crt > ~/rabbitmq.crt
printf 'user = "cloudimg-admin:%s"\n' "$(sudo sed -n 's/^RABBITMQ_ADMIN_PASSWORD=//p' /root/rabbitmq-credentials.txt)" > ~/.rabbitmq-admin.curl
api() { curl -sS --cacert ~/rabbitmq.crt -K ~/.rabbitmq-admin.curl "$@"; }
api -o /dev/null -w '%{http_code}\n' https://localhost/api/overview
curl -sS --cacert ~/rabbitmq.crt -o /dev/null -w '%{http_code}\n' https://localhost/api/overview

200
401

Give each application its own user, limited to its own virtual host and name prefix, rather than sharing one login. The safe way on the instance is rabbitmqctl with the password on standard input. Run rabbitmqctl add_user with only the user name, and redirect the password file into it. It then reads the password from the file. The password never appears in ps, your shell history or the broker log. Never pass the password as a second argument.

The example below sets up:

• a virtual host orders;
• a user orders-svc with a random password kept in a 0600 file;
• permissions limited to names that start with orders..

umask 077
sudo rabbitmqctl add_vhost orders
openssl rand -base64 30 | tr -d '/+=\n' | head -c 32 > ~/orders-svc.password
sudo rabbitmqctl add_user orders-svc < ~/orders-svc.password
sudo rabbitmqctl set_permissions -p orders orders-svc '^orders\.' '^(orders\..*|amq\.default)?$' '^orders\.'

Adding vhost "orders" ...
Adding user "orders-svc" ...
Password:
Done. Don't forget to grant the user permissions to some virtual hosts! See 'rabbitmqctl help set_permissions' to learn more.
Setting permissions for user "orders-svc" in vhost "orders" ...

The write pattern also allows amq.default, the default exchange, so the application can publish straight to its own queues by name. Try the new user:

sudo rabbitmq-probe roundtrip --user orders-svc --password-file ~/orders-svc.password --vhost orders --queue orders.created
sudo rabbitmq-probe declare --user orders-svc --password-file ~/orders-svc.password --vhost orders --queue app.x || true
sudo rabbitmq-probe connect --user orders-svc --password-file ~/orders-svc.password --vhost cloudimg-app || true

ROUNDTRIP OK queue=orders.created bytes=56 tls=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384
CHANNEL-CLOSE 403 ACCESS_REFUSED - configure access to queue 'app.x' in vhost 'orders' refused for user 'orders-svc'
REFUSED 530 NOT_ALLOWED - access to vhost 'cloudimg-app' refused for user 'orders-svc'

To rotate the password, use the same standard-input form:

umask 077
openssl rand -base64 30 | tr -d '/+=\n' | head -c 32 > ~/orders-svc.password.new
sudo rabbitmqctl change_password orders-svc < ~/orders-svc.password.new && mv ~/orders-svc.password.new ~/orders-svc.password

Hand ~/orders-svc.password to the application's secret store, then delete it with shred -u ~/orders-svc.password. To remove the example again:

sudo rabbitmqctl delete_user orders-svc
sudo rabbitmqctl delete_vhost orders
shred -u ~/orders-svc.password 2>/dev/null || true

From another machine, manage the broker over HTTPS on 443 with the console or the HTTP API (https://<public-ip>/api/... with --cacert rabbitmq.crt). When you create a user through the API, send the password in a JSON request body read from a 0600 file (--data @file), never in the URL or on the command line.

The broker enforces these rules whatever you change:

• No user may be called guest.
• No user may have the password guest, an empty password, a common default or its own name.
• cloudimg-admin can use AMQP only from the instance itself (loopback_users).

Step 9: The broker refuses to run unsafely

rabbitmq-server.service runs rabbitmq-config-gate before every start and rabbitmq-guard after it. Check both, and the whole instance, at any time:

sudo rabbitmq-config-gate --unit && echo gate-ok
sudo rabbitmq-selfcheck | tail -n 1

rabbitmq-config-gate: OK (unit)
gate-ok
SELFCHECK OK

The gate. It runs before every start. It refuses changes like these:

• in /etc/rabbitmq/rabbitmq.conf or a conf.d/*.conf file: a plain-text listener (listeners.tcp.*, or a plugin's plain port off loopback), a console bound to the network, a non-loopback guest, the ANONYMOUS mechanism, a TLS version below 1.2, or an external authentication backend;
• an advanced.config file;
• in enabled_plugins: a plugin whose plain-text listener would be public. MQTT, STOMP and Stream need their plain listener set to none or to a 127.0.0.1 address (use their TLS listener for the network). Web-MQTT, Web-STOMP and Prometheus need their HTTP listener on 127.0.0.1. The gate also refuses the LDAP, HTTP and OAuth 2 authentication backends, peer discovery (clustering) and message tracing;
• changes to rabbitmq-env.conf (the loopback-only Erlang distribution).

If the gate refuses a change, the broker does not start, and journalctl -u rabbitmq-server shows the reason.

The guard. It runs after every start. It stops the broker if the broker has:

• a user called guest, a user with a weak password, or a user with no password;
• a management API that answers without a login;
• any listener other than the expected set.

rabbitmq-selfcheck prints one ok: line per area and ends with SELFCHECK OK. The areas are: the units, the gate and the guard, the Erlang cookie, the listening set, the certificate, round trips, refusals, the console and the metadata block.

Step 10: Why 5672, 15672, epmd and 25672 are closed, and the Erlang cookie

By default, RabbitMQ serves:

• plain AMQP on 5672 and the HTTP console on 15672, both without TLS;
• epmd on 4369 and Erlang distribution on 25672, on every address.

Its first start also creates guest / guest. On a cloud instance, that means passwords and messages in clear text, a well-known login, and a node that anyone holding the cookie can control over the network. This image closes each of these in RabbitMQ's own configuration, not with a firewall:

• 5672 (AMQP) is off. Use AMQPS on 5671; every maintained AMQP client supports TLS.
• 15672 (HTTP console and API) is bound to 127.0.0.1 for nginx only. Use https://<host>/ on 443.
• 4369 (epmd) and 25672 (Erlang distribution) are bound to 127.0.0.1, set in /etc/rabbitmq/rabbitmq-env.conf. The node is rabbit@localhost. Only processes on this instance can reach it, which is what rabbitmqctl needs. This image is a single node. Clustering would need distribution on the network, and the gate refuses that.
• MQTT (1883), STOMP (61613), Stream (5552) and Prometheus (15692) are not enabled.

epmd -names
sudo stat -c '%n %a %U:%G %s bytes' /var/lib/rabbitmq/.erlang.cookie /var/lib/rabbitmq

epmd: up and running on port 4369 with data:
name rabbit at port 25672
/var/lib/rabbitmq/.erlang.cookie 400 rabbitmq:rabbitmq 64 bytes
/var/lib/rabbitmq 750 root:rabbitmq 4096 bytes

The Erlang cookie is the shared secret that lets an Erlang process join the node or control it with rabbitmqctl. Anyone who has it, and can reach the distribution port, has full control of the broker. On this image:

• The cookie is 256 random bits, generated on your instance at first boot. No two instances share one, and the image ships none.
• It is readable only by the rabbitmq user (0400), in a home directory that root owns.
• It is not in the credentials file, and you never need to copy it: sudo rabbitmqctl on the instance reads it for you.
• The distribution port is on loopback, so the cookie is useless from another machine.

If you delete the cookie, the next boot mints a new one.

Step 11: The instance metadata block

The EC2 instance metadata service (169.254.169.254) hands out the instance's IAM role credentials to any process that asks. A broker or web server that could be tricked into fetching a URL must not reach it.

These units run with the metadata addresses blocked by systemd (IPAddressDeny):

• rabbitmq-server, and the epmd daemon it starts in its own control group;
• nginx;
• rabbitmq-firstboot.

Only rabbitmq-metadata-names, which reads the instance's names for the certificate, may reach the metadata service, and it may reach nothing else:

for u in rabbitmq-server nginx rabbitmq-firstboot rabbitmq-metadata-names; do printf '%-24s deny=%s allow=%s\n' "$u" "$(systemctl show -p IPAddressDeny --value "$u")" "$(systemctl show -p IPAddressAllow --value "$u")"; done

rabbitmq-server          deny=169.254.169.254/32 168.63.129.16/32 fd00:ec2::254/128 ::ffff:169.254.169.254/128 ::ffff:168.63.129.16/128 allow=
nginx                    deny=::ffff:168.63.129.16/128 169.254.169.254/32 fd00:ec2::254/128 168.63.129.16/32 ::ffff:169.254.169.254/128 allow=
rabbitmq-firstboot       deny=fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32 ::ffff:168.63.129.16/128 ::ffff:169.254.169.254/128 allow=
rabbitmq-metadata-names  deny=0.0.0.0/0 ::/0 allow=169.254.169.254/32 fd00:ec2::254/128

rabbitmq-selfcheck proves the block from inside the broker's own control group: a request to the metadata service gets no answer, while a request to the instance's own console succeeds. RabbitMQ has no telemetry. The image enables no plugin that dials out (no Federation, Shovel or Prometheus), so the broker opens no outbound connection.

Step 12: Use your own DNS name or a certificate from your CA

Point a DNS name at the instance (an Elastic IP keeps the address across stop and start), then add the name to the certificate:

sudo rabbitmq-set-hostname <dns-name>

This command:

• re-issues the self-signed certificate, with the same key, to cover the name;
• pins nginx to the name;
• updates the endpoint in /root/rabbitmq-credentials.txt;
• restarts the broker.

Copy the new rabbitmq.crt to clients that pin the certificate file.

To use a certificate from your CA (your own, or a public one such as Let's Encrypt), copy the chain (server certificate first) and its unencrypted PEM key to the instance, then run:

sudo rabbitmq-install-cert <certificate-chain.pem> <private-key.pem> <dns-name>

Both endpoints (5671 and 443) then serve your certificate, and clients trust your CA instead of pinning this instance. The boot-time renewal never replaces an installed certificate. To go back to a new self-signed certificate, run sudo rabbitmq-set-hostname <name>.

Logs, files and limits

• Logs:
• the broker: journalctl -u rabbitmq-server and /var/log/rabbitmq/;
• the console front door: journalctl -u nginx and /var/log/nginx/;
• first boot: journalctl -u rabbitmq-firstboot.
• Files:
• configuration: /etc/rabbitmq/rabbitmq.conf, /etc/rabbitmq/conf.d/, /etc/rabbitmq/enabled_plugins and /etc/rabbitmq/rabbitmq-env.conf, all checked by the gate on every start;
• data: /var/lib/rabbitmq/mnesia;
• the certificate and key: /etc/rabbitmq/tls/.
• Day-to-day commands: sudo rabbitmqctl list_users, sudo rabbitmqctl list_vhosts, sudo rabbitmqctl list_queues -p cloudimg-app name messages and sudo rabbitmq-diagnostics status.
• Sandbox: the broker runs as the unprivileged rabbitmq user in a systemd sandbox: no capabilities, a read-only system, a system-call filter, and core dumps off. It can write only its data and log directories.
• Package updates: the RabbitMQ and Erlang packages are held at the tested versions (apt-mark showhold). Ubuntu security updates keep applying. Upgrade RabbitMQ deliberately, by following RabbitMQ's upgrade guide, not with a routine apt upgrade.
• Storage and backups: messages are kept on the instance's EBS volume. Size the volume and the instance for your message volume, and take EBS snapshots for backups.

Support

cloudimg provides support for the image: launch problems, the first-boot setup, the TLS configuration and the cloudimg helpers. Contact support@cloudimg.co.uk. RabbitMQ itself is documented at rabbitmq.com/docs.