Redshift Serverless Pricing: RPU-Hour Math, Idle Costs, and When Provisioned Wins

Redshift Serverless arrived as the answer to the awkward problem of provisioned Redshift: clusters are expensive when idle and slow to scale when busy. The Serverless model bills per Redshift Processing Unit hour (RPU-hour) and scales transparently. That model is genuinely better for some workloads and genuinely worse for others. This piece walks the math so the decision is not a marketing-page reflex.

How Redshift Serverless billing works

• RPU-hour billed per second of usage, with a 60-second minimum after each query starts.
• Base capacity is set in RPUs (minimum 8 RPUs as of recent updates). The base is the lower bound; the workload can scale higher transparently.
• Storage is billed separately at S3 pricing for managed storage, similar to RA3 nodes on provisioned Redshift.
• Snapshot storage is billed beyond the included free tier.

The RPU-hour price

RPU-hour pricing varies by region but is roughly $0.36 to $0.50 per RPU-hour. With an 8-RPU base, that is $2.88 to $4.00 per hour while the workload is active. If the workload runs only during business hours (200 hours/month), this is $576 to $800/month. If the workload runs 24/7 (~730 hours/month), this is $2,100 to $2,920/month for the 8-RPU base alone, plus scale-up time.

The crossover point

The rule of thumb: if the cluster would be utilised more than ~50 percent of the time, provisioned with Reserved Instances is cheaper. Below 50 percent utilisation, Serverless wins.

Base capacity sizing

Base capacity is the most important decision in Serverless. Two failure modes:

• Base too high. Pays the base rate during all active hours regardless of actual query load. Common when teams set base at 32 RPUs "to be safe."
• Base too low. Triggers frequent scale-ups, which compound RPU-hour charges. A base of 8 RPUs scaling to 64 RPUs for short bursts costs more than starting at 16 RPUs.

Start at 8 RPUs. Monitor for two weeks. Adjust based on observed scaling behaviour.

Idle cost mythology

"Serverless has no idle cost" is the marketing tagline. The technical reality is more precise: there is no idle compute cost when no queries are running. However, two cost lines accrue continuously regardless of query activity:

• Storage at managed storage rates.
• Snapshot storage beyond the included tier.

For dev/test environments, the storage cost is the dominant line. For production with 100 GB of data, storage is $25/month. For a data warehouse with 50 TB, storage is $12,500/month.

Workload patterns that favour Serverless

• Development and test warehouses with intermittent use.
• BI dashboards that run during business hours only.
• Ad-hoc analytics teams with unpredictable query loads.
• Multi-tenant SaaS analytics where customer query volume is uneven.
• POCs and trial deployments before committing to provisioned.

Workload patterns that favour Provisioned + RIs

• Production data warehouses with steady-state query load.
• Reporting pipelines that run continuously throughout the day.
• Workloads sensitive to scale-up latency (Serverless takes seconds to scale).
• Customers with a known 1- or 3-year horizon and committed budget.

The hybrid pattern

Many mature analytics architectures combine both:

• Provisioned RA3 with Reserved Instances for the steady-state production warehouse.
• Redshift Serverless for ad-hoc analyst workloads, dev/test, and overflow capacity.
• Data sharing between the two environments so analysts can run heavy queries on Serverless without affecting production.

This pattern lets each workload use the cost-optimal Redshift engine.

Migration cost

Moving from provisioned to Serverless (or back) is straightforward via snapshot restore, but two cost considerations:

• Snapshot egress to a different region or account bills standard data transfer rates.
• Parallel running during cutover doubles cost temporarily; minimise the window.

The EDP angle

Redshift Serverless is part of the analytics bundle inside an EDP. The negotiation levers:

• Bundle Serverless RPU-hour with provisioned Redshift node-hours for a blended discount.
• Negotiate base-capacity-hour rate discounts at 50,000+ RPU-hours per month.
• Migration credits when consolidating Snowflake or other warehouses to Redshift.
• Storage-tier discounts on managed storage for committed volumes.

Worked example: ad-hoc analyst team

For this workload, Serverless wins when used intermittently, loses when used continuously. The decision criterion is utilisation, not vendor narrative.

Implementation checklist

1. Measure query patterns over 30 days to determine utilisation.
2. Right-size base capacity at 8 RPUs initially; adjust after monitoring.
3. Use Serverless for dev/test and ad-hoc; reserve provisioned with RIs for production.
4. Audit managed storage for redundant or oversized datasets.
5. Negotiate analytics bundle in the next EDP cycle.
6. Contact us for a Redshift cost review benchmarked against 500+ engagements.

Common failure modes

Over-provisioning base capacity

The most expensive Serverless mistake. A 32-RPU base "just in case" pays 4x what an 8-RPU base would pay during active hours.

Treating Serverless as a free lunch

Serverless is cheaper for intermittent workloads, not for all workloads. For 24/7 production warehouses, provisioned + RIs wins by 50 to 65 percent.

Forgetting storage costs

Managed storage is billed separately and accrues continuously. A dev environment with 10 TB of data costs $2,500/month in storage alone before any RPU-hour usage.

Mixing workloads on a single Serverless workgroup

ETL and analyst queries on the same workgroup cause each to inflate the other's scaling behaviour. Use separate workgroups, or use provisioned for ETL.

Data sharing between Serverless and provisioned

Redshift data sharing lets a single dataset be accessed across multiple Redshift workgroups and clusters without copying. The cost model:

• Storage is paid once on the producer side.
• Compute is paid by each consumer at their own rate (Serverless RPU-hour or provisioned node-hour).
• No data transfer charge between producer and consumer in the same region.

This pattern enables the hybrid architecture: a provisioned RI-backed warehouse acts as the data producer, while a Serverless workgroup serves intermittent analyst queries against the same shared data. The result is a single source of truth with cost-optimal compute per workload.

Concurrency scaling

On provisioned Redshift, concurrency scaling adds transient clusters to handle query spikes. On Serverless, scaling happens within the same workgroup. The cost dynamic:

• Provisioned concurrency scaling bills at the per-second rate of the transient cluster after the free credit allowance.
• Serverless scaling is invisible to the user but bills incremental RPU-hours.

For bursty BI workloads, Serverless eliminates the concurrency-scaling configuration step. For predictable steady-state with occasional spikes, provisioned with reserved baseline and concurrency-scaling credits is cheaper.

Materialized views and result caching

Materialized views in Redshift Serverless run on the same RPU-hour billing as user queries. The trade-off: refreshing materialized views costs RPU-hours, but it eliminates the recomputation cost for downstream queries. For dashboards hitting the same query patterns, materialized views combined with result caching cut the underlying RPU consumption by 60 to 80 percent.

For more see the AWS analytics cost optimization pillar, the Redshift pricing negotiation piece for the provisioned discounting model, and the RI optimization guide for the underlying RI mechanics that determine the crossover point.