Server replication, not Kafka backup

What AWS Elastic Disaster Recovery does well — and at what layer​

Teams evaluating AWS Elastic Disaster Recovery for Kafka usually already trust it for server DR. The short answer: AWS DRS replicates the machines Kafka runs on. It does not back up the data Kafka holds.

As server DR, the service is genuinely strong. The successor to CloudEndure, it installs a replication agent on each source server — on-premises, in another cloud, or on EC2 — and streams block-level changes continuously into a staging area of minimal compute and affordable storage. RPOs are typically sub-second. Recovery launches full EC2 instances in minutes, typically five to twenty. Drills run without touching production, and failback reverses replication once the primary site returns.

That model is also cheap for what it does. You pay per replicating source server plus staging-area resources, instead of running a warm standby fleet. For lift-and-shift applications and server-hosted databases, it is one of the lowest-cost pilot-light DR options on AWS.

OSO Kafka Backup works at the data layer instead. It connects to any Kafka cluster as a standard client and writes topic records, consumer group offsets, and topic configuration to object storage (S3, Azure Blob, GCS) or local disk. Restores are offset-consistent, work across clusters, and stop at a precise millisecond — the failure modes covered in the disaster recovery use cases.

AWS Elastic Disaster Recovery and Kafka: what server snapshots cannot see​

AWS DRS does offer point-in-time recovery — within its window and at its layer. Each snapshot is full-server block state. The default schedule keeps one snapshot every ten minutes for the last hour, hourly for the last day, then daily for seven days. Rewinding a broker to a snapshot rewinds every topic, every partition, and every consumer offset on that machine together.

That scope is the problem for Kafka data. A poison message discovered after the snapshot window has rolled past is unrecoverable. A single corrupted topic cannot be restored without dragging the whole broker back in time. And continuous replication is faithful by design: a bad deploy that writes garbage, or an accidental topic deletion, reaches the staging area in seconds. The replication-is-not-backup distinction applies here exactly as it does to MirrorMaker.

There is a consistency wrinkle replication cannot fix. Each agent replicates its own server, so a multi-broker cluster recovers from snapshots that are close together but not coordinated. Kafka usually heals the difference, yet the recovered cluster state is whatever was on disk — not a clean, offset-consistent view of your topics. OSO Kafka Backup stores original offsets with each record and restores consumer group positions alongside the data, so applications resume where they left off, on any target cluster.

The structural gap is managed Kafka. Amazon MSK, Confluent Cloud, and Aiven expose no servers to install the replication agent on, so AWS DRS has nothing to protect. A client-level backup tool works against MSK and every other distribution the same way.

When to choose which​

Choose AWS Elastic Disaster Recovery when the job is infrastructure survival: recovering self-managed servers into AWS after a site failure, with sub-second RPOs, minutes of RTO, rehearsable drills, and pay-per-server pricing instead of a standby fleet.

Choose OSO Kafka Backup when the job is Kafka data: offset-consistent topic backups, millisecond point-in-time restore months after the fact, single-topic recovery, and coverage for managed services the DRS agent cannot reach. The RTO and RPO planning guide shows how the two objectives differ by failure mode.

Run both when Kafka matters to the business. AWS DRS brings the servers back; OSO Kafka Backup restores logically consistent topic data at any point in its retention. The same layer split appears in the EBS snapshots comparison for DIY volume snapshots and the Zerto comparison for journal-based replication.