Amazon MSK Replicator vs. MirrorMaker 2: Choosing a Cross-Region Kafka Replication Path

Cross-region Kafka replication looks like a choice between two tools. In production, it is a choice about who owns the replication plane, how topic names and offsets move, where a failure is detected, and what the team must prove before it sends traffic back to the original region.

Amazon MSK Replicator is a managed feature of Amazon MSK. Apache Kafka MirrorMaker 2 (MM2) is a Kafka Connect-based replication system that your team deploys and operates. Both can move records between clusters, but they make different trade-offs around control, topology, observability, and change management.

The useful comparison starts with the recovery story. If a region fails during an overnight incident, can consumers resume from a known position? If a planned migration is reversed, can producers be fenced and offsets translated in the return direction? If the answer depends on a configuration file, a runbook, or an AWS service setting, that dependency belongs in the decision.

1Why teams compare MSK Replicator and MirrorMaker 2

The two options appear together in three situations:

• Cross-region disaster recovery: keep a second cluster current and move producers and consumers after a regional event.
• Migration: copy from self-managed Kafka or another managed cluster to Amazon MSK while clients move in stages.
• Multi-region operation: serve local traffic in more than one region and decide how replicated topics, duplicate records, and consumer groups behave.

The surface question is “Which replicates Kafka data?” Both do. The decision questions are more specific:

1. Do you want replication capacity and networking to be a managed service boundary, or do you need to run the workers yourself?
2. Do consumers need identical topic names after a failover, or is a source prefix useful for separating local and remote data?
3. Is one-way offset synchronization enough, or must failback translate offsets in both directions?
4. Do you need to change filters, converters, quotas, or routing logic without waiting for a provider feature?
5. Can the team operate and test the replication system as carefully as the Kafka clusters themselves?

Those questions produce a better shortlist than a feature checklist because they describe what has to happen when the normal path stops.

2Replication semantics and topology

2.1What Amazon MSK Replicator provides

AWS describes MSK Replicator as an asynchronous service for replicating data between MSK clusters in the same or different AWS Regions. It can also replicate from self-managed Apache Kafka into an MSK Provisioned cluster. AWS says the service automatically scales its underlying resources and copies topic configuration, supported ACLs, and consumer group offsets along with records. Source and target MSK clusters must be in the same AWS account when replicating between MSK clusters.

The service creates resources in the target region. Replication latency therefore depends on the distance between regions, the read and write capacity of the two clusters, and the number of partitions. That is a workload property, not a fixed promise in the service name.

MSK Replicator has two topic naming modes:

• Prefixed: the target topic receives a source-cluster prefix. This keeps the remote copy distinct and is the recommended pattern for active-active designs in the current AWS guidance.
• Identical: the target keeps the source topic name. This reduces client reconfiguration during active-passive failover, while MSK Replicator uses record headers to avoid replicating a record back to the topic it originated from.

The choice changes the consumer design. Prefixed topics let local and replicated streams coexist, but consumers must subscribe to the correct names or patterns. Identical names make a standby cutover simpler, but they do not remove the need to fence writers and verify which cluster is authoritative.

MSK Replicator’s offset behavior also has a boundary that matters during failback. Offset translation is approximate and intentionally favors at-least-once processing, so consumers may re-read a small number of records after switching clusters. In a standard one-way setup, offsets are synchronized from source to target; AWS documents enhanced bidirectional offset synchronization for a pair of replicators when consumers may move in both directions. That mode requires identical topic names and two opposite replication flows.

2.2What MirrorMaker 2 provides

MM2 is part of Apache Kafka and runs on Kafka Connect. It consumes from one cluster and produces to another through source, checkpoint, and heartbeat connectors. The Apache Kafka documentation describes directional replication flows, topic and consumer-group filters, configurable replication policies, and metrics under the kafka.connect.mirror metric group.

The default replication policy prefixes remote topics with the source cluster alias, such as us-west.orders. This prevents a remote topic from being confused with a local topic and helps avoid loops. You can customize the separator or implement a custom ReplicationPolicy when the default names do not fit the target application. MM2 can also synchronize translated consumer offsets, but the behavior is controlled by connector configuration and the state of the checkpoint and offset-sync topics.

MM2 therefore gives you a larger control surface:

• Select topics and consumer groups with regular expressions.
• Choose converters, producer and consumer settings, quotas, security protocols, and placement of the Connect workers.
• Run one-way or bidirectional flows by enabling each direction explicitly.
• Add workers when a replication flow needs more throughput.

That control is useful when the target is not another MSK cluster or when you need a transformation, filter, or custom naming policy. It also makes the replication plane part of your Kafka platform. Worker placement, upgrades, connector restarts, configuration drift, and Connect internal topics become your operational responsibility.

2.3The topology decision

Both systems can represent active-passive and active-active designs, but they make the topology visible in different ways.

The table is not a ranking. It shows where the ownership boundary moves. MSK Replicator reduces the amount of infrastructure you run. MM2 gives you more knobs to make the infrastructure behave exactly as your topology requires.

3Operations and failure handling

3.1Planned failover is a test, not a click

A planned failover should prove that the secondary region can become authoritative without losing the team’s understanding of offsets and write ownership. For an active-passive MSK design, AWS’s runbook starts by stopping producers and consumers on the source, creating a reverse Replicator for data written in the secondary region, and then starting clients on the target. The exact steps differ between Prefixed and Identical naming, especially when ordering matters.

For MM2, the same control points are implemented by your runbook and configuration. You must stop or fence writers, verify that replication has caught up, choose whether consumers read remote topics first, and confirm that translated offsets are safe for the workload. MM2’s documentation recommends placing a MirrorMaker process near the target cluster because producers are more sensitive to a high-latency or unreliable path than consumers.

The test should leave evidence behind:

• The source and target bootstrap endpoints used by each client class.
• The topic and consumer-group filters active during the test.
• The record and offset lag at the handoff point.
• The producer fencing mechanism and the time it took to redirect traffic.
• The duplicate-processing and ordering behavior observed by consumers.

If those artifacts do not exist, the test measured operator confidence rather than recovery capability.

3.2Unplanned failover changes the data-loss conversation

MSK Replicator is asynchronous. AWS explicitly notes that an unplanned failover can lose records that have not reached the target. Replication latency and message lag are therefore part of the failover signal. A target cluster can be healthy while still being behind the source.

MM2 has the same fundamental property because it consumes and produces records across a network. The difference is who has to assemble the signal. Your team must monitor MirrorSourceConnector replication latency, checkpoint latency, worker health, and the health of the source and target clusters. A “green” Connect process does not prove that every topic is current.

Ordering also needs an explicit decision. If consumers read both local and replicated topics during a prefixed failover, the application may see records in an order that differs from the original source partition sequence. If ordering is required, AWS’s prefixed-topic procedure has consumers drain the replicated topics before switching to local topics. The same rule applies to MM2: do not ask a wildcard subscription to preserve an ordering guarantee it was never designed to provide.

3.3Failback is where shallow comparisons break

Failback is a second migration. Data written while the secondary region was active must return to the primary, and consumer positions must be translated in the opposite direction. The original one-way plan is no longer sufficient.

For MSK Replicator, AWS recommends creating a new reverse Replicator with an Earliest starting position when data produced during an unplanned outage must be copied back. The failback guide says to monitor MessageLag until the reverse flow catches up, move producers, wait for consumer lag to drain, and then verify that the original forward Replicator is running again. With Identical topic names and enhanced bidirectional offset synchronization, the two Replicators can translate offsets in either direction; the consumers still need idempotent processing because translation is approximate.

For MM2, failback normally means enabling or validating the reverse flow, confirming the checkpoint and offset-sync state, and deciding whether remote topic prefixes map cleanly to the target application. If the replication policy or topic filters changed during the incident, the return path can silently differ from the forward path. That is why a failback rehearsal should use the same topic inventory and consumer groups as production, rather than a small synthetic topic.

4Cost inputs that belong in the comparison

The replication tool is only one line in a cross-region design. Model the complete path:

1. Source and target clusters: broker or serverless capacity, storage, retention, and the headroom required for replication traffic.
2. Replication service: AWS’s current MSK pricing page charges MSK Replicator by Replicator-hours and by gigabytes processed, including metadata; MM2 turns the equivalent work into Connect worker instances, storage for internal topics, and the team’s operating cost.
3. Cross-region transfer: AWS applies standard cross-region data-transfer charges for MSK Replicator CRR. MM2 has the same network reality, whether workers run on EC2, EKS, or another platform.
4. Private connectivity: MSK Replicator’s cross-region setup uses MSK private connectivity and security groups. MM2 may need VPC routing, PrivateLink, Transit Gateway, or inter-region connectivity that your network team already operates.
5. Failure and replay: An Earliest replay during failback can process data that will later be filtered as already replicated. AWS notes that such data can still incur processing and transfer charges.

Do not compare a service rate with an EC2 instance rate and call the result a TCO. Count the second cluster, the workers, the network path, the monitoring, the on-call coverage, and the time needed to rehearse a reverse flow. Then run the model with your actual bytes in, retention, partition count, and failover frequency.

5Migration and failback checklist

Use the following checklist before choosing a replication path:

5.1Inventory the application contract

Record topic names, partition counts, replication factor, cleanup policy, retention, compaction, schemas, ACLs, IAM policies, transactional producers, connectors, consumer groups, and offset-reset policies. A Kafka protocol match does not mean that every operational dependency will be copied automatically.

5.2Define the recovery boundary

Write down which region is authoritative, how writers are fenced, what “caught up” means, and whether the target may process duplicates. Express RPO and RTO as acceptance criteria for your workload instead of borrowing a generic number from a product page.

5.3Pick topic naming deliberately

Use Identical names when the primary concern is a simple active-passive client switch and your clients can handle the loop-prevention headers. Use Prefixed names when local and remote data must remain visibly separate, especially for active-active or aggregation patterns. Test wildcard subscriptions and ordering before production.

5.4Validate offset translation

Compare source offsets, translated target offsets, and application-level checkpoints. Start a test consumer group on the target only after the translation has been observed; AWS and Apache Kafka both protect existing target consumers from being overwritten, which can make a premature test look successful while it starts from the wrong position.

5.5Rehearse the return path

Perform a reverse replication test with producers fenced, consumers drained, and a measured lag threshold. Verify that topic filters, ACLs, quotas, and connector configuration are symmetrical enough for the return trip. Keep the exact commands and metric evidence in the runbook.

5.6Recalculate the bill after the topology is fixed

Use the AWS MSK pricing page and MSK Replicator quotas for the current service terms. For MM2, include the workers and the Kafka Connect internal topics. Do not use a fixed per-GB figure from an older blog as a forecast for a different region.

6Decision matrix

The right answer usually follows the ownership boundary rather than a single feature.

The matrix also shows why a “managed versus self-managed” answer is incomplete. The managed path reduces infrastructure ownership, but it does not remove the need to design client routing and failback. The self-managed path increases control, but it also makes replication a first-class production system with its own SLOs and on-call load.

7Where a Kafka-compatible shared-storage platform fits

Replication solves a geographic availability or migration problem. It does not change the storage model inside either Kafka cluster. If the next constraint is broker-local storage, slow partition movement, or the need to keep durable data in a customer-owned object store, the evaluation should widen from replication tooling to the Kafka platform itself.

This is where AutoMQ, a Kafka-compatible streaming platform with a Shared Storage architecture, can enter the conversation. AutoMQ’s architecture documentation describes separating broker compute from durable stream storage backed by S3-compatible object storage. The point is not to claim that AutoMQ replaces every MSK Replicator or MM2 topology. The point is to give a team a portable Kafka-facing target whose scaling and retention decisions are less tied to broker-local disks.

That distinction matters during an exit discussion. You can keep MSK Replicator or MM2 as a migration bridge, preserve Kafka client and connector contracts where they remain valid, and then evaluate whether a shared-storage platform reduces the amount of data movement required for future broker changes. AutoMQ’s shared-storage architecture documentation and stateless broker documentation explain that model; your proof of concept still needs to test the clients, connectors, retention, recovery, and observability that matter to your workload.

For adjacent migration patterns, compare this decision framework with AutoMQ’s Kafka replication concepts and best practices and Beyond MM2: Kafka migration with zero downtime. Those articles cover broader migration mechanics; this article stays focused on choosing the cross-region replication path.

The boundary is straightforward:

• Stay with MSK Replicator when AWS-managed MSK-to-MSK replication is the requirement and its naming, offset, account, and cost constraints fit.
• Choose MM2 when the team needs cross-platform reach or control over the replication runtime and accepts the operational burden.
• Evaluate AutoMQ when the replication decision is part of a larger move toward Kafka compatibility with shared storage, elastic compute, and a customer-controlled deployment model.

8FAQ

8.1Is Amazon MSK Replicator the same as MirrorMaker 2?

No. MSK Replicator is a managed Amazon MSK feature. MirrorMaker 2 is an Apache Kafka Connect-based replication system that you deploy and configure. Both replicate records and can synchronize consumer positions, but their ownership boundaries and configuration surfaces differ.

8.2Does MSK Replicator support cross-region disaster recovery?

Yes. AWS documents cross-region replication, active-passive and active-active patterns, planned and unplanned failover, and failback. Replication is asynchronous, so monitor message and replication latency and define how the application handles records that have not reached the target.

8.3Does MirrorMaker 2 preserve consumer offsets?

MM2 can emit checkpoints and synchronize translated group offsets through its checkpoint and offset-sync connectors. The settings, filters, topic naming policy, and worker health determine whether the target position is usable. Validate offsets with a real consumer group before a cutover.

8.4Which option is better for failback?

Neither is automatically safer. MSK Replicator has an AWS-documented bidirectional offset-sync mode that uses two Replicators and Identical topic names. MM2 can implement a reverse flow with checkpointing, but the team owns the configuration and evidence. The deciding factor is whether the return path has been rehearsed with writers fenced and duplicates handled.

8.5Can AutoMQ replace MSK Replicator or MirrorMaker 2?

AutoMQ is a Kafka-compatible platform, not a claim that every replication topology disappears. Treat it as a possible target in a migration or architecture evaluation when shared storage, elastic broker compute, and customer-controlled deployment are requirements. Keep the replication bridge and cutover checks that your workload needs.

When the decision reaches a real workload, use the AutoMQ deployment assessment to compare the migration bridge, Kafka compatibility checks, storage model, and recovery evidence against your current MSK design.

9References

• Amazon MSK Replicator
• How Amazon MSK Replicator works
• Amazon MSK topic naming
• Amazon MSK consumer group offset synchronization
• Amazon MSK failover and failback patterns
• Amazon MSK pricing
• Apache Kafka Geo-Replication and MirrorMaker 2
• Apache Kafka MirrorMaker configuration
• MSK Replicator: Cross-Region Kafka DR on AWS
• AWS MSK Disaster Recovery Setup, DoiT