Skip to main content

​
Set up DR on a new cluster

You can enable DR when creating a new dedicated cluster through the Astro UI. See Create a dedicated Astro cluster for configuration steps and field descriptions. After the cluster is created, complete the required steps after enabling DR before triggering a failover.
You can also create a DR-enabled cluster with the Astro API or the Astro Terraform provider. See Terraform support for DR.

​
Set up DR on an existing cluster

How you enable DR on an existing dedicated cluster depends on your cluster’s cloud provider. On Azure, enablement is self-service and requires no downtime. On AWS and GCP, Astronomer converts the cluster during a maintenance window that you request.
To enable DR on an existing AWS cluster, submit a support request through the Astro UI. Astronomer processes the request during your specified maintenance window.

​
Prerequisites

  • Organization Owner role with organization.clusters.update permission
  • A dedicated AWS cluster that is not already DR-enabled

​
Submit a DR enablement request

1

Open the support request form

You can open the form in two ways:
  • From the Disaster Recovery tab: In the Astro UI, go to Settings > Clusters (Organization Settings > Clusters in the legacy UI), select your cluster, open the Disaster Recovery tab, then click Enable Disaster Recovery.
  • From the support menu: In the Astro UI, open New Support Request and select Enable AWS Data Plane Disaster Recovery.
2

Configure the request

Complete the following fields:
  • Cluster: Select the AWS cluster to enable DR on. Only eligible clusters appear. The cluster must be an AWS dedicated cluster that isn’t already DR-enabled.
  • Failover Region: Select the AWS region for the secondary cluster.
  • DR VPC Subnet Range: (Optional) Specify a VPC subnet range for the secondary cluster. Leave blank to use the same range as the primary cluster.
  • DR Pod CIDR Range: (Optional) Specify a Pod CIDR range for the secondary cluster. Leave blank to use the same range as the primary cluster.
  • Task Logs Replication SLA: Guarantees a 15-minute recovery point objective (RPO) for task logs. Enabled by default. Additional charges apply. See Task Logs Replication SLA.
  • Maintenance Window: Select a date and time for the maintenance window. The date must be at least 5 days from today. Weekends are not available.
  • Additional Details: (Optional) Include any additional context or requirements.
  • CC Emails: (Optional) Add email addresses to copy on the support ticket.
3

Submit the request

Click Submit Support Request. Astronomer confirms the maintenance window and contacts you before beginning the conversion.
Running, scheduled, and event-triggered tasks are affected during the maintenance window. Tasks may fail and require a retry. Plan for 1-2 hours of downtime during the maintenance window.
The conversion runs in two phases:
  • Database migration: Migrates the metadata database. This phase requires no downtime.
  • Infrastructure switch: Enables cross-region replication. This phase requires approximately 1-2 hours of maintenance downtime.
Enabling DR incurs additional Astro credits. Secondary cluster resources and data replication incur ongoing charges based on your cluster configuration.

​
Disable DR

Disabling DR deprovisions the secondary cluster and deletes all compute and data stores in the secondary region. This stops data replication and can’t be undone without re-enabling DR.
You can disable DR only while the cluster is running from its primary region. If the cluster has failed over to the secondary region, Astro blocks the request until you fail back to the primary region. For the same reason, you can’t delete a cluster while it’s failed over.
The failover region and the DR subnet ranges can’t be changed after Astronomer creates the secondary cluster. If you disable DR and later re-enable it, the cluster reuses its original failover region and subnet ranges.
Disabling DR is also supported using the Astro API. On Azure, you can also disable DR with Terraform. See Terraform support for DR.

​
Prerequisites

  • Organization Owner role with organization.clusters.update permission

​
Disable DR on your cluster

1

Open the DR tab

In the Astro UI, go to Settings > Clusters (Organization Settings > Clusters in the legacy UI), select your DR-enabled cluster, and open the Disaster Recovery tab.
2

Disable DR

On the Disaster Recovery tab, click Disable. Alternatively, open the cluster’s actions menu (⋯) at the top right of the page and select Disable Disaster Recovery…. Enter the cluster name to confirm, then click Disable Disaster Recovery.
This action is irreversible without re-enabling DR. Ensure you no longer need cross-region failover capability before disabling DR.

​
Terraform support for DR

The Astro Terraform provider supports DR on the astro_cluster resource with the following attributes: On AWS and GCP, you can only enable DR when you create the cluster. On Azure, you can enable and disable DR on an existing cluster with Terraform. Disabling DR by setting is_dr_enabled to false works on any cloud provider. For Azure clusters, if you leave enable_replication_time_control unset, the provider enables the Task Logs Replication SLA only when region and dr_region are on the same continent. Setting it to true for regions on different continents fails when you run terraform plan. You can always set it to false. GCP clusters additionally require dr_pod_subnet_range, dr_service_subnet_range, and dr_service_peering_range. AWS clusters can optionally set dr_secondary_vpc_cidr.

​
Required steps after enabling DR

After Astronomer creates the secondary cluster, complete the following steps before triggering a failover:
  1. Networking and DNS: Configure all required networking and DNS customizations for the secondary cluster. See Networking considerations.
  2. imagePullSecrets: If your Deployments use Kubernetes Pod Operators (KPOs), configure imagePullSecrets on the secondary cluster. See Pull images from a private registry.
  3. Customer-managed workload identity: If your Deployments use customer-managed workload identities, configure the appropriate workload identity and update the trust relationships for the secondary cluster. See Workload identity.
  4. Dag logic: Update your Dag logic to handle the ASTRONOMER_IS_DR_ENV environment variable for secondary-specific connections or configurations. See Prepare Dags for disaster recovery.