Backups answer the question "can we get the data back?" Availability answers a different one: "what happens to the warehouse at 2am when an Availability Zone degrades, and who notices?" Most Redshift environments we review have a solid snapshot story — cross-Region copies, retention, a documented restore — and no availability story at all. The implicit plan is restore a snapshot into another AZ and tell everyone it will be a few hours.
That may be a perfectly defensible plan. It should just be a decision, not an accident. This guide covers the three availability mechanisms Amazon Redshift actually offers, what each is worth in RPO and RTO terms, how to turn them on, and how to rehearse a failover.
The three options, honestly
| Mechanism | Applies to | RPO | RTO | Cost |
|---|---|---|---|---|
| RA3 Multi-AZ | Provisioned RA3 clusters | Zero (shared managed storage) | Minutes, automatic, endpoint unchanged | ~2x compute: you pay for nodes in both AZs |
| Serverless cross-AZ recovery | Redshift Serverless workgroups | Zero | Minutes, automatic, managed by AWS | Included |
| Cluster relocation | Single-AZ provisioned RA3 | Zero | Tens of minutes, AWS-initiated or manual | Free |
| Snapshot restore | Everything, incl. DC2 | Up to your snapshot interval | Hours | Storage only |
Two things in that table matter more than the rest. First, because RA3 and Serverless separate compute from Redshift Managed Storage, which is itself replicated across AZs, none of the compute-level options lose committed data. Availability on Redshift is a compute-recovery problem, not a data-replication problem. Second, DC2 has none of this; if you are still on DC2 nodes, availability is one more reason to migrate off DC2.
RA3 Multi-AZ: what it actually is
A Multi-AZ RA3 cluster runs compute in two Availability Zones at once, both active, behind a single endpoint. It is not a warm standby you promote. Queries are served from both AZs, and if one becomes unavailable the cluster keeps serving from the other while AWS re-provisions capacity. Your JDBC string, your BI connections and your orchestration do not change.
The things teams are surprised by:
- You pay for both AZs. A Multi-AZ cluster sized at 8 RA3 nodes bills roughly like 16. Reserved Instance coverage applies, but budget for the doubling.
- Node count is per-AZ. Set the node count you need for the workload; Redshift provisions that many in each AZ.
- It is an RA3 feature and requires your cluster to be in a VPC with subnets in at least two AZs in the cluster subnet group.
- Failover is not instantaneous. In-flight queries during an AZ event are typically terminated and must be retried — your orchestration needs retry logic regardless of HA topology.
Enabling it on a new cluster:
aws redshift create-cluster \
--cluster-identifier analytics-prod \
--node-type ra3.4xlarge \
--number-of-nodes 4 \
--multi-az \
--cluster-subnet-group-name prod-redshift-subnets \
--master-username admin \
--manage-master-password \
--encrypted
Converting an existing single-AZ RA3 cluster:
aws redshift modify-cluster \
--cluster-identifier analytics-prod \
--multi-az
The conversion is an availability event in itself — schedule it in a maintenance window, not on a Monday morning. Verify afterwards:
aws redshift describe-clusters --cluster-identifier analytics-prod \
--query 'Clusters[0].{MultiAZ:MultiAZ,Status:ClusterStatus,AZ:AvailabilityZone,Secondary:ClusterNamespaceArn}'
In Terraform, this is a single argument on aws_redshift_cluster:
resource "aws_redshift_cluster" "analytics_prod" {
cluster_identifier = "analytics-prod"
node_type = "ra3.4xlarge"
number_of_nodes = 4
multi_az = true
cluster_subnet_group_name = aws_redshift_subnet_group.prod.name
encrypted = true
# ...
}
If you manage Serverless with Terraform instead, the namespace/workgroup pattern is in our Redshift Serverless as code walkthrough.
Redshift Serverless: availability you did not configure
Serverless workgroups are not single-AZ resources in the way a provisioned cluster is. Compute is managed by AWS across AZs, data lives in Redshift Managed Storage, and recovery from an AZ impairment is handled for you. There is no --multi-az flag because there is nothing for you to turn on.
What you do control:
- Subnet coverage. A workgroup requires subnets in at least three AZs (with enough free IP addresses). If your VPC only has subnets in two, create the third before you need it — a cramped subnet group is the most common reason recovery capacity cannot be placed.
- Base RPU and max RPU. After a recovery event the workgroup comes back at its configured capacity; if your base RPU is set low to save money, the first few minutes after recovery will be slow while it scales.
- Snapshots and recovery points. Serverless keeps automatic recovery points for 24 hours; anything longer-lived must be an explicit snapshot. That is a backup concern, covered in backup and disaster recovery, but it is the fallback when the failure is logical rather than infrastructural.
Check your subnet spread before you call it done:
aws redshift-serverless get-workgroup --workgroup-name analytics-prod \
--query 'workgroup.subnetIds' --output text | tr '\t' '\n' | \
xargs -n1 -I{} aws ec2 describe-subnets --subnet-ids {} \
--query 'Subnets[0].[SubnetId,AvailabilityZone,AvailableIpAddressCount]' --output text
Cluster relocation: the cheap middle option
If doubling your compute bill for Multi-AZ is not justifiable, single-AZ RA3 clusters support relocation: Redshift can move the cluster to another AZ in the same Region, keeping the same endpoint DNS name, without you restoring anything. AWS may initiate it during an AZ impairment, and you can trigger it yourself.
aws redshift modify-cluster \
--cluster-identifier analytics-prod \
--availability-zone-relocation
# Manual move
aws redshift modify-cluster \
--cluster-identifier analytics-prod \
--availability-zone us-east-1c
Caveats worth writing into the runbook: relocation requires RA3, requires that your cluster subnet group has subnets in the target AZ with free IPs, and is incompatible with clusters that have an Elastic IP or certain fixed-IP setups. Relocation takes tens of minutes and drops connections — it is an outage, just a much shorter one than a restore.
What HA does not protect you from
This is the part that justifies keeping the snapshot discipline:
- A bad deploy. A migration that drops the wrong column replicates perfectly to both AZs. Protect against this with the CI gate described in schema migrations.
- A bad load. A duplicated batch is instantly highly available. Load gates and data quality tests are the control.
- Region-level events. Multi-AZ is within one Region. Cross-Region protection is cross-Region snapshot copy, and for a warm standby, a second namespace restored on a schedule.
- Credential or account compromise. Covered by RBAC, Identity Center and separation of production accounts, not by topology.
Rehearsing the failover
An untested HA setup is a claim, not a capability. A quarterly 60-minute exercise is enough:
- Announce a window and pick a representative workload: a nightly ELT batch and a handful of BI dashboards.
- For single-AZ RA3, trigger a relocation to another AZ with
modify-cluster --availability-zone. For Multi-AZ, you cannot force an AZ outage, so test the adjacent behaviours instead: reboot the cluster, or run a failover-style test by restarting your ELT during a maintenance event and confirming retry logic works. - Measure three numbers: time until the endpoint accepts connections again, time until a representative query returns within normal latency, and how many pipeline tasks failed permanently rather than retrying.
- Watch the alarms fire. If your CloudWatch alarms and on-call routing stayed silent through the event, the exercise found a real problem — see monitoring and alerting.
- Write down the deltas. Connection strings hard-coded to a node IP, a Lambda with a 30-second timeout and no retry, a BI service account whose connection pool never reconnects. These are the actual findings; the infrastructure almost always behaves.
Make retries non-negotiable on the client side. With the Redshift Data API, that is a state-machine retry; with JDBC, it is connection validation plus an application-level retry on transient errors. Idempotent loads — the MERGE patterns — are what make retrying safe.
Choosing
- Serverless — availability is included and adequate for most workloads; spend your attention on subnet coverage and base RPU instead.
- Provisioned RA3, tolerable downtime — single-AZ with relocation enabled and cross-Region snapshot copy. Free, and good for tens of minutes of RTO.
- Provisioned RA3, warehouse is in a revenue path or a customer-facing SLA — Multi-AZ, and budget the second AZ's compute from the start.
If you need an availability target written against a real workload — RPO, RTO, cost and a tested runbook rather than a diagram — that is the kind of engagement our Redshift Administration and Data Modeling & Architecture practices handle. Get in touch with your current topology and the downtime your business actually tolerates.