Skip to main content
The Astro Data Plane is designed to withstand in-region Availability Zone (AZ) degradations and outages as described in Resilience. For full region outages on dedicated clusters, Astro supports self-service cross-region disaster recovery (DR). For a detailed overview of Astro’s disaster recovery architecture, see the disaster recovery whitepaper in the Astronomer Trust Center.

​
Cross-region disaster recovery

Cross-region disaster recovery requires the Enterprise Business Critical tier. It is generally available for AWS, Azure, and GCP dedicated clusters.
Cross-region DR lets you configure a pair of dedicated clusters, a primary and a secondary, in two regions of the same cloud provider. The secondary cluster stays continuously synchronized with the primary so you can fail over with minimal downtime and data loss. After failover, Astro automatically enables synchronization in the reverse direction, keeping the original primary ready for failback. When the primary region recovers, you can fail back with a single click.

​
How disaster recovery works

  • The primary cluster runs all Deployments in Region A.
  • A multi-region database replicates Deployment metadata to the secondary cluster in Region B.
  • Multi-region object storage copies task logs to the secondary cluster.
  • User-deployed images are replicated to the secondary cluster.
  • On failover, the secondary cluster is promoted to active. All Deployments, configuration, environment variables, connections, and Airflow variables transfer automatically.
  • Clusters and Deployments retain their IDs, names, namespaces, and system-managed configuration after failover. All hostnames — including the Airflow UI, Airflow API, and Remote Execution API URLs — are updated to point to the secondary cluster and remain the same.
  • For Deployments that use Remote Execution, only the Astro-managed orchestration plane fails over. The execution plane runs in your own infrastructure and isn’t part of Astro’s region failover, but your Remote Execution Agents reconnect to the promoted secondary cluster automatically. See Remote Execution in DR pairs.

​
RTO and RPO

The following table defines the recovery time objective (RTO) and recovery point objective (RPO) for DR clusters. Targets are benchmarked with 80+ Deployments and 1,250+ concurrent task runs. The RPO target covers task logs and depends on the Task Logs Replication SLA, which is enabled by default. See Task Logs Replication SLA. Deployment metadata replicates continuously to the secondary cluster rather than on a fixed schedule. On Azure, you can monitor the current database and object storage replication lag on the cluster’s Disaster Recovery tab. See Trigger failover.

​
Data loss during failover and failback

Failover and failback have different data loss characteristics:
  • Failover: Astro promotes the secondary metadata database while the primary region might be unreachable. You can lose up to the amount of data represented by the current replication lag.
  • Failback: Astro stops writes to the secondary cluster before promoting the original primary, which guarantees zero data loss.
Because of this difference, review how far replication has caught up before you trigger a failover, especially when you are testing DR rather than responding to a real region outage. On Azure, the Disaster Recovery tab reports the current replication lag.

​
What gets failed over

The following items transfer to the secondary cluster automatically during failover:
  • Deployments and data pipelines
  • Dag run history, task instance metadata, and XComs
  • Deployment configuration
  • Environment variables, connections, Airflow variables, and metrics exports — whether configured with Environment Manager or directly on the Deployment
  • Task logs. The Task Logs Replication SLA guarantees a 15-minute RPO and is enabled by default.
  • Deployment images
The following items do not transfer automatically and require manual steps after configuring the secondary cluster:
  • Networking and DNS configuration. Configure these using self-service networking features, or work with Astronomer support. See Networking considerations.
  • imagePullSecrets for Kubernetes Pod Operators (KPOs)
  • Customer-managed workload identities. You must configure the workload identity and trust relationships for the secondary cluster separately. See Workload identity.
  • Customer-managed network routing on the secondary cluster, such as AWS Transit Gateway
  • Remote Execution Agents and their supporting infrastructure. Agents run in your own environment and aren’t part of Astro’s region failover. See Remote Execution in DR pairs.