Idle Redshift clusters have near-zero database connections and low CPU utilization over the last 14 days — a signal the warehouse may no longer be running analytics workloads but still incurs compute charges.
Before you pause or delete
- Confirm no BI dashboards, ETL jobs, scheduled queries, or third-party tools still connect to this cluster.
- Check for dependent snapshots, datashares, or cross-cluster queries that reference this warehouse.
- Review whether the cluster is part of a maintenance window or seasonal analytics cycle that will resume soon.
Pause vs delete
Pause is the safer first step: compute billing stops while your data and configuration are preserved, and you can resume later with aws redshift resume-cluster. Snapshot and managed storage charges continue while paused.
Delete removes the cluster permanently. Paid plans include remediation scripts that pause the cluster first and, if you are certain it is no longer needed, delete it with a final snapshot.
AWS Redshift pause and delete commands do not support --dry-run — review commands carefully before running them.
What triggers this finding
A Redshift cluster with no active queries or very low CPU and disk utilization over the lookback window.
Typical fix
Pause the cluster during off-hours, or delete it if analytics workloads no longer need it.
Example savings
Often 100% of compute charges when paused or deleted — typically $100–$1,000+/month for provisioned clusters.
See also: Severity and savings estimates for how Parsivex calculates figures on your report.
Node-hours multiplied by node count
Redshift bills per node, per hour, for as long as the cluster is available. There is no per-query component on a provisioned cluster and no discount for silence — the node count you chose is the node count you pay for, around the clock.
Parsivex multiplies the us-east-1 on-demand hourly rate for the node type by 730 hours and by the number of nodes. The rates it prices against are $0.25 for dc2.large, $4.80 for dc2.8xlarge, $1.086 for ra3.xlplus, $3.26 for ra3.4xlarge, and $13.04 for ra3.16xlarge. The multiplication is what makes these findings large: a two-node dc2.large development cluster is $365 a month, while a four-node ra3.4xlarge nobody has queried since a project ended is $9,519. Node types outside that table are skipped rather than estimated.
On ra3 clusters, compute and storage are billed separately — managed storage is charged per GB-month independently of the nodes. That separation is exactly why pausing works as a partial fix: pausing stops the node-hours, which is the whole of the figure above, while managed storage and any retained snapshots keep billing at their own rates. The saving is real and large; it is not the entire Redshift line.
Reserved nodes are the exception worth checking first. If the cluster is covered by a reserved-node purchase, the money is already spent and pausing recovers none of it until the term ends. The estimate is pure on-demand arithmetic and does not know about commitments.
The two conditions, read together
A cluster is reported only when both signals are quiet across the last 14 days: average DatabaseConnections below 0.5 and average CPUUtilization below 5%. The cluster must also be available and more than 14 days old.
aws cloudwatch get-metric-statistics --namespace AWS/Redshift \
--metric-name DatabaseConnections \
--dimensions Name=ClusterIdentifier,Value=my-cluster \
--start-time 2026-07-29T00:00:00Z --end-time 2026-08-12T00:00:00Z \
--period 86400 --statistics Average Maximum
Repeat with --metric-name CPUUtilization. Requiring both is what keeps interactive warehouses out of the report — a cluster with even one BI tool holding a session clears the connections test on its own.
What it does not filter out is batch. A nightly ETL that runs for twenty minutes at 80% CPU contributes under 0.1% to a fortnight's average, and its connections average close to zero on the same arithmetic. A warehouse that is loaded every night and queried by nobody during the day will be reported as idle, and in a narrow sense the report is accurate — the cluster is sized for interactive analytics it is not serving.
Quiet clusters that are doing their job
- Batch-only warehouses. Loaded on a schedule, read by a downstream export. Real work, invisible to both metrics.
- Datashare producers. On
ra3, a consumer cluster's queries run on the consumer's own compute against the producer's managed storage. The producer's CPU and connection counts stay flat while its data is queried constantly, which makes this the sharpest false positive in the category — pausing a producer breaks every consumer. - Seasonal analytics. Quarter-end close, annual reporting, and audit cycles leave a cluster dormant for months by design.
- Disaster-recovery standbys. A cluster restored from snapshot and kept ready is meant to be silent.
- Clusters between projects. Retained deliberately while a team decides whether the next phase is funded.
Where the finding is right about the cost but wrong about the remedy, mark it accordingly through the finding lifecycle rather than leaving it to reappear every scan.
What pausing and deleting actually cost
Pausing is the reversible option and it is genuinely reversible — the cluster keeps its identifier, endpoint, node configuration, and data, and resuming restores all of it. The costs are that the cluster is completely unavailable while paused, so any connection attempt fails rather than queues, and that resuming takes minutes rather than seconds. A pause is not something to schedule against an hourly dashboard.
Deleting is where the care is needed. Without a final snapshot, the data is gone irretrievably; with one, the snapshot's storage is billed for as long as it exists. Restoring from a snapshot produces a new cluster with a new endpoint, so every JDBC string, BI connection profile, and ETL configuration pointing at the old hostname needs updating — and on dc2 the restore also has to move all the data back onto node-local storage, which takes time proportional to the volume.
Two consequences catch people. Pausing a producer cluster stops its datashares, so the failure lands in someone else's account. And a paused cluster still counts against snapshot and managed-storage charges, so a cluster paused and forgotten for a year is cheaper than it was but not free — the finding will not resurface to remind you, because a paused cluster is no longer available and is no longer scanned.