> ## Documentation Index
> Fetch the complete documentation index at: https://astronomer.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Prepare for disaster recovery

## Networking considerations

Networking primitives and DR network requirements differ by cloud provider.

<Tabs>
  <Tab title="AWS">
    **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](/docs/astro/create-dedicated-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](/docs/astro/customer-managed-egress).
  </Tab>

  <Tab title="GCP">
    **DR CIDR ranges for the secondary cluster**

    GCP requires four network ranges for the secondary cluster: a DR VPC subnet range, DR Pod CIDR range, DR service subnet range, and DR service peering range. Each range is required and must not overlap with the corresponding range on the primary cluster. Unlike AWS, GCP does not default these ranges from the primary cluster. Configure them when you create the cluster or in the DR enablement request. See [Create a dedicated Astro cluster](/docs/astro/create-dedicated-cluster).

    **Region pairing**

    The secondary region must be compatible with the primary region, based on supported GCP dual-region pairings. For example, the region `us-east5` can pair only with `us-central1` or `us-east1`. The Astro UI shows only compatible secondary regions when you configure DR.

    **Networking and DNS**

    Unlike AWS, GCP networking connectivity isn't self-service. To configure networking for either the primary or secondary cluster, including VPC peering and DNS, contact [Astronomer support](https://support.astronomer.io).
  </Tab>
</Tabs>

## 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.

## 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](/docs/astro/create-dedicated-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](https://docs.astronomer.io/astro/api) or [Terraform](https://registry.terraform.io/providers/astronomer/astro/latest/docs).