Security, Multi-Region Replication, and Disaster Recovery
A messaging pipeline with no authentication, no encryption, and no cross-region replica is a single point of failure on three independent axes. This article implements Kafka mTLS and SASL/SCRAM, MSK IAM auth, MirrorMaker 2 active-passive replication, and a concrete disaster recovery runbook for promoting a passive cluster and resuming consumer groups from translated offsets.
Messaging at Cloud Scale
Security, Multi-Region Replication, and Disaster Recovery
At 2:14 a.m., a penetration tester connects to the Kafka broker on port 9092 with no credentials. The broker accepts the connection. The tester publishes 10,000 synthetic payment.charged events to the production topic. The fulfillment service processes them. The company dispatches 10,000 phantom orders before a monitoring alert fires 12 minutes later. The root cause is a Kafka cluster with security.inter.broker.protocol=PLAINTEXT and allow.everyone.if.no.acl.found=true — the defaults on a self-managed Kafka cluster that was "just for development" six months ago and quietly became production.
Separately: us-east-1 goes dark at 7:03 a.m. due to an AWS availability zone impairment. The Kafka cluster is in us-east-1. The consumer groups have no idea what offset to start from in the eu-west-1 passive cluster. They reset to earliest. Two million messages are reprocessed. The downstream services, which are not idempotent for this volume, produce duplicate charges, duplicate shipments, and duplicate notification emails for six hours.
Both failures are preventable. Neither requires exotic tooling.
Series positioning: This is Part 6 and the final article of Messaging at Cloud Scale (Series 2). It covers the operational hardening layer that makes every pattern from Series 1 and Series 2 production-safe. The prerequisite for the IAM section is AWS Security: IAM, VPC, and Networking.
1. Kafka Authentication
1.1 mTLS: Mutual Authentication
mTLS verifies both the broker's identity (client knows it is talking to a legitimate broker) and the client's identity (broker knows who is connecting). Neither SASL nor plaintext authentication verifies the broker.
1.2 SASL/SCRAM: Client-Only Authentication
SASL/SCRAM is simpler to operate than mTLS but only authenticates the client — the broker identity is unverified (susceptible to rogue broker injection in a compromised network):
| Mechanism | Verifies broker | Verifies client | Credential rotation | Best for |
|---|---|---|---|---|
| PLAINTEXT | ❌ | ❌ | N/A | Local dev only |
| SASL/SCRAM | ❌ | ✅ | Manual (rotate password) | Internal services, simpler setup |
| mTLS | ✅ | ✅ | Certificate rotation (PKI) | External clients, regulated environments |
| MSK IAM | ✅ (AWS-managed) | ✅ (IAM role) | Never — IAM rotates automatically | AWS-native workloads |
1.3 Kafka ACLs
2. MSK IAM Authentication (Zero-Credential Model)
MSK IAM auth eliminates credential rotation entirely. The IAM role attached to the ECS task IS the client identity — AWS rotates the underlying credentials automatically via the EC2 metadata service. Audit every connection via CloudTrail: kafka-cluster:Connect events appear per client, per cluster, per timestamp. This is the correct model for any AWS-native Kafka deployment.
3. Multi-Region Replication with MirrorMaker 2
3.1 Active-Passive Architecture
3.2 MirrorMaker 2 Configuration
3.3 Disaster Recovery Runbook
MirrorMaker 2 translates consumer group offsets across clusters, but the translation is not instantaneous. With sync.group.offsets.interval.seconds=60, consumers resuming in the passive cluster may replay up to 60 seconds of messages. Consumers must be idempotent — this is not an edge case during DR, it is the expected behaviour. Without idempotency, a 60-second replay produces 60 seconds of duplicate side effects.
4. RPO and RTO Model
| Metric | Self-Managed MM2 | Amazon MSK Multi-Region | Amazon EventBridge Global Endpoints |
|---|---|---|---|
| RPO (data loss) | 60s (sync interval) | < 1s (native replication) | < 1s |
| RTO (recovery time) | 10–20 min (manual runbook) | 5–10 min (auto-failover) | < 1 min (automatic) |
| Operational burden | High | Low | Very low |
| Cost | MirrorMaker EC2 | MSK x2 regions | Per-event pricing |
| Kafka API preserved | Yes | Yes | No (EventBridge only) |
Summary
| Concept | Rule |
|---|---|
| mTLS vs SASL | mTLS authenticates both broker and client identity; SASL/SCRAM authenticates only the client — use mTLS when the broker identity must also be verified (preventing rogue broker injection). |
| MirrorMaker 2 offset translation | MirrorMaker 2 translates consumer group offsets across clusters; without offset translation, a failover restores consumers to the beginning of the topic, not to their last committed position. |
| MSK IAM zero-credential | MSK IAM auth eliminates credential rotation entirely: the IAM role attached to the ECS task / EC2 instance IS the client identity — rotate nothing, audit everything via CloudTrail. |
Series 2 — Messaging at Cloud Scale — is complete. Together with Series 1, these 18 articles form the complete Distributed Messaging Systems curriculum: from first principles (why async messaging) to cloud-native production hardening (security, multi-region DR, disaster recovery).
This article was developed with AI-assisted deep search, specification cross-referencing, and technical research synthesis.