Redshift Rules

These rules flag Redshift clusters with low utilization, missing reserved node coverage, and clusters eligible for pause/resume scheduling.

CLDBRN-AWS-REDSHIFT-1

Redshift Cluster Low CPU Utilization

Scan type: Discovery

Severity: High

What it checks

Flags available Redshift clusters whose average CPU utilization over the past 14 days is at or below 10%. A cluster consistently running this cold is either oversized or underused.

Why it matters

Redshift clusters bill by the node-hour regardless of query load. A ra3.xlplus cluster with 3 nodes at 10% CPU costs the same as one running at 80%. If your cluster barely touches its CPU budget over two weeks, you're paying for capacity you don't need. Downsizing or consolidating workloads onto fewer nodes can cut costs significantly.

What triggers a finding

• Cluster status is available
• 14-day average CPU utilization is not null and is at or below 10%

Metrics are joined to the cluster inventory by account, region, and cluster identifier.

Coverage

An available cluster whose 14-day average CPU utilization is missing is reported as unknown rather than as a pass. See Live Evaluation Coverage.

How to remediate

1. Check CloudWatch metrics to understand the workload pattern - is it consistently low, or are there brief spikes?
2. If consistently low, resize the cluster to fewer or smaller nodes:

aws redshift modify-cluster \
  --cluster-identifier my-cluster \
  --node-type ra3.xlplus \
  --number-of-nodes 2

3. For intermittent workloads, consider enabling pause/resume scheduling (see CLDBRN-AWS-REDSHIFT-3) or migrating to Redshift Serverless, which scales compute to match demand automatically.

CLDBRN-AWS-REDSHIFT-2

Redshift Cluster Missing Reserved Coverage

Scan type: Discovery

Severity: High

What it checks

Flags Redshift clusters that have been running for at least 180 days without matching active reserved node coverage. The rule tracks reserved node inventory by region:nodeType and checks whether each long-running cluster is covered.

Why it matters

Redshift Reserved Nodes offer up to 75% savings compared to on-demand pricing on 3-year terms. A cluster running for 6+ months on-demand is a strong signal that it's a steady-state workload and should be reserved. For a 3-node ra3.xlplus cluster, that's thousands of dollars per year in savings.

What triggers a finding

All of the following must be true:

• Cluster status is available
• Cluster has been running for 180 or more days
• Cluster node count is greater than zero
• The cluster's node count exceeds the remaining reserved node inventory for its region:nodeType combination

Findings carry a resourceType of redshift:cluster. When this rule reports a cluster, it supersedes the equivalent Cost Optimization Hub reservation-purchase finding (CLDBRN-AWS-COSTOPTIMIZATIONHUB-2) for the same cluster. See Finding Precedence.

How to remediate

1. Review the flagged cluster's node type, node count, and region
2. Check existing reserved node inventory for coverage gaps
3. Purchase reserved nodes matching the cluster configuration:

aws redshift purchase-reserved-node-offering \
  --reserved-node-offering-id <offering-id> \
  --node-count 3

Use AWS Cost Explorer's RI recommendations to find the optimal term length and payment option for your usage.

CLDBRN-AWS-REDSHIFT-3

Redshift Cluster Pause Resume Not Enabled

Scan type: Discovery and IaC

Severity: High

What it checks

Flags Redshift clusters that are eligible for pause/resume scheduling but don't have both a pause and resume schedule configured. Eligible clusters must be available, not HSM-enabled, not Multi-AZ, have a snapshot retention period greater than zero, and reside in a VPC. Clusters where the pause/resume state could not be determined (e.g. DescribeScheduledActions was denied) are skipped.

Why it matters

Pausing a Redshift cluster stops compute billing entirely while preserving your data. If your cluster sits idle during off-hours or weekends, pause/resume scheduling can cut compute costs by 40-60% with zero data loss. Storage charges continue, but compute (the expensive part) stops.

What triggers a finding

• In discovery scans, the cluster is available, VPC-based, has automated snapshot retention greater than zero, is not HSM-enabled or Multi-AZ, and has no explicit indication that pause/resume state is unavailable
• In IaC scans, the declared cluster is VPC-based, has known automated snapshot retention greater than zero, and neither HSM nor Multi-AZ is explicitly enabled; runtime status and pause/resume availability are not checked
• In either mode, the cluster is missing a pause schedule, a resume schedule, or both

How to remediate

Configure both a pause and resume schedule for the cluster. For a typical business-hours workload:

# Pause at 8 PM UTC on weekdays
aws redshift create-scheduled-action \
  --scheduled-action-name my-cluster-pause \
  --target-action '{"PauseCluster":{"ClusterIdentifier":"my-cluster"}}' \
  --schedule "cron(0 20 ? * MON-FRI *)" \
  --iam-role arn:aws:iam::123456789012:role/RedshiftSchedulerRole

# Resume at 7 AM UTC on weekdays
aws redshift create-scheduled-action \
  --scheduled-action-name my-cluster-resume \
  --target-action '{"ResumeCluster":{"ClusterIdentifier":"my-cluster"}}' \
  --schedule "cron(0 7 ? * MON-FRI *)" \
  --iam-role arn:aws:iam::123456789012:role/RedshiftSchedulerRole

Both schedules are required. A cluster with only a pause schedule will pause and never resume automatically, which is probably not what you want.

IaC resources checked

See Also

• CLI discover command -- scan live Redshift clusters
• SDK Reference -- run scans programmatically