Skip to main content

​
Networking considerations

Networking primitives and DR network requirements differ by cloud provider.
VPC CIDR for the secondary clusterBy default, the secondary cluster uses the same VPC subnet range and Pod CIDR range as the primary cluster. Astronomer recommends configuring a different CIDR range for the secondary cluster to avoid IP conflicts when both clusters are connected to shared networks. You can set a different CIDR range for the secondary cluster when you create the primary cluster. See Create a dedicated Astro cluster.VPC peeringSelf-service VPC peering is supported for both clusters. After Astronomer creates the secondary cluster, you must create all VPC peering connections and routes for the secondary cluster. Astronomer does not automatically initiate any peerings after creating the secondary cluster.Private Network EgressIf Private Network Egress (PNE) is enabled on the primary cluster, Astronomer enables it on the secondary cluster as well.Customer Managed Egress and Transit GatewayCustomer Managed Egress (CME) is self-service and must be configured separately for both the primary and secondary clusters. See Customer Managed Egress.

​
Workload identity

Astro-managed workload identity If you use Astro-managed workload identity, the same workload identity is used in both the primary and secondary regions. Customer-managed workload identity If you use customer-managed workload identity, the secondary cluster defaults to the Astro-managed workload identity. You must configure the workload identity and IAM policy binding for the secondary cluster separately. You can only do this after Astronomer creates the secondary cluster, because the identity provider information for the secondary cluster is not available until then. You can do this in the Deployment details Advanced section. Azure federated credentials On Azure, workload identity federation is scoped to a cluster’s OIDC issuer. The secondary cluster therefore requires its own federated credentials, even when you reuse the managed identity from your primary cluster. Selecting Use same identity as primary cluster does not remove this step. For each Deployment that uses a customer-managed workload identity, open the Deployment details Advanced section and run the az identity federated-credential create commands that the Astro UI generates for the secondary cluster. The commands create one federated credential for each Airflow component — the scheduler, triggerer, worker, API server, and Dag processor — and one for Kubernetes Pod Operators, each against the secondary cluster’s OIDC issuer URL.

​
Task Logs Replication SLA

The Task Logs Replication SLA guarantees a 15-minute recovery point objective (RPO) for task logs. It is enabled by default when you enable DR and incurs additional pass-through costs. Disable it to accept a longer RPO for task logs at a lower cost. Deployment images always replicate with the 15-minute SLA, whether or not you enable this option. The setting applies only to task logs. Each cloud provider implements the SLA with its own storage replication feature: AWS uses S3 Replication Time Control, Azure uses Blob Storage priority replication, and GCP uses Cloud Storage turbo replication. You can set the Task Logs Replication SLA when you create a new DR cluster pair, or when you enable DR on an existing cluster. See Create a dedicated Astro cluster.

​
Azure region requirements

Azure supports the 15-minute SLA only when the primary and failover regions are on the same continent. If you select regions on different continents, the Astro UI disables the option and explains that it requires a failover region on the same continent as the primary region. The Astro API rejects the request, and Terraform reports an error during terraform plan. The following table groups the supported Azure dedicated cluster regions by continent: uaenorth and southafricanorth are the only supported regions on their respective continents, so DR cluster pairs that use either region cannot enable the Task Logs Replication SLA. On Azure, the replication lag metrics on a cluster’s Disaster Recovery tab are available only when the Task Logs Replication SLA is enabled.

​
Prepare Dags for disaster recovery

Astro automatically sets the ASTRONOMER_IS_DR_ENV environment variable on all Deployments in a DR cluster pair:
  • Secondary cluster: ASTRONOMER_IS_DR_ENV=True
  • Primary cluster: The variable is not set.
Use this variable in your Dag code to branch logic based on whether a Deployment is running on the secondary cluster. For example, to switch connections, change resource configurations, or skip certain tasks during a DR event. Astronomer recommends updating your Dags to handle this variable before triggering a failover. Alternatively, you can update relevant configuration such as connections and environment variables after failover using the Astro API or Terraform.