Redshift Version Upgrade Disabled: Why It Matters and How to Fix It

Amazon Redshift ships engine updates on a regular cadence. These updates carry security fixes, performance improvements, and bug patches. When a cluster has AllowVersionUpgrade set to false, AWS will not apply new major or minor versions automatically, even during your maintenance window. The cluster stays frozen on whatever version it had, indefinitely.

The redshift_noupgrade check looks at the AllowVersionUpgrade attribute on each cluster and raises a finding when it is disabled. It is a small setting, but it is the difference between a cluster that maintains itself and one that quietly rots.

---

What this check detects

Every Redshift cluster has a boolean attribute called AllowVersionUpgrade. When it is true (the default), Amazon Redshift can deploy new engine versions to your cluster during the next maintenance window. When it is false, those upgrades are blocked.

You can confirm the current state for any cluster with a single API call:

aws redshift describe-clusters \
  --cluster-identifier my-cluster \
  --query 'Clusters[0].AllowVersionUpgrade'

A response of false is what this check fires on.

---

Why it matters

Skipping version upgrades feels safe in the short term. You avoid surprise behavior changes, and nothing breaks today. The cost shows up later, and it compounds.

You miss security patches

Engine updates frequently include fixes for vulnerabilities in the database software itself. A cluster stuck three or four versions behind is a cluster carrying every unpatched issue from those intervening releases. For a data warehouse that often holds your most sensitive aggregated data, customer records, financial figures, behavioral analytics, that is exactly where you do not want known gaps sitting open.

Drift makes the eventual upgrade harder

The longer a cluster lags, the bigger the version jump when you finally upgrade. Small incremental updates are low-risk. A single leap across many versions is where compatibility surprises and query plan regressions tend to bite. Disabling auto-upgrade trades many small, boring updates for one large, scary one.

Compliance and audit findings

Frameworks like CIS, SOC 2, and PCI DSS expect systems to be kept current with vendor patches. An auditor who finds a production warehouse pinned to an end-of-support engine version will write it up. "We turned upgrades off and forgot" is not a control that passes review.

---

How to fix it

Re-enabling automatic version upgrades is a non-destructive change. It does not trigger an immediate upgrade, it just allows future ones to proceed during your maintenance window.

Option 1: AWS CLI

aws redshift modify-cluster \
  --cluster-identifier my-cluster \
  --allow-version-upgrade

Verify the change took effect:

aws redshift describe-clusters \
  --cluster-identifier my-cluster \
  --query 'Clusters[0].AllowVersionUpgrade'

You should now see true.

Option 2: AWS Console

1. Open the Amazon Redshift console.
2. Go to Clusters and select the affected cluster.
3. Choose Actions, then Modify.
4. Under Maintenance, enable Allow version upgrade.
5. Save the changes.

Option 3: Terraform

If you manage Redshift through Terraform, set allow_version_upgrade explicitly so the setting cannot drift:

resource "aws_redshift_cluster" "warehouse" {
  cluster_identifier  = "my-cluster"
  node_type           = "ra3.xlplus"
  number_of_nodes     = 2
  database_name       = "analytics"
  master_username     = "admin"

  allow_version_upgrade        = true
  preferred_maintenance_window = "sun:06:00-sun:06:30"
}

Fixing many clusters at once

If you have several clusters flagged, you can loop over them rather than fixing each by hand:

for cluster in $(aws redshift describe-clusters \
  --query 'Clusters[?AllowVersionUpgrade==`false`].ClusterIdentifier' \
  --output text); do
  echo "Enabling version upgrade for $cluster"
  aws redshift modify-cluster \
    --cluster-identifier "$cluster" \
    --allow-version-upgrade
done

---

How to prevent it from happening again

Fixing the clusters you have today is half the job. The other half is making sure the setting never gets flipped back and stays flipped off.

Enforce it in your IaC

Always declare allow_version_upgrade = true explicitly in Terraform, CloudFormation, or the CDK. Relying on the default is fragile because a future engineer copying an old module, or importing a hand-built cluster, can introduce false without anyone noticing.

Add a policy-as-code gate in CI

Catch misconfigured clusters before they reach AWS. With Checkov scanning your Terraform plan, you can fail the build on any cluster that disables upgrades. A custom check looks like this:

metadata:
  id: "CKV_REDSHIFT_UPGRADE"
  name: "Redshift clusters must allow automatic version upgrades"
  category: "GENERAL_SECURITY"
definition:
  cond_type: attribute
  resource_types:
    - aws_redshift_cluster
  attribute: allow_version_upgrade
  operator: equals
  value: true

Wire that into your pull request pipeline so any plan that ships a non-upgradable cluster blocks the merge.

Detect drift continuously

IaC gates only protect resources that go through IaC. Console changes, emergency hotfixes, and clusters created before you adopted Terraform all slip past. Continuous scanning with Lensix catches a cluster that gets modified out of band, and surfaces the redshift_noupgrade finding so you can correct it before an auditor does.

---

Best practices

• Leave automatic upgrades on by default. Treat disabling them as an exception that needs a documented reason and an expiry date, not a permanent state.
• Own your maintenance window. Choose a quiet period that fits your workload, and make sure downstream jobs tolerate the brief reboot that some upgrades require.
• Test major version changes in a clone. Restore a snapshot into a staging cluster on the new version and validate your heaviest queries before a major release reaches production.
• Snapshot before maintenance windows. Automated snapshots give you a clean rollback point if an upgrade surfaces an unexpected regression.
• Track version coverage across the fleet. Report on which clusters run which versions so a single lagging cluster does not hide in a large estate.

Staying current is cheaper than catching up. A cluster that upgrades a little at a time is boring, and boring is exactly what you want from infrastructure that holds your data.

Re-enabling AllowVersionUpgrade is one of the lowest-effort, highest-leverage hygiene fixes available for Redshift. It costs nothing, risks almost nothing, and keeps your warehouse patched on a schedule you control. Turn it on, enforce it in code, and let Lensix tell you the moment something drifts.