Does Amazon MQ use IAM policies to control who can publish or consume messages?

No, not for broker-level message operations, that's controlled by the broker's own Users and Groups (application-level credentials, similar to standing up your own ActiveMQ or RabbitMQ instance), IAM policies control AWS API-level operations (creating/modifying/deleting the broker itself), but actual message pub/sub authorization is the broker engine's native user/permission model, a genuinely different security boundary that's easy to conflate with AWS-native services like SQS/SNS.

What's the practical benefit of ACTIVE_STANDBY_MULTI_AZ over SINGLE_INSTANCE?

ACTIVE_STANDBY_MULTI_AZ maintains a synchronized standby broker in a second AZ that automatically takes over if the active broker fails or during planned maintenance, providing meaningfully better availability for production workloads. SINGLE_INSTANCE has no standby, a broker failure or maintenance window causes an outage until the single instance recovers, appropriate for dev/test but a real availability risk for production message flows.

Can a broker's storage type be changed after creation?

StorageType (EFS vs. EBS, depending on engine and deployment mode) is generally a creation-time architectural choice tied to the broker's deployment mode and engine type, not something freely switchable afterward, changing it typically requires creating a new broker rather than an in-place migration, verify the storage type fits your durability and throughput needs before initial deployment.

AWS MQ Broker Config Builder

ServerlessAWS

Build Amazon MQ broker configurations for ActiveMQ/RabbitMQ with multi-AZ, encryption, users, and logging.

Amazon MQ Configuration

Build Amazon MQ broker configurations for ActiveMQ/RabbitMQ with multi-AZ, encryption, users, and logging.

Required Fields

BrokerNameEngineTypeHostInstanceTypeDeploymentModeUsers

{
  "BrokerName": "prod-message-broker",
  "EngineType": "ACTIVEMQ",
  "EngineVersion": "5.17.6",
  "HostInstanceType": "mq.m5.large",
  "DeploymentMode": "ACTIVE_STANDBY_MULTI_AZ",
  "PubliclyAccessible": false,
  "AutoMinorVersionUpgrade": true,
  "SubnetIds": [
    "subnet-0abc123def456789a",
    "subnet-0abc123def456789b"
  ],
  "SecurityGroups": ["sg-0abc123def456789a"],
  "Users": [
    {
      "Username": "admin",
      "Password": "CHANGE_ME_admin_password!",
      "ConsoleAccess": true,
      "Groups": ["admin"]
    },
    {
      "Username": "app-producer",
      "Password": "CHANGE_ME_producer_password!",
      "ConsoleAccess": false,
      "Groups": ["producers"]
    }
  ],
  "Configuration": {
    "Id": "c-0abc123def456789",
    "Revision": 2
  },
  "EncryptionOptions": {
    "UseAwsOwnedKey": false,
    "KmsKeyId": "arn:aws:kms:us-east-1:123456789012:key/abcd1234-ef56-gh78-ij90-klmnopqrstuv"
  },
  "Logs": {
    "Audit": true,
    "General": true
  },
  "MaintenanceWindowStartTime": {
    "DayOfWeek": "SUNDAY",
    "TimeOfDay": "03:00",
    "TimeZone": "UTC"
  },
  "StorageType": "EFS",
  "Tags": {
    "Environment": "production",
    "Service": "messaging"
  }
}

Generated Output

Output will appear here...

What This Tool Does

Build an Amazon MQ broker (ActiveMQ or RabbitMQ engine) with ACTIVE_STANDBY_MULTI_AZ deployment mode for automatic failover, VPC-scoped networking via SecurityGroups and SubnetIds, and broker-level Users, a fundamentally different security model from IAM-based AWS-native messaging services, since MQ broker authentication uses application-level usernames/passwords (or LDAP), not IAM policies, meaning access control here lives in the broker's own user/group model, not in an IAM policy document.

Technical Details

The builder validates that BrokerName, EngineType, HostInstanceType, DeploymentMode, and Users all resolve before accepting the JSON as a valid CreateBroker request, the fields Amazon MQ needs to provision the broker, its engine, sizing, deployment topology, and initial user accounts; it can't verify the referenced subnet/security group IDs exist or that broker-level user passwords meet the engine's complexity requirements, those checks happen only against the live API.

Common Use Cases

1Choosing ACTIVE_STANDBY_MULTI_AZ deployment mode for a production broker needing automatic failover to a standby instance in a different AZ, versus SINGLE_INSTANCE for a dev/test broker where brief downtime during maintenance is acceptable.
2Creating separate Users with distinct Groups (admin versus producers) so the console-accessible admin account is separate from the application credential used just to publish messages, limiting blast radius if the application credential is ever exposed.
3Setting PubliclyAccessible to false and placing the broker's SubnetIds inside a private VPC subnet, so the broker is only reachable from within the VPC (or via VPN/Direct Connect), not exposed to the public internet at all.
4Enabling both Audit and General log types under Logs, since Audit specifically tracks administrative and security-relevant actions on the broker, while General covers broker application-level operational logging, they're not redundant, they capture different event classes.

Common Questions

Does Amazon MQ use IAM policies to control who can publish or consume messages?: No, not for broker-level message operations, that's controlled by the broker's own Users and Groups (application-level credentials, similar to standing up your own ActiveMQ or RabbitMQ instance), IAM policies control AWS API-level operations (creating/modifying/deleting the broker itself), but actual message pub/sub authorization is the broker engine's native user/permission model, a genuinely different security boundary that's easy to conflate with AWS-native services like SQS/SNS.
What's the practical benefit of ACTIVE_STANDBY_MULTI_AZ over SINGLE_INSTANCE?: ACTIVE_STANDBY_MULTI_AZ maintains a synchronized standby broker in a second AZ that automatically takes over if the active broker fails or during planned maintenance, providing meaningfully better availability for production workloads. SINGLE_INSTANCE has no standby, a broker failure or maintenance window causes an outage until the single instance recovers, appropriate for dev/test but a real availability risk for production message flows.
Can a broker's storage type be changed after creation?: StorageType (EFS vs. EBS, depending on engine and deployment mode) is generally a creation-time architectural choice tied to the broker's deployment mode and engine type, not something freely switchable afterward, changing it typically requires creating a new broker rather than an in-place migration, verify the storage type fits your durability and throughput needs before initial deployment.

Expert Tips

TIP

Don't assume IAM policies control message-level access the way they do for SQS/SNS, Amazon MQ's actual pub/sub authorization lives in the broker's own Users/Groups model, verify broker-level permissions are correctly scoped, not just the IAM policy governing the broker resource itself.

TIP

Separate admin (console-access) credentials from application (publish/consume-only) credentials from the start, using one shared admin credential for both broker management and application message publishing means a leaked application credential also grants broker admin access.

TIP

ACTIVE_STANDBY_MULTI_AZ is worth the modest additional cost for any production messaging workload where broker downtime translates into lost or delayed messages, SINGLE_INSTANCE's cost savings usually aren't worth the availability tradeoff outside of dev/test.

Related Learning Guides

Lambda Performance Tuning26 min read
SQS vs SNS vs EventBridge25 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.

AWS MQ Broker Config Builder

ServerlessAWS

Build Amazon MQ broker configurations for ActiveMQ/RabbitMQ with multi-AZ, encryption, users, and logging.

Amazon MQ Configuration

Build Amazon MQ broker configurations for ActiveMQ/RabbitMQ with multi-AZ, encryption, users, and logging.

Required Fields

BrokerNameEngineTypeHostInstanceTypeDeploymentModeUsers

Generated Output

Output will appear here...

What This Tool Does

Technical Details

Common Use Cases

1Choosing ACTIVE_STANDBY_MULTI_AZ deployment mode for a production broker needing automatic failover to a standby instance in a different AZ, versus SINGLE_INSTANCE for a dev/test broker where brief downtime during maintenance is acceptable.
2Creating separate Users with distinct Groups (admin versus producers) so the console-accessible admin account is separate from the application credential used just to publish messages, limiting blast radius if the application credential is ever exposed.
3Setting PubliclyAccessible to false and placing the broker's SubnetIds inside a private VPC subnet, so the broker is only reachable from within the VPC (or via VPN/Direct Connect), not exposed to the public internet at all.
4Enabling both Audit and General log types under Logs, since Audit specifically tracks administrative and security-relevant actions on the broker, while General covers broker application-level operational logging, they're not redundant, they capture different event classes.

Common Questions

Does Amazon MQ use IAM policies to control who can publish or consume messages?: No, not for broker-level message operations, that's controlled by the broker's own Users and Groups (application-level credentials, similar to standing up your own ActiveMQ or RabbitMQ instance), IAM policies control AWS API-level operations (creating/modifying/deleting the broker itself), but actual message pub/sub authorization is the broker engine's native user/permission model, a genuinely different security boundary that's easy to conflate with AWS-native services like SQS/SNS.
What's the practical benefit of ACTIVE_STANDBY_MULTI_AZ over SINGLE_INSTANCE?: ACTIVE_STANDBY_MULTI_AZ maintains a synchronized standby broker in a second AZ that automatically takes over if the active broker fails or during planned maintenance, providing meaningfully better availability for production workloads. SINGLE_INSTANCE has no standby, a broker failure or maintenance window causes an outage until the single instance recovers, appropriate for dev/test but a real availability risk for production message flows.
Can a broker's storage type be changed after creation?: StorageType (EFS vs. EBS, depending on engine and deployment mode) is generally a creation-time architectural choice tied to the broker's deployment mode and engine type, not something freely switchable afterward, changing it typically requires creating a new broker rather than an in-place migration, verify the storage type fits your durability and throughput needs before initial deployment.

Expert Tips

TIP

Related Learning Guides

Lambda Performance Tuning26 min read
SQS vs SNS vs EventBridge25 min read

Was this tool helpful?