Terraform Amazon MQ: Building Production-Ready ActiveMQ and RabbitMQ Brokers on AWS

Amazon MQ is a managed message broker service for Apache ActiveMQ and RabbitMQ. If applications rely on standard messaging protocols like AMQP, MQTT, OpenWire, or STOMP, Amazon MQ handles the heavy lifting of broker provisioning, patching, and high availability. Managing brokers through Terraform means you can spin up consistent messaging infrastructure across development, staging, and production environments without manual setup.

This guide covers creating both ActiveMQ and RabbitMQ brokers, configuring high availability, managing users, and setting up proper networking. It combines hands-on Terraform examples with module patterns and production considerations for multi-environment deployments.

Prerequisites and Provider Setup

Before creating brokers, the reference implementations assume a baseline toolchain and network.

• Terraform 1.0 or later
• AWS CLI with appropriate permissions
• A VPC with subnets for production deployments
• Understanding of message broker concepts

Provider setup for a standard project is shown in multiple examples. One configuration pins the AWS provider to ~6.0 and adds the random provider:

```hcl
terraform {
requiredversion = ">= 1.0"
requiredproviders {
aws = {
source = "hashicorp/aws"
version = "~> 6.0"
}
random = {
source = "hashicorp/random"
version = "~> 3.0"
}
}
}

provider "aws" {
region = "us-east-1"
}
```

Another example uses a slightly older provider pin with required_version >= 1.2.0:

```hcl
terraform {
requiredproviders {
aws = {
source = "hashicorp/aws"
version = "~> 4.16"
}
}
requiredversion = ">= 1.2.0"
}

data "awsavailabilityzones" "available" {}

provider "aws" {
region = "us-east-1"
}
```

Initialization is performed with:

bash terraform init

Note that Amazon MQ is part of the AWS free-tier for the first 12 months using micro size.

Creating a Single-Instance RabbitMQ Broker

A single-instance broker is good for development and testing. The resource definition below is from a RabbitMQ deployment example.

hcl resource "aws_mq_broker" "rabbitmq_broker" { broker_name = "rabbitmq-broker" engine_type = "RabbitMQ" engine_version = "3.11.20" host_instance_type = "mq.t3.micro" deployment_mode = "SINGLE_INSTANCE" subnet_ids = [module.vpc.public_subnets[0]] publicly_accessible = false configuration { id = aws_mq_configuration.rabbitmq_broker_config.id revision = aws_mq_configuration.rabbitmq_broker_config.latest_revision } user { username = var.rabbit_mq_username password = var.rabbit_mq_password } auto_minor_version_upgrade = true maintenance_window_start_time { day_of_week = "MONDAY" time_of_day = "18:00" time_zone = "UTC" } apply_immediately = true }

The configuration resource that is referenced:

hcl resource "aws_mq_configuration" "rabbitmq_broker_config" { description = "RabbitMQ config" name = "rabbitmq-broker" engine_type = "RabbitMQ" engine_version =

Key attributes in this pattern:

• engine_type = "RabbitMQ"
• engine_version = "3.11.20"
• hostinstancetype = "mq.t3.micro"
• deploymentmode = "SINGLEINSTANCE"
• publicly_accessible = false
• autominorversion_upgrade = true
• maintenancewindowstarttime dayofweek = "MONDAY", timeofday = "18:00", timezone = "UTC"
• apply_immediately = true

Creating a Single-Instance ActiveMQ Broker

The same Terraform workflow applies to ActiveMQ. A single-instance broker is good for development and testing. Amazon MQ supports Apache ActiveMQ and RabbitMQ engine types. Amazon MQ makes it easy to migrate to a message broker in the cloud. AWS recommends Amazon MQ for migrating applications from existing message brokers that rely on compatibility with protocols like AMQP 0-9-1, AMQP 1.0, MQTT, OpenWire, and STOMP.

A typical module usage for ActiveMQ with high availability is:

hcl module "mq_broker" { source = "cloudposse/mq-broker/aws" namespace = "eg" stage = "test" name = "mq-broker" apply_immediately = true auto_minor_version_upgrade = true deployment_mode = "ACTIVE_STANDBY_MULTI_AZ" engine_type = "ActiveMQ" engine_version = "5.15.14" host_instance_type = "mq.t3.micro" publicly_accessible = false general_log_enabled = true audit_log_enabled = true encryption_enabled = true use_aws_owned_key = true vpc_id = var.vpc_id subnet_ids = var.subnet_ids security_groups = var.security_groups }

Module Provisions and Outputs

The Cloud Posse Terraform module to provision AmazonMQ resources on AWS provisions the following resources:

• ActiveMQ broker
• RabbitMQ broker
• Security group rules to allow access to the broker

Admin and application users are created and credentials written to SSM if not passed in as variables. For a complete example, see examples/complete.

Important guidance from the module maintainers: In examples, we avoid pinning modules to specific versions to prevent discrepancies between the documentation and the latest released versions. However, for your own projects, we strongly advise pinning each module to the exact version you're using. This practice ensures the stability of your infrastructure.

The module exposes outputs such as:

Deployment Modes and Broker Comparison

Protocol support varies by engine:

• RabbitMQ supports several protocols like AMQP 0-9-1, AMQP 1.0, and MQTT
• ActiveMQ supports AMQP, MQTT, OpenWire, or STOMP

A message broker acts as a middleware to decouple services and applications independently of their logic. It also provides offers persistent message storage, guaranteed delivery and the ability to handle large volumes of messages on high workloads.

Multi-Environment Patterns

A production-tested pattern includes complete Terraform modules for VPC, Security Groups, Amazon MQ, ECS, and Route 53. Environment-specific configurations for dev, QA, performance, and production are maintained alongside PowerShell deployment scripts with automated testing, connection validation utilities, CI/CD pipeline examples for GitHub Actions, and architecture decision records explaining why specific choices were made.

The repo includes:

• Complete Terraform modules for VPC, Security Groups, Amazon MQ, ECS, and Route 53
• Environment-specific configurations for dev, QA, performance, and production
• PowerShell deployment scripts with automated testing
• Connection validation utilities
• CI/CD pipeline examples for GitHub Actions
• Architecture decision records explaining why I made specific choices

Who this pattern is for:

• Running RabbitMQ or any message queue on AWS
• Managing multiple environments with different requirements
• Tired of manual configuration and configuration drift
• Worried about disaster recovery and business continuity
• Looking to implement Infrastructure as Code properly

Networking, Logging and Security Best Practices

Applications should connect through VPC networking. Enable logging. CloudWatch logs are essential for troubleshooting connection issues and monitoring broker health.

Rotate credentials. Store passwords in Secrets Manager and rotate them periodically. Update both the secret and the broker configuration together.

Additional security settings observed in module examples include:

• publicly_accessible = false
• generallogenabled = true
• auditlogenabled = true
• encryption_enabled = true
• useawsowned_key = true

Security group rules to allow access to the broker are provisioned automatically by the module. The created security group ARN, ID and name are exposed as outputs.

Terraform Configuration Lifecycle

Amazon MQ with Terraform gives you managed messaging infrastructure that you can deploy consistently across environments. Whether you choose ActiveMQ for its protocol versatility or RabbitMQ for its routing capabilities, Terraform handles the broker lifecycle from creation through configuration updates.

The key is to start with the right deployment mode for your environment and build up from there. Single-instance is appropriate for development and testing. ACTIVESTANDBYMULTI_AZ provides high availability for production.

Use Cloud Posse's ready-to-go terraform architecture blueprints for AWS to get up and running quickly. Cloud Posse is the leading DevOps Accelerator for funded startups and enterprises. Your team can operate like a pro today. Ensure that your team succeeds by using Cloud Posse's proven process and turnkey blueprints.

Building infrastructure isn’t just about making things work — it’s about making them work reliably, securely, and cost-effectively at scale.

Conclusion

Terraform Amazon MQ enables repeatable, version-controlled broker provisioning for both RabbitMQ and ActiveMQ. The reference patterns show a clear progression from a minimal single-instance RabbitMQ broker with mq.t3.micro, engine version 3.11.20, SINGLEINSTANCE deployment, VPC subnet placement and non-public access, to a hardened multi-AZ ActiveMQ deployment with ACTIVESTANDBYMULTIAZ, encryption enabled, general and audit logging enabled, and security group automation.

Provider configuration with requiredversion >= 1.0, AWS provider ~6.0, and region us-east-1 provides a stable baseline. User management via var.rabbitmqusername and var.rabbitmqpassword, autominorversionupgrade true, and a defined maintenance window of MONDAY 18:00 UTC with apply_immediately true ensures safe updates.

Module-based approaches add SSM credential handling, standardized outputs for endpoints and security groups, and environment-specific configurations for dev, QA, performance, and production. Combined with VPC networking, CloudWatch logging, Secrets Manager rotation, and careful version pinning, Terraform delivers consistent messaging infrastructure that scales from development prototypes to production workloads without manual drift.

Sources

1. OneUptime
2. Samyouaret
3. CloudPosse GitHub
4. Medium BVInay