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.
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.
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.
Astro automatically sets the ASTRONOMER_IS_DR_ENV environment variable on all Deployments in a DR cluster pair:
ASTRONOMER_IS_DR_ENV=TrueUse 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.