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’s enabled by default when you enable DR and adds pass-through cost — disable it for a longer RPO at lower cost. This setting affects only task logs; Deployment images and the metadata database always replicate within 15 minutes regardless. Each cloud provider implements the SLA with its own storage replication feature. Task logs replicate to the secondary region either way — the SLA only changes how fast that replication must complete: 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.