Skip to content
Ask AI about this
Help improve this page

Redshift clusters should be encrypted with CMK

AWS-managed keys give you encryption at rest but no control over key rotation schedules, key policies, or cross-account access grants. With a customer-managed CMK, you own the key lifecycle: you decide who can use it, when it rotates, and whether to disable or delete it. If a cluster is compromised or decommissioned, revoking the CMK immediately renders the data unreadable.

Redshift clusters often hold sensitive analytical data aggregated from multiple sources. A CMK also enables CloudTrail logging of every Decrypt and GenerateDataKey call against that key, giving you a clear audit trail of data access patterns that AWS-managed keys obscure.

Retrofit consideration

Enabling encryption or changing the KMS key on an existing unencrypted Redshift cluster requires a cluster migration. AWS creates a new encrypted cluster, copies data, and swaps endpoints. This causes downtime proportional to cluster size and cannot be done in place.

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

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

  kms_key_id = "arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012"
}

What this control checks

In the aws_redshift_cluster resource, set encrypted = true and kms_key_id to the ARN of a customer-managed KMS key (created via aws_kms_key). A cluster fails if encrypted is false; if encrypted is true but kms_key_id is omitted (which defaults to the AWS-managed aws/redshift key); or if kms_key_id references an AWS-managed key ARN. The referenced key must have is_enabled = true and a key policy granting the Redshift service principal usage permissions.

Common pitfalls

  • Omitting kms_key_id still passes encrypted check

    Omitting kms_key_id while setting encrypted = true silently encrypts the cluster with the AWS-managed aws/redshift key, not a CMK. This passes a generic encryption check but fails the CMK-specific control. Always wire kms_key_id explicitly to an aws_kms_key resource ARN.

  • Snapshot encryption inheritance

    Snapshots inherit the CMK from their source cluster. Delete or disable that key and those snapshots become permanently unrestorable. Set deletion_window_in_days to at least 30 and put a CloudWatch alarm on key deletion events before you're in a position where you need them.

  • Cross-region snapshot copy requires separate CMK grant

    If you use aws_redshift_snapshot_copy_grant for cross-region DR, the destination region needs its own CMK and the grant must reference it. The source CMK ARN will not work in another region.

  • Retrofit requires cluster migration with downtime

    Terraform will destroy and recreate the cluster if encrypted changes from false to true, which means data loss if you haven't handled the migration manually first. AWS has no in-place toggle: the process requires an encrypted snapshot copy, a restore to a new cluster, and a connection cutover. Plan the migration outside of Terraform before touching this attribute.

Audit evidence

AWS Config rule evaluations should show each cluster as compliant, confirming both encryption and CMK usage. The aws redshift describe-clusters output should show Encrypted: true and a KmsKeyId containing a customer-managed key ARN (alias not starting with aws/). Confirm KeyManager: CUSTOMER via aws kms describe-key against that ARN.

CloudTrail logs for kms:Decrypt and kms:GenerateDataKey calls from the Redshift service against that key ARN provide ongoing evidence of active CMK usage. Prowler scan results flagging this specific check round out the documentation package.

Framework-specific interpretation

Tool mappings

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

  • Compliance.tf Control: redshift_cluster_encrypted_with_cmk

  • AWS Config Managed Rules: REDSHIFT_CLUSTER_CONFIGURATION_CHECK, REDSHIFT_CLUSTER_KMS_ENABLED

  • Checkov Check: CKV_AWS_142

  • Powerpipe Controls: aws_compliance.control.redshift_cluster_encrypted_with_cmk, aws_compliance.control.redshift_cluster_kms_enabled

  • AWS Security Hub Control: Redshift.10

  • KICS Query: cfdcabb0-fc06-427c-865b-c59f13e898ce

  • Trivy Check: AWS-0084

Last reviewed: 2026-03-09