Explanation
Why the waste happens and who it affects.
Clusters created for a proof of concept, a migration, a one-off analysis or a reporting workload that has since moved elsewhere often keep running long after the last user connects. Because clusters usually have several nodes, and RA3 node types carry a high hourly rate, one forgotten cluster can be a large recurring line item.
The cluster looks healthy, so nothing alerts anyone: it passes its health checks, takes automated snapshots and applies maintenance, while no application or user connects to it. This is most common after data warehouse migrations (for example to Redshift Serverless or another platform), in sandbox accounts, and when a cluster is restored from a snapshot for investigation and never deleted.
Billing model
The pricing dimensions that drive this cost.
On-demand provisioned clusters are billed per compute node, independent of query activity.
- Node-hours
- Each compute node is billed at an hourly rate for the node type, with partial hours billed in one-second increments after a billable status change such as create, delete, pause or resume
- Managed storage
- RA3 and RG clusters pay separately for Redshift Managed Storage per GB-month
- Backup storage
- Manual snapshots are billed as backup storage, while automated snapshots are offered at no charge
- Paused clusters
- On-demand compute billing is suspended while paused, and storage charges continue
- Reserved nodes
- Billed for every hour of the term whether or not a matching node is running
How to detect
5 checks to find it in your estate.
- Review the Trusted Advisor check Underutilized Amazon Redshift Clusters, which flags a running cluster that has had no connection in the last 7 days, or had less than 5% cluster-wide average CPU for 99% of the last 7 days, and reports the reason and estimated monthly savings
- In CloudWatch (AWS/Redshift), check DatabaseConnections and CPUUtilization for the cluster over at least 30 days; DatabaseConnections at zero across the period is the clearest signal
- Query SYS_QUERY_HISTORY (or STL_QUERY) for user queries over the lookback period to confirm nothing, including scheduled jobs, is using the cluster
- Check whether the cluster is still the target of ETL jobs, BI tool connections, data shares or scheduled queries before treating it as unused
- Confirm ownership through tags and creation context, and check whether reserved nodes are applied to it
How to fix
5 ways to remove the waste.
- Delete clusters that are no longer needed, taking a final snapshot (delete-cluster with --final-cluster-snapshot-identifier) if the data may be needed again; delete the snapshot later if it is kept only as a precaution, since manual snapshots are billed as backup storage
- Pause clusters that will be needed again at a known date; pausing suspends on-demand compute billing, but it requires automated snapshots to be enabled and does not apply to EC2-Classic or HSM clusters
- Where usage is occasional rather than zero, migrate the workload to Redshift Serverless, which does not bill compute when no queries are running
- If the cluster is covered by reserved nodes, move another workload of the same node type and Region onto the reservation, because deleting or pausing the cluster does not stop reservation charges
- Tag clusters with an owner and review date at creation so proof-of-concept and migration clusters are removed on schedule
Documentation
Vendor references for pricing and configuration.