Redshift Cluster Not Encrypted: Why It Matters and How to Fix It

Amazon Redshift is where a lot of organizations end up putting their most sensitive aggregated data: customer records, financial transactions, behavioral analytics, and everything joined together for reporting. That makes an unencrypted Redshift cluster one of the more consequential misconfigurations you can leave running. The redshift_unencrypted check looks at every cluster in your account and reports any that do not have encryption at rest enabled.

---

What this check detects

The check inspects each Redshift cluster and reads the Encrypted property. When that value is false, the cluster's data blocks, automated snapshots, and metadata are written to disk in plaintext. Lensix marks the cluster as failing.

Encryption at rest in Redshift protects the data stored on the cluster's underlying disks and in any snapshots derived from it. When enabled, Redshift encrypts blocks using a hierarchy of keys, with the top of that hierarchy anchored in AWS KMS (or, for older clusters, HSM-backed keys).

---

Why it matters

Encryption at rest is the control that protects you when something else has already gone wrong. The scenarios it covers are not theoretical:

• Snapshot exposure. Redshift snapshots can be shared with other AWS accounts or, through misconfiguration, made accessible more broadly than intended. An unencrypted snapshot copied to an attacker-controlled account is fully readable. An encrypted one is useless without access to the KMS key.
• Physical and storage-layer compromise. Encryption at rest defends against scenarios where the storage substrate is accessed outside the normal data path. This is a baseline expectation in most threat models.
• Compliance failure. PCI DSS, HIPAA, SOC 2, and GDPR all expect sensitive data to be encrypted at rest. An unencrypted warehouse holding cardholder or health data is a direct finding in an audit, and Redshift frequently holds exactly that kind of aggregated data.
• Blast radius. A warehouse is the place where data from dozens of source systems converges. A single exposed cluster can leak the combined sensitive data of your entire organization, which is far worse than any one source database.

The cost of enabling encryption is negligible. The cost of explaining to a regulator why your central data warehouse was plaintext is not.

---

How to fix it

Here is the catch that trips people up: you cannot turn on encryption for an existing unencrypted cluster in place using a simple modify call for older cluster types, and even where modify is supported the operation is significant. The reliable path is to create an encrypted copy and cut over to it.

Option 1: Modify the cluster (RA3 and supported node types)

For modern node types, you can request encryption directly. AWS performs a background migration of the data into an encrypted state.

aws redshift modify-cluster \
  --cluster-identifier my-analytics-cluster \
  --encrypted \
  --kms-key-id alias/redshift-warehouse-key

Omit --kms-key-id to use the default AWS-managed key for Redshift, though a customer-managed key (CMK) is strongly preferred for control over rotation and access.

Option 2: Snapshot, copy with encryption, and restore

This works for any node type and gives you a clean, auditable cutover. The trade-off is that you create a new cluster, so the endpoint changes and you need to update clients.

1. Create a manual snapshot of the unencrypted cluster.

aws redshift create-cluster-snapshot \
  --snapshot-identifier my-cluster-pre-encryption \
  --cluster-identifier my-analytics-cluster

2. Copy the snapshot, attaching a KMS key to produce an encrypted copy.

aws redshift copy-cluster-snapshot \
  --source-snapshot-identifier my-cluster-pre-encryption \
  --target-snapshot-identifier my-cluster-encrypted \
  --manual-snapshot-retention-period 7

When restoring from this snapshot, you specify the KMS key. Restore into a new encrypted cluster:

aws redshift restore-from-cluster-snapshot \
  --cluster-identifier my-analytics-cluster-enc \
  --snapshot-identifier my-cluster-pre-encryption \
  --kms-key-id alias/redshift-warehouse-key \
  --node-type ra3.4xlarge \
  --number-of-nodes 2

3. Validate data, row counts, and query behavior against the new cluster.
4. Cut over client connections to the new endpoint.
5. Decommission the old unencrypted cluster.

Confirm encryption is on

aws redshift describe-clusters \
  --cluster-identifier my-analytics-cluster-enc \
  --query 'Clusters[0].{Encrypted:Encrypted,KmsKeyId:KmsKeyId}'

---

How to prevent it from happening again

Fixing one cluster is easy. Making sure the next one is never created unencrypted is the part that actually moves your security posture. Bake encryption into the provisioning layer.

Terraform

Set encrypted = true and pin a CMK so every cluster is encrypted by default:

resource "aws_redshift_cluster" "warehouse" {
  cluster_identifier = "analytics-prod"
  node_type          = "ra3.4xlarge"
  number_of_nodes    = 2

  encrypted  = true
  kms_key_id = aws_kms_key.redshift.arn

  # other config...
}

Block unencrypted clusters with policy-as-code

Add a guardrail in CI so a pull request introducing an unencrypted cluster fails before merge. With Checkov the relevant rule is CKV_AWS_64:

checkov -d . --check CKV_AWS_64

Or write an OPA / Conftest policy against your plan output:

package terraform.redshift

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_redshift_cluster"
  resource.change.after.encrypted == false
  msg := sprintf("Redshift cluster %v must be encrypted at rest", [resource.address])
}

Service Control Policy

For organization-wide enforcement, deny the creation of unencrypted clusters at the account boundary:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedRedshift",
      "Effect": "Deny",
      "Action": "redshift:CreateCluster",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "redshift:Encrypted": "false"
        }
      }
    }
  ]
}

---

Best practices

• Use a customer-managed KMS key, not the default. A CMK lets you control key rotation, scope key usage with policies, and revoke access if a key is ever suspected of compromise. The AWS-managed key gives you none of that flexibility.
• Enable automatic key rotation on the CMK so the backing key material rotates annually without manual effort.
• Encrypt snapshots and cross-region copies. When you copy snapshots to another region for disaster recovery, configure a KMS key in the destination region so the copies stay encrypted.
• Require SSL for connections. Set the require_ssl parameter in the cluster parameter group so data in transit is protected alongside data at rest.
• Restrict KMS key access. Encryption only helps if access to the key is tightly controlled. Limit which roles can call kms:Decrypt on the Redshift key, and log that usage with CloudTrail.
• Audit snapshot sharing. Review which accounts your snapshots are shared with. An encrypted snapshot shared with an external account still requires the recipient to have key access, which is exactly the safety net you want.

Encryption at rest on Redshift is one of those controls with a very high security payoff and a very low operational cost once it is in place. The effort is almost entirely in the one-time migration of existing unencrypted clusters. After that, a default in your IaC and a deny rule in CI mean the problem never comes back.