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

Amazon MQ runs managed message brokers (ActiveMQ and RabbitMQ) that sit in the middle of a lot of important traffic: order events, payment notifications, IoT telemetry, microservice commands. When something goes wrong with that messaging layer, the first question is always "what happened on the broker?" If general logging is off, you have no good answer.

This check, mq_generallogging, looks for Amazon MQ brokers where general logging is not enabled. It is a small configuration flag with an outsized impact on your ability to debug, audit, and respond to incidents.

---

What this check detects

Amazon MQ supports publishing broker logs to Amazon CloudWatch Logs. For ActiveMQ brokers there are two categories you can enable:

• General logging — the broker's main activity log (the ActiveMQ activemq.log equivalent). It captures connection events, broker lifecycle messages, errors, warnings, and general operational output.
• Audit logging — a separate stream that records management actions performed through the JMX or web console.

The mq_generallogging check fails when a broker has the general logging category turned off. In the Amazon MQ API this maps to the Logs.General property being false (or absent) on the broker configuration.

---

Why it matters

A message broker is a shared dependency. When it misbehaves, the blast radius covers every producer and consumer attached to it. Without general logging, you lose visibility into the exact layer where problems tend to surface.

You cannot debug what you cannot see

Consider a common production scenario: consumers start failing to receive messages, queues back up, and downstream systems stall. With general logging enabled you can look at the broker log and see connection drops, authentication failures, memory pressure warnings, or a misbehaving client repeatedly reconnecting. With it disabled, you are left guessing and restarting things.

Security and forensics

If a credential leaks and an attacker connects to your broker, the general log is one of the few records that show the connection attempts and broker-side events tied to that activity. No logs means no forensic trail. During an incident review you will not be able to reconstruct who connected, when, or what errors the broker raised.

Compliance

Frameworks like SOC 2, PCI DSS, and ISO 27001 expect logging on systems that handle sensitive data flows. An auditor asking "show me the broker logs for the last 90 days" is a bad time to discover logging was never switched on. Logging gaps also tend to fail internal controls reviews.

---

How to fix it

You enable general logging at the broker level. The change is applied during a maintenance window or immediately, depending on how you push it. Amazon MQ also needs a resource-based permission on the CloudWatch Logs log group so the broker can write to it.

Console

1. Open the Amazon MQ console and select your broker.
2. Choose Edit.
3. Under Logs, check General logging (and Audit logging if available for your engine).
4. Save and apply the change. Amazon MQ will set up the CloudWatch Logs log group and the required permissions for you.

AWS CLI

Update the broker to turn on the general log category. This is a non-destructive configuration change.

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

Confirm the change took effect:

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

You should see General reported as true, along with the CloudWatch Logs group ARNs the broker is publishing to.

Terraform

If you manage brokers with Terraform, set the logs block on the aws_mq_broker resource so the configuration is enforced in code.

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

  logs {
    general = true
    audit   = true
  }

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

CloudFormation

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

Set retention to a sensible window, for example 90 days:

aws logs put-retention-policy \
  --log-group-name "/aws/amazonmq/broker/b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9/general" \
  --retention-in-days 90 \
  --region us-east-1

---

How to prevent it from happening again

Fixing one broker by hand does not stop the next one from being created without logging. Push the requirement into your provisioning and policy layers.

Enforce it in IaC

Make the logs block mandatory in your shared Terraform module for Amazon MQ. If teams provision brokers through that module, they cannot turn logging off by accident:

variable "enable_general_logging" {
  type    = bool
  default = true

  validation {
    condition     = var.enable_general_logging == true
    error_message = "General logging must be enabled for all MQ brokers."
  }
}

Add a policy-as-code gate

Use a tool like Checkov, OPA/Conftest, or tfsec in CI to block any plan that ships a broker without general logging. A Conftest (Rego) rule against a Terraform plan looks like this:

package mq

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

Detect drift continuously

IaC and CI catch new brokers, but they do not catch changes made directly in the console or by another team. Run a continuous scan across your accounts so a broker that gets reconfigured shows up quickly. Lensix runs the mq_generallogging check on a schedule and flags any broker that falls out of compliance, including ones created outside your pipeline.

---

Best practices

• Enable general and audit logging together. They cover different things, operational events versus administrative actions. You want both for a full record.
• Set log retention deliberately. Match retention to your compliance requirements, then let CloudWatch expire logs automatically to control cost.
• Route logs into your monitoring stack. Forward the broker log group to your SIEM or set CloudWatch metric filters and alarms on error patterns, connection failures, and authentication issues.
• Alarm on broker health, not just logs. Pair logging with CloudWatch metrics like CpuUtilization, HeapUsage, and queue depth so you catch problems before they cascade.
• Standardize across environments. Logging should be on in dev and staging too. Brokers behave differently under load, and you want consistent visibility everywhere.
• Review log access. Logs can contain sensitive operational detail. Restrict who can read the broker log group with IAM, and treat that access like any other sensitive data control.

General logging is one checkbox, but it is the difference between a quick root cause and a long, frustrating outage with no evidence to go on. Turn it on, enforce it in code, and keep an eye on drift.