Apache Qpid Broker-J AMQP Message Broker on AWS User Guide

Overview

Apache Qpid Broker-J is a pure Java message broker from the Apache Qpid project. It is unusual in speaking the full range of AMQP versions, 1.0 alongside 0-8, 0-9, 0-9-1 and 0-10, on a single server, which makes it a practical bridge between older AMQP clients and modern AMQP 1.0 applications.

The stock Qpid Broker-J configuration ships a well known guest/guest account that is accepted on both the message listeners and the management console. This image does not. It ships with no rendered broker configuration at all, so the broker physically cannot start until first boot generates a unique administrator password for your instance.

What is included:

• Apache Qpid Broker-J 10.0.1 from the official Apache release distribution (Apache License 2.0), sha512 verified at build time
• OpenJDK 17 headless runtime; the broker runs as the unprivileged qpid system user under systemd
• AMQP on 0.0.0.0:5672 and AMQPS on 0.0.0.0:5671, both requiring authentication
• The management console bound to 127.0.0.1:8080, published only through nginx on :443 with a per instance self signed certificate, and :80 redirecting to HTTPS
• An unauthenticated /health endpoint for load balancer probes
• qpid-broker-j-firstboot.service generating a 28 character administrator password, a per instance TLS certificate and a per instance AMQPS keystore, writing /root/qpid-broker-j-credentials.txt (mode 0600 root:root)
• python3-pika for the bundled AMQP round trip helper
• 24/7 cloudimg support

Prerequisites

An AWS account, an EC2 key pair, and a VPC subnet. The security group should allow inbound TCP 22 (SSH), 443 (management console), and 5672 and 5671 (messaging) from your trusted CIDR. m5.large is a comfortable default: the broker is a JVM service sized for roughly a gigabyte of heap plus a gigabyte of direct memory.

Connecting to your instance

SSH in as the default login user for the operating system variant you launched. This listing currently ships one variant:

ssh ubuntu@<public-ip>

Step 1: Launch from AWS Marketplace

Subscribe to the cloudimg Apache Qpid Broker-J listing and launch an instance. Pick m5.large, choose your VPC and subnet, and attach a security group allowing inbound TCP 22, 443, 5672 and 5671 from your trusted CIDR.

Step 2: SSH In

ssh ubuntu@<public-ip>

Step 3: Service Status

Confirm the broker and the TLS reverse proxy are both active.

sudo systemctl is-active qpid nginx

active
active

Step 4: Confirm the Health Endpoint

nginx serves an unauthenticated health endpoint. Point an Application Load Balancer target group or an external uptime check at this, so probes never need credentials.

curl -sk -o /dev/null -w 'health HTTP %{http_code}\n' -m 10 https://127.0.0.1/health

health HTTP 200

Step 5: Confirm Secure By Default Authentication

The management API must reject an unauthenticated request.

curl -sk -o /dev/null -w 'unauthenticated management API HTTP %{http_code}\n' -m 10 https://127.0.0.1/api/latest/broker

unauthenticated management API HTTP 401

Now confirm the listener topology. The two messaging ports are network facing, the management port is loopback only, and nginx alone is publicly bound.

sudo ss -tlnp | grep -E ':5672|:5671|:8080|:443 ' | awk '{print $1, $4}'

LISTEN 0.0.0.0:443
LISTEN [::ffff:127.0.0.1]:8080
LISTEN *:5671
LISTEN *:5672
LISTEN [::]:443

127.0.0.1:8080 is the important line: the management console cannot be reached from the network except through the TLS proxy.

Step 6: Read Per-Instance Credentials

First boot generated this instance's administrator password. Read it now.

sudo cat /root/qpid-broker-j-credentials.txt

Pick up QPID_ADMIN_USER (admin) and QPID_ADMIN_PASSWORD. These are unique to this instance and exist nowhere in the image.

Step 7: Sign In to the Management Console

Browse to https://<public-ip>/. The image ships a self signed certificate regenerated for your instance, so your browser warns on first visit; accept it, or replace the certificate as described in Step 12.

The console presents its own sign in form, which is proof the broker is not open.

Sign in as admin with the generated password. The broker view opens, listing the virtual hosts, the configured ports and their authentication providers, the broker loggers and the authentication providers.

Note the Ports table: AMQP and AMQPS are bound to *, while HTTP is bound to 127.0.0.1. That is the loopback restriction, visible in the product's own UI.

Step 8: Explore the Virtual Host

Expand virtualhostnodes in the tree and open default. The virtual host view shows live message and queue depth statistics and the four standard AMQP exchanges, ready for you to bind queues to.

Step 9: Confirm the Broker Version and Ports over the API

Everything the console does is available through the REST API using the same credentials.

P=$(sudo grep -m1 '^QPID_ADMIN_PASSWORD=' /root/qpid-broker-j-credentials.txt | cut -d= -f2-)
curl -sk -u "admin:$P" -m 15 https://127.0.0.1/api/latest/broker | python3 -c "import sys,json;d=json.load(sys.stdin);b=d[0] if isinstance(d,list) else d;print('broker product:',b.get('productVersion'));print('model version:',b.get('modelVersion'))"

broker product: 10.0.1
model version: 9.1

P=$(sudo grep -m1 '^QPID_ADMIN_PASSWORD=' /root/qpid-broker-j-credentials.txt | cut -d= -f2-)
curl -sk -u "admin:$P" -m 15 https://127.0.0.1/api/latest/port | python3 -c "import sys,json;[print(f\"  {p['name']:<6} port={p['port']:<5} transports={','.join(p.get('transports',[]))}\") for p in json.load(sys.stdin)]"

  AMQPS  port=5671  transports=SSL
  HTTP   port=8080  transports=TCP
  AMQP   port=5672  transports=TCP

Step 10: List the Exchanges

P=$(sudo grep -m1 '^QPID_ADMIN_PASSWORD=' /root/qpid-broker-j-credentials.txt | cut -d= -f2-)
curl -sk -u "admin:$P" -m 15 https://127.0.0.1/api/latest/exchange/default | python3 -c "import sys,json;print('exchanges:',[e['name'] for e in json.load(sys.stdin)])"

exchanges: ['amq.match', 'amq.fanout', 'amq.topic', 'amq.direct']

These are the standard AMQP exchange types: headers, fanout, topic and direct. Bind your queues to whichever routing model suits your application.

Step 11: Prove an End-to-End AMQP Round Trip

The image ships a helper that declares a durable queue, publishes a message, consumes it back, and asserts a wrong credential connect is rejected. Run it any time to confirm messaging health.

P=$(sudo grep -m1 '^QPID_ADMIN_PASSWORD=' /root/qpid-broker-j-credentials.txt | cut -d= -f2-)
sudo /opt/qpid/bin/qpid-amqp-roundtrip.py admin "$P" 2>&1 | tail -2

AMQP_RT_OK cloudimg-rt-9d8a9de2fe6245f0ac64b4be0fa66ebe

From your own applications, connect to <public-ip>:5672 for plaintext AMQP or <public-ip>:5671 for AMQPS, authenticating with the same admin user and generated password. Anonymous and wrong credential connections are rejected.

Step 12: Production Hardening Checklist

Before exposing the broker beyond a trusted network:

1. Replace the self signed certificate. The per instance certificate is fine for a first connection but not for production clients. Install your own certificate for nginx on :443, and a trusted keystore for the AMQPS listener on :5671.
2. Prefer AMQPS. Port 5672 is plaintext: credentials are protected by SASL but message bodies are not encrypted. For anything crossing an untrusted network, use 5671 and close 5672 in the security group.
3. Restrict the security group. Limit 22, 443, 5672 and 5671 to your application and administrator CIDRs rather than the world.
4. Add per application users. Rather than sharing the admin account, add users under authenticationproviders in the console and grant them only the queues they need via access control.
5. Back up the broker configuration and store. /var/lib/qpid holds the broker configuration, users and durable message state; snapshot the volume or copy the directory on a schedule.
6. Keep it patched. Unattended upgrades is enabled for OS packages; review the Apache Qpid release notes before replacing the broker under /opt/qpid.

Architecture

Support

cloudimg provides 24/7 support for this image. Open a ticket at https://www.cloudimg.co.uk/support/ with your instance ID and a brief description of the issue. Common asks: replacing the self signed certificate, queue and exchange design, connecting clients across AMQP versions, access control, and sizing for throughput.