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 AWS disaster recovery architecture, see the AWS 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 and GCP dedicated clusters. Azure support is planned. 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. See Task Logs Replication SLA for details on the RPO guarantee.

​
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 via Environment Manager or directly on the Deployment
  • Task logs. Enable Task Logs Replication SLA for a guaranteed 15-minute RPO.
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.