Create it
- Console
- CLI and API
- Coding agent
- Open the environment, then New service › Blueprint.
- Find Amazon MQ for RabbitMQ in the catalog and pick the major version.
- Fill in the variables. Required ones are marked; the others use their defaults.
- Create the service, and deploy it now or later.
Variables and outputs
Generated fromqbm.yml at AWS/rabbitmq/4/2.0.1, the manifest the Console form is built from.
All 19 variables
All 19 variables
All 10 outputs
All 10 outputs
Reference
From the Blueprint’s README. Creates an Amazon MQ for RabbitMQ 4 broker, reachable over AMQPS (port 5671, TLS only), on a single node or as a three-node cluster spread across availability zones. By default the broker joins the Qovery cluster network, in the private subnets of the cluster’s DB subnet group, with its own security group opening 5671, 443 and the Prometheus ports 16001-16003 to the VPC, so pods reach it with no extra setup. The broker carries an Amazon MQ configuration holdingconsumer_timeout, heartbeat and any
extra_configuration lines. Storage is EBS, encrypted at rest.
Before the first deploy, give the deploying identity the Amazon MQ permissions listed in
Required AWS IAM permissions. The Qovery IAM policy does not
include mq:*, so with the default cluster credentials the deploy fails on the first Amazon MQ
call with AccessDeniedException: ... is not authorized to perform: mq:CreateConfiguration.
No broker or configuration is created when that happens. With general_logs = true, the
CloudWatch Logs resource policy is created in parallel and can remain: delete the service to
remove it.
Variables
Required
Engine
Credentials
Both are set at creation only. Amazon MQ cannot update RabbitMQ users and never returns them,
so the blueprint ignores later edits to the
user block, and the rabbitmq_username,
rabbitmq_password and rabbitmq_amqp_url outputs keep the values the broker was created with. Editing either variable afterwards
has no effect. Change the password in the RabbitMQ management UI instead, then update your
applications. A replaced broker (for example after a deployment_mode change) is created with the
current values, and the outputs follow.
Network
A single-instance broker takes the first subnet (one per availability zone, sorted by zone name);
a cluster takes up to three. On a cluster deployed into an existing VPC, the
ClusterId lookup may
find nothing: set subnet_ids explicitly. The security group is then created in the VPC of those
subnets.
The blueprint does not reuse the cluster workers security group, as the RDS blueprints do. That
group only opens the ports of the native databases (5432, 3306, 6379), and nodes started by
Karpenter carry the EKS cluster security group instead, so pods could not reach the broker.
Amazon MQ does not let a RabbitMQ broker change security groups, so the groups are set at creation.
Setting or clearing security_group_ids afterwards changes nothing on the broker: to switch between
the blueprint’s group and your own, delete the service and create a new one. The blueprint’s group
exists for every private broker, attached or not, so such an edit never deletes a group the broker
still uses.
allowed_cidrs can change at any time. It edits the ingress rules of the blueprint’s group, which
is the group attached to the broker by default, without touching the broker’s security_groups.
The default opens 5671, 443 and 16001-16003 to the whole VPC, not only the broker’s subnets: pods get their IPs
from the node subnets, which are not the DB subnets the broker sits in. On a VPC shared with other
workloads, set allowed_cidrs to the cluster’s node subnets, or use security_group_ids. Port 443
is the RabbitMQ management API, which can manage users, vhosts and policies.
A public broker is hosted by Amazon MQ outside the VPC and cannot have a security group: anyone who
has the credentials can connect. Keep it private unless a client outside AWS needs it.
Maintenance
Instance type, engine version and configuration changes all need a reboot. With
apply_changes_now = false the deploy succeeds but the broker keeps the old settings until the
next maintenance window, and Terraform may keep showing the change as pending until then.
RabbitMQ settings
For example,
management.restrictions.operator_policy_changes.disabled = false lets you edit
operator policies. See
Configurable values
for the keys Amazon MQ accepts.
Logs & encryption
Amazon MQ can only publish logs once a CloudWatch Logs resource policy lets it. With
general_logs = true the blueprint creates one, named qovery-amazonmq-<broker_name>. AWS allows
10 such policies per region.
Outputs
Qovery publishes each output as an environment variable alias with the same name in upper case
(
RABBITMQ_HOST, RABBITMQ_PASSWORD…). Blueprint versions before 2.0.0 had unprefixed outputs
(HOST, PORT, USERNAME, PASSWORD…); services that read those aliases must switch to the
RABBITMQ_ names when the blueprint is upgraded.
Prometheus metrics
RabbitMQ 4.2 and later expose Prometheus metrics on ports 16001, 16002 and 16003, one per node, which the blueprint’s security group opens toallowed_cidrs. Scrape them over HTTPS with basic
auth (the broker credentials), on the broker host, every 60 seconds or more:
/metrics/detailed and /metrics/memory-breakdown are also available; /metrics/per-object is
not. See
Accessing Prometheus metrics.
Required AWS IAM permissions
The identity that deploys the blueprint needs the actions below. Withcredentials: cluster (the
default) that is the cluster’s IAM role, qovery-user-role on a standard installation: attach them
to it as an extra policy. With credentials: env, the keys you supply need them. The EC2 and RDS
read actions let Terraform find the cluster subnets, and the security group actions create the
broker’s own group; the logs actions are only used with general_logs = true.