Skip to content
Ask AI about this
Help improve this page

Redshift clusters should have automatic upgrades to major versions enabled

Redshift major version upgrades can include security patches, performance improvements, and reliability fixes. Leaving a cluster on an older major version longer than intended is a common outcome when upgrades require manual intervention: change-freeze windows stack up, team bandwidth gets allocated elsewhere, and the upgrade quietly gets deferred.

Automatic upgrades apply during preferred_maintenance_window, so the brief unavailability is predictable and schedulable. This setting reduces that operational drag, but it does not replace a proper patch and vulnerability management process.

Implementation

Choose the approach that matches how you manage Terraform.

Use the compliance.tf module to enforce this control by default. See get started with compliance.tf.

module "redshift" {
  source  = "nistcsf.compliance.tf/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"]
}

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"]

  allow_version_upgrade = 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"
  skip_final_snapshot                 = true

  allow_version_upgrade = true
}

What this control checks

This control validates allow_version_upgrade on the aws_redshift_cluster resource. It accepts a boolean: true passes, false fails. The Terraform AWS provider defaults this argument to true, so omitting it also passes. A cluster fails only when allow_version_upgrade is explicitly set to false. No additional resources are required.

Common pitfalls

  • Explicit false overrides a safe default

    The Terraform default for allow_version_upgrade on aws_redshift_cluster is true. Teams sometimes copy older module templates that explicitly set allow_version_upgrade = false to prevent unexpected changes. Grep your modules for this value before assuming compliance.

  • Maintenance window misalignment causes perceived outages

    Disabling allow_version_upgrade reactively because upgrades overlap with peak query hours is the wrong fix. Upgrade timing is governed by preferred_maintenance_window. Set that to a low-traffic window and the disruption concern goes away.

  • Terraform import may not capture the setting

    After terraform import, allow_version_upgrade is read from the API, but only if you have declared it in your .tf file. If the argument is absent, subsequent plans will silently rely on the provider default. Declare it explicitly to avoid configuration drift.

Audit evidence

Auditors expect AWS Config rule evaluation results showing all Redshift clusters as compliant, or equivalent output from a CSPM tool such as Turbot Pipes. Supplementary evidence includes aws redshift describe-clusters output showing "AllowVersionUpgrade": true for each cluster across all active regions. Organizations using Config conformance packs can provide the rule's evaluation history as a timestamped compliance record covering continuous adherence, not just a point-in-time snapshot.

Framework-specific interpretation

NIST Cybersecurity Framework v2.0: PR.PS (Platform Security) covers protection of platform components, and keeping Redshift on a current major version is part of that. This setting reduces time spent on older engine releases with known issues and supports technology asset protection under the Protect function.

Tool mappings

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

  • Compliance.tf Control: redshift_cluster_automatic_upgrade_major_versions_enabled

  • AWS Config Managed Rule: REDSHIFT_CLUSTER_MAINTENANCESETTINGS_CHECK

  • Checkov Check: CKV_AWS_141

  • Powerpipe Control: aws_compliance.control.redshift_cluster_automatic_upgrade_major_versions_enabled

  • Prowler Check: redshift_cluster_automatic_upgrades

  • AWS Security Hub Control: Redshift.6

Last reviewed: 2026-03-09