Skip to main content
Qovery creates it in the AWS account of the environment’s cluster, as a Blueprint service in one of your environments.
New to this? You don’t need to know Kubernetes or Terraform. Qovery sets up Amazon MQ for RabbitMQ in your cloud account and manages it for you: you fill in a form, or paste the prompt below into your coding agent. The values it publishes, listed under Outputs, reach your other services as environment variables. Qovery tells you when a newer version of the Blueprint is available. Check the requirements in the Reference section before you start, and try it first in a development environment.

Create it

  1. Open the environment, then New service › Blueprint.
  2. Find Amazon MQ for RabbitMQ in the catalog and pick the major version.
  3. Fill in the variables. Required ones are marked; the others use their defaults.
  4. Create the service, and deploy it now or later.
You don’t add any file to your repository. Qovery creates the Blueprint from the Console or the API.

Variables and outputs

Generated from qbm.yml at AWS/rabbitmq/4/2.0.1, the manifest the Console form is built from.
Outputs become environment variables that other services in the environment can use. By default Qovery also creates an alias for each output, prefixed with the Blueprint’s name; see Aliases Qovery creates for outputs for the naming rules and the cases where no alias is created.
Secret variables and outputs are encrypted and masked in Qovery, but Terraform can also keep their values, and values derived from them, in its state. With the Qovery-managed state backend (the default), Qovery stores the state. If you use your own backend, protect it and keep state files out of version control.

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 holding consumer_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 to allowed_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. With credentials: 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.