Prepare for disaster recovery

Networking considerations

VPC CIDR for the secondary cluster

By 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 peering

Self-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 Egress

If Private Network Egress (PNE) is enabled on the primary cluster, Astronomer enables it on the secondary cluster as well.

Customer Managed Egress and Transit Gateway

Customer 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 role name 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 role. You must configure the workload identity and trust policy for the secondary cluster separately. You can only do this after Astronomer creates the secondary cluster, because the OIDC provider information for the secondary cluster is not available until then. You can do this in the Deployment details Advanced section.

Task Logs Replication SLA

The Task Logs Replication SLA is an optional feature that guarantees a 15-minute RPO for task logs. Enabling this feature incurs additional pass-through costs.

You can enable the Task Logs Replication SLA when you create a new DR cluster pair, or after creating. See Create a dedicated Astro cluster.

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.