Skip to content
Ask AI about this
Help improve this page

Redshift clusters should have Multi-AZ deployments enabled

A single-AZ Redshift cluster becomes completely unavailable if that Availability Zone experiences an outage. For production data warehouses that power dashboards, reports, or downstream pipelines, even a brief interruption can cascade into missed SLAs and stale analytics. Multi-AZ Redshift maintains a standby cluster in a second AZ with automatic failover, typically completing recovery in minutes rather than the hours required to restore from a snapshot.

The cost is real (roughly double the compute spend), but for workloads where query availability matters, the tradeoff is straightforward. If the cluster doesn't warrant that investment, document the exception rather than leaving it ambiguous.

Retrofit consideration

Enabling Multi-AZ on an existing single-AZ cluster triggers a modification that may cause a brief outage during the maintenance window. It also requires RA3 node types; clusters on DC2 or DS2 nodes must be migrated first, which involves a resize operation.

Implementation

Choose the approach that matches how you manage Terraform.

If you use terraform-aws-modules/redshift/aws, set the right module inputs for this control. You can later migrate to the compliance.tf module with minimal changes because it is compatible by design.

module "redshift" {
  source  = "terraform-aws-modules/redshift/aws"
  version = ">=7.0.0,<8.0.0"

  automated_snapshot_retention_period = 7
  cluster_identifier                  = "abc123"
  create_cloudwatch_log_group         = true
  database_name                       = "mydb"
  logging = {
    log_destination_type = "cloudwatch"
    log_exports          = ["connectionlog", "userlog", "useractivitylog"]
  }
  master_password_wo     = "change-me-in-production"
  master_username        = "admin"
  node_type              = "ra3.xlplus"
  number_of_nodes        = 2
  subnet_ids             = ["subnet-12345678", "subnet-12345678", "subnet-12345678"]
  vpc_id                 = "vpc-12345678"
  vpc_security_group_ids = ["sg-12345678"]

  multi_az = true
}

Use AWS provider resources directly. See docs for the resources involved: aws_redshift_cluster.

resource "aws_redshift_cluster" "this" {
  automated_snapshot_retention_period = 7
  cluster_identifier                  = "pofix-abc123"
  cluster_subnet_group_name           = "example-redshift-subnet-group"
  master_password                     = "ChangeMe123!"
  master_username                     = "admin"
  node_type                           = "ra3.large"
  number_of_nodes                     = 2
  skip_final_snapshot                 = true

  multi_az = true
}

What this control checks

The aws_redshift_cluster resource must have multi_az set to true. It fails when multi_az is omitted or false. One dependency worth flagging: Multi-AZ requires RA3 node types (ra3.xlplus, ra3.4xlarge, or ra3.16xlarge). Pairing multi_az = true with dc2.large or any DS2 type causes an API error at apply time, not plan time, so the failure won't surface until after Terraform attempts the create or modify.

Common pitfalls

  • RA3 node type requirement

    Multi-AZ is only supported on RA3 node types. Setting multi_az = true with dc2.large or any DS2 variant will be accepted at plan time and rejected at apply time with an API error. This means a failed deployment, not a Terraform validation warning. Check node_type compatibility before enabling.

  • Cost doubles with Multi-AZ

    Enabling multi_az = true provisions a standby cluster in a second AZ, effectively doubling compute costs. A 3-node ra3.4xlarge cluster at on-demand pricing goes from roughly $9,700/month to $19,400/month. Teams sometimes enable it in dev or staging to pass controls and then get surprised by the bill.

  • Region and AZ availability

    Multi-AZ Redshift is not available in every AWS region. Attempting to enable it in an unsupported region fails at apply time. Check the Redshift documentation for current regional support before codifying multi_az = true in shared modules.

  • Snapshot restore does not inherit Multi-AZ

    Restoring from a snapshot via snapshot_identifier does not carry over the source cluster's Multi-AZ setting. The multi_az argument must be explicitly set to true on the restored aws_redshift_cluster resource, or the cluster comes back up single-AZ.

Audit evidence

Config rule evaluation results showing clusters as COMPLIANT for the Multi-AZ check, or equivalent Security Hub findings, are the primary evidence. The Redshift console cluster details page shows Multi-AZ status directly. For programmatic collection, aws redshift describe-clusters returns the MultiAZ field (boolean) for each cluster and can be scripted across accounts and regions.

Supporting documentation should include exception records for any clusters intentionally left in single-AZ mode, with business justification and risk acceptance sign-off.

Framework-specific interpretation

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: redshift_cluster_multiple_az_enabled

  • AWS Config Managed Rule: REDSHIFT_CLUSTER_MULTI_AZ_ENABLED

  • Powerpipe Control: aws_compliance.control.redshift_cluster_multiple_az_enabled

  • Prowler Check: redshift_cluster_multi_az_enabled

  • AWS Security Hub Control: Redshift.18

Last reviewed: 2026-03-09