Explanation
Why the waste happens and who it affects.
The default base capacity is 128 RPUs, and many workgroups are created with that default or with a value copied from a sizing exercise and never adjusted. When the workload is made of light dashboard queries, small ETL steps, zero-ETL refreshes or connection health checks, each active period is billed at the full base capacity even though a much smaller base would complete the same work at acceptable speed.
The effect is amplified by the billing rules: usage is metered per second with a 60-second minimum charge, and AWS notes that capacity can stay at a higher level for a period after load falls. The Redshift documentation states that a higher base capacity yields better performance but also incurs higher costs, and its zero-ETL cost guidance recommends the lower 8 RPU base capacity where available.
Billing model
The pricing dimensions that drive this cost.
Redshift Serverless compute is billed only while queries run, at a rate driven by the capacity in use.
- RPU-hours
- Compute billed for the capacity used in a given duration, in RPU-hours on a per-second basis, and not billed when no queries are running
- Base capacity
- The RPU level Redshift uses to serve queries, 128 RPUs by default and adjustable from 4 RPUs up to 512 (1024 in some Regions)
- Minimum charge
- Each period of usage is charged for at least 60 seconds of resource usage
- Scaled capacity
- Capacity added above the base for higher load is billed at the same RPU rate as base compute
How to detect
5 checks to find it in your estate.
- List workgroups and their base capacity (get-workgroup or the Workgroup configuration Limits tab) and flag workgroups still at the 128 RPU default or at a high value with no documented reason
- Query SYS_SERVERLESS_USAGE to see charged_seconds and compute_capacity per minute; workgroups whose usage consists of many short periods at full base capacity are paying the base rate for light work
- Review ComputeCapacity and ComputeSeconds in CloudWatch (AWS/Redshift-Serverless) together with query runtimes in SYS_QUERY_HISTORY; consistently short queries on a large base suggest the base can be lowered
- Check for connection pools or BI tools sending frequent health-check queries; Redshift Serverless treats them as billable user activity, so they trigger compute charges at the workgroup's capacity even when no real workload runs
- Confirm managed storage size before planning a reduction, because it constrains the minimum base capacity
How to fix
5 ways to remove the waste.
- Lower the base capacity with update-workgroup or the console, testing representative queries at each step; values are 4 RPUs, or multiples of 8 from 8 to 512, and editing the base capacity might cancel some running queries
- Respect the documented limits: 4 RPUs supports up to 32 TB of managed storage, 8 or 16 RPUs up to 128 TB, and above 128 TB the base cannot be set below 32 RPUs; AWS also recommends 32 or more RPUs for tables with many columns and higher concurrency
- For zero-ETL target workgroups, use the lower 8 RPU base capacity where available and lengthen REFRESH_INTERVAL where immediate freshness is not needed
- Use the price-performance target (for example toward Optimizes for cost) for workloads in the 8 to 512 RPU range, and set Max capacity to cap scaling above the base
- Set a Maximum RPU hours usage limit per day, week or month with a log, alert or turn-off-user-queries action, and reduce connection-pool health-check frequency to avoid paying for keep-alive queries
Documentation
Vendor references for pricing and configuration.