MSK Replicator: Cross-Region Kafka DR on AWS (Complete Guide)

MSK Replicator is a fully managed feature of Amazon MSK that copies topic data, consumer group offsets, and topic configurations between MSK clusters — across regions or across accounts — without you running any replication infrastructure. AWS manages the brokers, but cross-region disaster recovery for your streams is still your responsibility. MSK Replicator closes that gap. This guide covers its architecture, how to set it up for cross-region DR, failover procedures, and when to choose it over MirrorMaker 2.

Key takeaway

Reach for MSK Replicator when both clusters live on Amazon MSK and you want managed cross-region replication with no Connect cluster to operate. Choose MirrorMaker 2 when you need multi-cloud reach, finer control, or lower cost at scale. And remember: neither one is a backup. Replication copies deletions and corrupt records to the target in milliseconds, so pair it with point-in-time backup for real recoverability.

What is MSK Replicator?

MSK Replicator is an Amazon MSK feature that replicates data between MSK clusters for you. You point it at a source cluster and a target cluster, and AWS handles the compute, networking, and scaling behind the replication. There is no Kafka Connect cluster to size, patch, or monitor.

It handles three things automatically:

• Topic data. Records are copied from source topics to matching target topics, with configurable topic selection.
• Consumer group offsets. MSK Replicator syncs consumer group offsets to the target so applications can resume near their last committed position after a failover.
• Topic configuration. New topics and configuration changes on the source are mirrored to the target, so the two clusters stay in step.

A detail that matters for DR: MSK Replicator keeps topic names identical on the target by default. Unlike MirrorMaker 2, which prefixes remote topics with the source alias, MSK Replicator uses identity replication. Your consumers subscribe to the same topic name in the DR region — no rename logic in the failover path.

MSK Replicator supports both cross-region and same-region replication, and it works across AWS accounts. Pricing is usage-based: you pay for the volume of data MSK Replicator processes, plus standard AWS cross-region data transfer for cross-region setups. Check the current AWS MSK pricing page for exact rates before you size a deployment.

MSK Replicator vs MirrorMaker 2 — when to use which

Both tools do asynchronous cross-cluster replication. The difference is who operates the machinery and how much control you get.

MSK Replicator is the managed path. AWS runs the replication compute and networking; you configure and monitor. MirrorMaker 2 (MM2) ships with Apache Kafka, runs on the Connect framework, and gives you full control of every setting — at the cost of running and scaling that infrastructure yourself.

Dimension	MSK Replicator	MirrorMaker 2
Operating model	Fully managed by AWS	Self-managed on Kafka Connect
Cloud scope	Amazon MSK only	Any Kafka, any cloud, on-prem
Setup effort	Low — console or CLI	Higher — deploy and tune Connect
Topic naming	Identity (same names)	Prefixed by default
Offset sync	Built in	Via MirrorCheckpointConnector
Configurability	Moderate	Extensive
Cost driver	Per GB processed + transfer	Compute you run + transfer
Best for	AWS-native DR, small teams	Multi-cloud, cost at scale, control

The decision usually comes down to two questions. Are both clusters on Amazon MSK? If not, MSK Replicator is off the table and MM2 (or another tool) is your answer. If they are, do you value managed simplicity over control and cost? Pick MSK Replicator when you want fewer moving parts, and MM2 when you need to tune throughput, run across clouds, or minimize spend on high-volume streams.

For a wider view of your replication options, see Kafka replication across data centers, which walks through stretched clusters versus asynchronous cross-DC replication and the MM2 configuration in detail.

Setting up MSK Replicator for cross-region DR

A cross-region DR setup with MSK Replicator has four moving parts: two clusters, an IAM role, and the Replicator itself.

Prerequisites.

• A source MSK cluster in your primary region and a target MSK cluster in your DR region. Both must have multi-VPC private connectivity enabled and IAM access control turned on.
• The target cluster sized to hold the replicated workload. For DR it can run smaller than the primary until you fail over.
• An IAM service execution role that MSK Replicator assumes to read from the source and write to the target.

Step-by-step.

1. Create the clusters. Provision the primary and DR clusters with IAM access control. Keep a replication factor of 3 with min.insync.replicas=2 on both, so each cluster survives broker loss independently.
2. Create the Replicator. In the MSK console or with the AWS CLI (aws kafka create-replicator), specify the source and target cluster ARNs, the target region, and the service execution role.
3. Define topic selection. Use topic include and exclude patterns to replicate only the topics that matter for DR. Replicating everything wastes money on data you would never restore.
4. Confirm offset sync. Enable consumer group offset replication and set the group patterns for the applications that must resume in the DR region.
5. Set topic auto-creation. Let MSK Replicator create target topics so new source topics appear in the DR region without manual intervention.

IAM and security. The service execution role needs permissions to describe and read from the source cluster, and to describe, create topics on, and write to the target cluster, plus the kafka-cluster IAM actions for both. Scope the policy to the two cluster ARNs — do not grant account-wide Kafka access.

Monitoring. MSK Replicator publishes CloudWatch metrics, including replication latency and message lag per topic. Create CloudWatch alarms on replication lag so you learn about a stalled Replicator before a failover, not during one. Lag is your live RPO signal: the further the target trails the source, the more data a sudden failover would lose.

Failover procedures with MSK Replicator

Replication keeps the DR cluster warm. Failover is the human-and-automation sequence that redirects traffic to it. Write it down and rehearse it before you need it.

1. Detect the failure. Health checks on the primary cluster and its region trigger the decision. Automate detection; do not wait for a human to notice.
2. Redirect producers. Point producers at the DR cluster's bootstrap servers. Because MSK Replicator preserves topic names, producers write to the same topics with no rename.
3. Redirect consumers. Move consumer applications to the DR bootstrap servers. Since offsets were synced, they resume near their last committed position rather than replaying from the beginning.
4. Verify offset sync. Confirm consumer groups picked up the replicated offsets. Offset sync is asynchronous, so expect a small window of possible reprocessing or gap — this is your RPO in practice.
5. Fail back carefully. Once the primary region recovers, reverse the flow: replicate from the DR cluster back to the primary, drain the delta, then cut traffic back over during a planned window.

The offset detail is where DR plans succeed or fail. MSK Replicator syncs offsets on a best-effort, asynchronous basis, so a hard outage can leave a small gap between what the source committed and what the target recorded. Decide in advance whether your applications tolerate at-least-once reprocessing at failover, because that is the behavior you get.

MSK Replicator best practices

• Replicate only critical topics. Cost scales with the volume MSK Replicator processes. Filter to the topics your DR plan actually needs.
• Alarm on replication lag. A CloudWatch alarm on lag is your early warning and your live RPO gauge. Treat sustained lag as an incident.
• Right-size the DR cluster. Run it smaller than the primary to save money, but load-test that it can absorb full production throughput once promoted.
• Test failover on a schedule. Run a real failover drill at least quarterly. Measure actual RTO and RPO and compare them to your targets — a plan you have not exercised is a guess.
• Keep runbooks outside the primary region. Recovery steps stored in a system that depends on the failed region are useless during the outage.

Where MSK Replicator ends and backup begins

MSK Replicator is a strong availability tool. It is not a backup, and treating it as one is the most expensive mistake in AWS Kafka DR.

Replication is faithful by design. If a producer bug writes malformed events for an hour, MSK Replicator copies every bad record to the DR cluster in milliseconds. If an operator deletes a topic, the deletion propagates to the target too. There is no rewind. A replicated copy of corrupt or deleted data recovers nothing.

Point-in-time backup solves the case replication cannot. OSO Kafka Backup writes a continuous, independent copy of your topics and consumer group offsets to object storage — Amazon S3 and S3-compatible stores, Azure Blob, GCS, or a filesystem — with Zstd or LZ4 compression and millisecond-precision restore. If a bad deploy corrupts a topic, you restore to the moment before it happened, which no replication tool can do. For the full argument, see Kafka backup strategies and the Kafka disaster recovery architecture guide.

The two are complementary. Run MSK Replicator for fast regional failover, and run continuous backup to S3 for the corruption, deletion, and compliance cases. A minimal backup config for an AWS deployment looks like this:

mode: backup
backup_id: "msk-prod-continuous"

kafka:
  bootstrap_servers:
    - b-1.msk-prod.abcde.c1.kafka.us-east-1.amazonaws.com:9098
    - b-2.msk-prod.abcde.c1.kafka.us-east-1.amazonaws.com:9098

storage:
  backend: s3
  bucket: kafka-msk-backups
  region: us-east-1
  compression: zstd

For the AWS-specific storage settings, see the S3 cloud setup guide and the full config reference. For a side-by-side of managed replication versus point-in-time backup, see OSO Kafka Backup vs MSK Replicator.

Conclusion

MSK Replicator makes cross-region Kafka DR on AWS accessible without the operational weight of running MirrorMaker 2. It replicates data, offsets, and topic configuration between MSK clusters, keeps topic names identical for clean failover, and scales without a Connect cluster to manage. Choose it when both clusters are on Amazon MSK and you value managed simplicity; choose MM2 when you need multi-cloud reach, deeper control, or lower cost at high volume.

But do not let managed replication lull you into thinking DR is solved. Replication protects against region loss; it does nothing for corruption, deletion, or the compliance mandate for an independent copy. Layer point-in-time backup underneath MSK Replicator, then test the whole failover on a schedule. When you are ready to add the backup half, the getting started guide has the exact steps for an AWS deployment.

Frequently asked questions

What is MSK Replicator?

MSK Replicator is a fully managed feature of Amazon MSK that replicates topic data, consumer group offsets, and topic configurations between MSK clusters. It supports cross-region and cross-account replication, and AWS runs the underlying compute and networking so you do not operate any replication infrastructure yourself.

How does MSK Replicator compare to MirrorMaker 2?

MSK Replicator is fully managed by AWS and only works between Amazon MSK clusters, with low setup effort and identity topic naming. MirrorMaker 2 is self-managed on Kafka Connect, works across any Kafka deployment and cloud, and offers more control at lower cost, but you run and scale the infrastructure. Choose MSK Replicator for AWS-native simplicity and MM2 for multi-cloud reach or cost at scale.

How much does MSK Replicator cost?

MSK Replicator uses usage-based pricing: you pay for the volume of data it processes, plus standard AWS cross-region data transfer charges for cross-region setups. Because cost scales with volume, replicate only the topics your DR plan needs and check the current AWS MSK pricing page for exact rates before sizing a deployment.

Can MSK Replicator replicate across AWS accounts?

Yes. MSK Replicator supports cross-account replication in addition to cross-region and same-region replication. You grant the service execution role the required IAM permissions on both the source and target cluster ARNs, scoped to those clusters rather than granting account-wide Kafka access.

Does MSK Replicator replace Kafka backup?

No. MSK Replicator provides availability by keeping a warm copy of your data in another region, but it faithfully copies deletions and corrupt records to the target and cannot restore to a point in time. For recoverability against corruption, accidental deletion, and compliance requirements, pair it with continuous point-in-time backup to object storage.