Amazon Redshift Serverless RPU cost is the compute line on a workgroup that has no cluster you sized yourself. Capacity is measured in Redshift Processing Units. You pay RPU-hours, metered per second, with a 60-second minimum charge when compute runs. Storage is a separate managed-storage charge. A workgroup sitting idle does not keep a provisioned cluster's hourly node cost, and a single query can still scale compute toward maxCapacity and hold it there until the query ends.
The CFO sees serverless as "we only pay when we query" and then sees a spike. The spike is usually a dashboard or a transform whose maxCapacity was left at the service maximum. Rutagon sets the ceiling, adds a usage limit with a breach action, and shows which queries consumed the RPU-hours. The outcome is a workgroup that cannot silently become your largest database line.
Base capacity, max capacity, and the 60-second floor
baseCapacity is the floor the workgroup uses when queries run. maxCapacity is the ceiling it may scale to. The gap between them is the surprise. A floor of a small RPU count looks cheap in a design review. A ceiling many times higher is what an unbounded join actually buys. We read both from the workgroup before we talk about query text.
The 60-second minimum matters for chatty workloads. A health check or a BI tool that fires a tiny query every minute can bill a minute of RPU each time if the workgroup starts compute for it. Connection pooling and query grouping reduce that chatter. Raising base capacity to "make it faster" increases the RPU multiplier on every one of those minimums. We do not raise the floor until the query list says the floor is the bottleneck.
AWS documents capacity settings in Redshift Serverless capacity. Usage limits are the second control: a budget of RPU-hours per day, week, or month. The breach action can log, emit a metric, or deactivate user queries. We ship deactivate on production workgroups that have surprised finance before, and log-only on a workgroup that is still being sized. Deactivate is a loud control. It is supposed to be.
aws redshift-serverless create-usage-limit \
--resource-arn "$WORKGROUP_ARN" \
--usage-type serverless-compute \
--amount 200 \
--period daily \
--breach-action deactivate
amount is RPU-hours for serverless-compute. The control that matters is the one the service enforces: a numeric ceiling and a breach action your on-call understands. A limit that only emails a dead inbox is a report.
Amazon Redshift Serverless RPU cost on the queries that scale
The scorecard is RPU-hours by day, joined to query history: query id, user, elapsed time, and the compute the workgroup was using. Serverless query monitoring views expose the statements. The top consumers are usually an unbounded scan, a cross join, or a dashboard that selects more rows than the chart can draw. Athena query scan cost is the parallel conversation when the data is still a data lake and someone reached for a warehouse too early. Moving that scan into an uncapped Redshift workgroup changes the meter from bytes to RPU-hours. It does not make the scan free.
We set maxCapacity to the highest concurrency you have actually needed, not the highest the console slider allows. If a monthly close legitimately needs more, that close uses a higher limit for a window, with an owner, and the limit comes back down. A permanent ceiling set for one Saturday is how the spike becomes structural.
Data layout still matters. Sort keys, distribution, and a materialized result for the dashboard beat a larger RPU ceiling. We will raise capacity when EXPLAIN and queue time say the work is real. We will not raise it because a timeout was annoying and the slider was available. Aurora Serverless v2 cost is a different serverless meter, ACUs on a transactional database. The habit to avoid is the same: an uncapped maximum left from a prototype.
Spectrum and data sharing can add charges beside RPU. We separate them on the scorecard so a Redshift line-item argument does not mix storage scans in S3 with workgroup compute. Data analytics work includes that split. One number called "the warehouse bill" is how the wrong fix gets approved.
What we change first
First the usage limit, so tomorrow's runaway has a brake. Then maxCapacity, so the brake is not the only thing between you and a large hourly rate. Then the top queries. Then base capacity, only if the floor is starving normal work. Reversing that order spends money on a higher floor while the ceiling is still open.
Scheduled transforms move off interactive workgroups. A load job and a BI user on the same uncapped workgroup compete, and the load job sets the scale. A second workgroup with a tight max RPU for dashboards keeps exploration from funding itself with production capacity. Isolation is an architecture change with a cost result.
We keep the before-and-after RPU-hours and the workgroup settings with the cost review. If a control owner wants it, the same note is filed in the GRC you already run. The person who buys this work is the one who can see Cost Explorer. The technical detail they can repeat is: RPU-hours, 60-second minimum, maxCapacity, and a usage limit whose breach action turns queries off.
Idle is not the villain. A paused consumer is cheap. The villain is a high ceiling during a bad query. We say that so nobody solves this article's problem by hunting idle clusters the way they hunt idle EC2. Serverless already released the idle nodes. The cap is the remaining control.
Frequently Asked Questions
How is Redshift Serverless compute billed?
In RPU-hours, per second, with a 60-second minimum when compute runs. baseCapacity is the floor and maxCapacity is the ceiling. Storage bills separately. An idle workgroup does not keep provisioned node hours, and a single query can still scale toward the ceiling.
What does a usage limit do?
It caps RPU-hours over a day, week, or month. On breach it can log, emit a metric, or deactivate queries. We use deactivate when a workgroup has already produced a surprise bill, and we make sure on-call knows the workgroup will stop accepting queries at the cap.
Should we raise base capacity to reduce timeouts?
Only after the query list shows the floor is the limit. Raising base capacity multiplies every query, including chatty ones that hit the 60-second minimum. The first levers are maxCapacity, the usage limit, and the SQL that scaled the workgroup.
How do you find the query that caused a spike?
Join RPU-hour usage to serverless query history for that window: query text, user, and elapsed time. The top statements get rewritten or moved to a workgroup with a tighter ceiling. A higher account-wide budget without that list will be consumed the same way.
Does this replace an Athena layout fix?
No. A lake scan that is expensive in Athena stays expensive in spirit if you pour it into an uncapped workgroup. We pick the engine for the workload and cap the one you keep. RPU-hours and bytes scanned are different lines and both belong on the scorecard.
Talk to us about an AWS cost scorecard for this workgroup. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.