Disaster Recovery and Failover on Confluent Cloud
A Disaster Recovery (DR) plan helps your organization quickly recover from regional outages and minimize downtime and data loss. In the public cloud, outages and downtime can cause businesses to lose considerable revenue or halt operations entirely. A solid DR strategy helps ensure business continuity.
If your business depends on Apache Kafka® to run mission-critical workloads or customer-facing applications, then you need a cross-region DR plan for your Kafka deployment. Disaster can take the form of a catastrophic hardware or software failure, power outage, denial-of-service attack, or any other event that causes degradation or failure of an entire cloud region. With a cross-region DR plan, when disaster strikes, your Kafka architecture continues to run in another region until service is restored.
Goal of disaster recovery
The goal of disaster recovery (DR) is to maintain an up-to-date replica of your primary cluster’s data and metadata on a separate DR cluster, so that producers and consumers can switch over with low downtime and minimal data loss when an outage occurs.
Recovery time objectives (RTOs) and recovery point objectives (RPOs)
Recovery Time Objective (RTO) is the maximum acceptable downtime during an outage. Recovery Point Objective (RPO) is the maximum acceptable data loss. Both metrics drive the design of your disaster recovery plan with Cluster Linking.
An RTO shows the difference between when the outage occurs and when your system is back up and running. An RPO measures the difference between the last message produced to the failed cluster and the last message replicated to the DR cluster.
Term |
Description |
|---|---|
Recovery Point Objective (RPO) |
RPO is the point in the data’s history that a failover must resume from. That is, how much data can be lost during a failure. To achieve low RPO, you can use asynchronous replication like Cluster Linking. To achieve zero RPO, you must use synchronous replication, which is not supported by Confluent Cloud. |
Recovery Time Objective (RTO) |
RTO is the amount of time that can elapse while a failover takes place. That is, how long a failover can take. To achieve low RTO, you must have seamless client failover. To achieve zero RTO, you must use an active/active setup. |
Region |
A synonym for a datacenter. |
Disaster Recovery (DR) |
Umbrella term that encompasses architecture, implementation, tooling, policies, and procedures that all allow an application to recover from a disaster or a full region failure. |
Event |
A single message produced to or consumed from Confluent Cloud or Confluent Platform. |
Millisecond (ms) |
1/1,000th of a second. |
Choose your DR deployment strategy
Before implementing Cluster Linking for DR, determine which deployment pattern fits your architecture, and aligns with your recovery point objective (RPO), recovery time objective (RTO), and application requirements.
Feature / Consideration |
Active-Passive (Automatic Failover) (Early Access) |
||
|---|---|---|---|
Primary Use Case |
Single active region; secondary acts as an automated warm standby for DR. |
Single active region; secondary acts as a manually managed warm standby. |
Both regions actively produce and consume traffic simultaneously. |
Failover Mechanism |
Managed Automatic Failover with a single global bootstrap URL. |
Manual failover execution using custom DNS updates, load balancers, or configuration changes. |
Manual failover or application-level client traffic redirection. |
Client Code Changes |
None (Clients use global bootstrap endpoint with auto-DNS resolution). |
Requires client application restarts, configuration updates, or custom discovery logic. |
Requires multi-cluster connection handling or client re-bootstrapping. |
Topic Architecture |
Primary topics mirrored to secondary ( |
Primary topics mirrored to secondary. |
Bidirectional topic replication across both clusters. |
Supported Automatic Failover Features |
Full automated one-click switchover, restore, and pairing orchestration. |
Not supported (uses standard Cluster Linking CLI/API). |
Automatic Failover features (global endpoint, one-click switchover) are not supported. |
Confluent Cloud supports two primary DR implementations:
A one-click solution that automatically switches all clients to the secondary cluster on demand. It enables a deployment to achieve a low RTO. The Automatic Failover Tutorial covers this workflow. Currently available only on active-passive deployments, this option is recommended for active-passive setups.
A manual solution that lets you manage switching your clients to the secondary cluster. The RTO that you can achieve depends on your own tooling and failover procedures. This solution is available on both active-passive and active-active deployments. These workflows are covered in Manual Switchover for Active-Active Deployments and Manual Switchover for Active-Passive Deployments.
With manual switchover, the RTO you can achieve with Cluster Linking depends on your tooling and failover procedures, because failing over your applications is your responsibility. There’s no set minimum or maximum RTO.
The RPO you can achieve with Cluster Linking is determined by the mirroring lag between the DR cluster and the primary cluster. Mirroring lag is exposed through the Metrics API, CLI, REST API, and Confluent Cloud Console.
For the list of clusters that support Cluster Linking, see supported cluster types.
Next steps and setup tutorials
After selecting your deployment pattern, proceed to the detailed prerequisites, setup steps, and failover runbook for your chosen strategy: