The short answer
Designing disaster recovery (DR) for an enterprise Redshift warehouse requires balancing Recovery Point Objective (RPO) and Recovery Time Objective (RTO) against operational cost.
Primary Region (us-east-1) Secondary DR Region (us-west-2)
+------------------------+ +------------------------+
| Redshift Cluster | | S3 Snapshot Copy |
| Active Production | | Automated replica |
+------------------------+ +------------------------+
| |
v automated snapshot copy v CloudFormation / Lambda
+------------------------+ +------------------------+
| S3 Local Snapshots | --------------> | Standby Cluster |
| Hourly automated snaps | AWS WAN | Restored on DR trigger |
+------------------------+ +------------------------+Snapshot replication (Cold Standby)
The standard, cost-effective DR approach uses automated cross-region snapshot copying.
- Automated snapshots: Configure Redshift to take snapshots every 1 or 2 hours with an automated snapshot copy rule targeting a secondary disaster recovery region (for example,
us-west-2). - KMS key grants: Ensure the snapshot copy rule uses an AWS KMS key in the target region with cross-account or cross-region decryption grants.
- Automated recovery runbook: Deploy an AWS Lambda function triggered by an AWS Step Functions state machine or health check alarm. If
us-east-1experiences a catastrophic regional outage, the automation creates a new Redshift cluster from the latest replicated snapshot inus-west-2and updates Route 53 DNS records.
This provides an RPO of 1 to 2 hours (the snapshot frequency) and an RTO of 30 to 45 minutes (the time required to spin up nodes and hydrate the NVMe cache from RMS).
Multi-region live Data Sharing (Warm Standby)
For mission-critical enterprises requiring near-zero RTO, deploy an active standby cluster in the secondary region. Using cross-region Redshift Data Sharing, the secondary cluster queries data directly, or ingestion pipelines replicate raw events to both regions simultaneously.