Amazon MQ Broker Audit Logging Disabled: Why It Matters and How to Fix It

Amazon MQ is a managed message broker service for Apache ActiveMQ and RabbitMQ. It sits in the middle of a lot of architectures, shuttling messages between services, queuing work, and decoupling producers from consumers. Because so much traffic passes through it, the broker is a high-value target and a critical operational component. Yet many teams spin one up, point their apps at it, and never enable the logging that would tell them what is happening on the management plane.

The mq_auditlogging check looks for ActiveMQ brokers that do not have audit logging turned on. If audit logs are off, you have no record of who changed broker configuration, who connected through the web console, or what administrative operations were performed.

---

What this check detects

The check inspects each Amazon MQ broker and verifies whether audit logging is enabled in the broker's Logs configuration. Amazon MQ for ActiveMQ supports two log types:

• General logs — the broker's general activity, similar to the ActiveMQ activemq.log file.
• Audit logs — a record of management actions taken through the ActiveMQ Web Console and the JMX API, including configuration changes and administrative commands.

This check focuses on the audit log. When Logs.Audit is set to false (or never configured), the broker fails the check.

---

Why it matters

A message broker is not just plumbing. It holds connection credentials, routing rules, and access to the data flowing between your services. Without audit logging, you lose visibility into the management plane of that broker.

Here are the concrete problems that creates.

You cannot investigate an incident

Suppose a queue gets purged in production and consumers start failing. Was it an application bug, a botched deploy, or someone using the web console to delete the queue by hand? Without audit logs, you are guessing. With them, you can see the management action, the source, and the timestamp in CloudWatch Logs.

Administrative changes go unrecorded

The ActiveMQ Web Console lets operators create and delete destinations, browse messages, and change runtime behavior. These actions do not appear in CloudTrail because they happen inside the broker, not through the AWS API. Audit logging is the only way to capture them.

Compliance gaps

Frameworks like PCI DSS, SOC 2, HIPAA, and ISO 27001 expect you to log access to systems that handle sensitive data. If your broker carries payment events, health records, or customer PII, an auditor will ask how you track administrative access to it. "We don't" is not an answer that passes.

Slower detection of misuse

If a credential leaks and someone connects to your broker console, audit logs give you a trail to detect and scope the abuse. Without them, an attacker can poke around the management interface and leave nothing behind.

---

How to fix it

Enabling audit logging requires two things: an IAM permission so Amazon MQ can write to CloudWatch Logs, and the logging setting itself on the broker.

Step 1: Confirm the service-linked permissions

Amazon MQ needs permission to publish logs to a CloudWatch Logs group. This is handled by a resource-based policy on CloudWatch Logs that allows the Amazon MQ service principal to write. If you have never enabled logging before, add the policy below.

{
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "mq.amazonaws.com"
      },
      "Action": [
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:111122223333:log-group:/aws/amazonmq/*:*"
    }
  ]
}

Apply it with the CloudWatch Logs put-resource-policy call:

aws logs put-resource-policy \
  --policy-name AmazonMQ-logging \
  --policy-document file://mq-logs-policy.json

Step 2: Enable audit logging on the broker (CLI)

Use update-broker to flip audit logging on. You should preserve the general log setting if it is already enabled.

aws mq update-broker \
  --broker-id b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9 \
  --logs General=true,Audit=true

Verify the change took effect:

aws mq describe-broker \
  --broker-id b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9 \
  --query 'Logs'

You should see "Audit": true in the response along with the CloudWatch Logs group where the logs are being delivered.

Step 3: Enable it in the console

1. Open the Amazon MQ console and select your broker.
2. Choose Edit.
3. Scroll to the Logs section.
4. Check Audit logging (and General logging if you want both).
5. Choose Save and apply the change.

Step 4: Fix it with Terraform

If you manage brokers as code, set the logs block on the aws_mq_broker resource. This is the cleanest place to enforce it so it never drifts.

resource "aws_mq_broker" "orders" {
  broker_name        = "orders-broker"
  engine_type        = "ActiveMQ"
  engine_version     = "5.18.4"
  host_instance_type = "mq.m5.large"
  deployment_mode    = "ACTIVE_STANDBY_MULTI_AZ"

  logs {
    general = true
    audit   = true
  }

  user {
    username = "admin"
    password = var.mq_admin_password
  }
}

And the equivalent in CloudFormation:

{
  "Type": "AWS::AmazonMQ::Broker",
  "Properties": {
    "BrokerName": "orders-broker",
    "EngineType": "ActiveMQ",
    "EngineVersion": "5.18.4",
    "HostInstanceType": "mq.m5.large",
    "DeploymentMode": "ACTIVE_STANDBY_MULTI_AZ",
    "Logs": {
      "General": true,
      "Audit": true
    }
  }
}

---

How to prevent it from happening again

Fixing one broker by hand is fine. The real win is making sure the next broker someone creates already has audit logging on. A few layers help here.

Block non-compliant brokers in IaC pipelines

If you use Terraform, run a policy-as-code check in CI before apply. Here is a Checkov-style custom policy concept using OPA/Conftest against a Terraform plan:

package mq

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_mq_broker"
  not resource.change.after.logs[_].audit
  msg := sprintf("MQ broker '%s' must have audit logging enabled", [resource.address])
}

Wire that into your pipeline so a pull request that adds a broker without audit = true fails before it ever reaches AWS.

Enforce with AWS Config

Use an AWS Config custom rule to continuously evaluate live brokers. A Lambda-backed rule can call describe-broker, check the Logs.Audit value, and mark the broker non-compliant if it is off. Pair it with an automatic remediation that runs update-broker, or just route the finding to your team.

Standardize through a module

If every team provisions brokers through a shared Terraform module that hard-codes audit = true, individual teams cannot accidentally skip it. Centralizing the resource definition removes the chance of drift across dozens of repos.

---

Best practices

Audit logging is one piece. Treat the broker as a sensitive system and harden the rest of it too.

• Enable both log types. General logs help with broker troubleshooting; audit logs cover security and change tracking. Most teams want both on.
• Set retention and metric filters. Send the audit log group through CloudWatch metric filters and alarms so a spike in administrative actions or failed console logins pages someone.
• Restrict console access. The ActiveMQ Web Console should not be reachable from the public internet. Keep brokers in private subnets and reach them through a bastion or VPN.
• Use strong, rotated broker credentials. Store the admin password in Secrets Manager and rotate it. Audit logs are most useful when each operator has their own identity rather than a shared admin account.
• Encrypt and isolate. Enable encryption at rest with a customer-managed KMS key and require TLS for connections so logging captures a clean, trustworthy picture of a properly secured broker.
• Forward logs centrally. Ship audit logs from CloudWatch to your SIEM so they live alongside the rest of your security telemetry and survive even if an account is compromised.

Turning on audit logging takes one CLI call or a two-line change in your IaC. The payoff is a permanent record of every administrative action on a broker that often sits at the center of your architecture. Enable it once, enforce it in your pipeline, and move on.