AWS Redshift Cost Optimization Guide: Serverless RPUs and WLM
How to cut your AWS Redshift bill by optimizing Serverless base capacity, managing RPUs, leveraging RA3 instances, and tuning Workload Management (WLM).
- ✓Redshift Serverless base capacity is a floor, not just a suggestion. Setting it too high guarantees a high baseline bill.
- ✓For provisioned RA3 clusters, pause them when not in use. A cluster left running over the weekend costs money for no reason.
- ✓Concurrency Scaling allows Redshift to handle peaks, but must be monitored closely to avoid surprising AWS bill shocks.
- ✓Run SYS system views to understand which queries are scanning the most blocks.
Table of contents
AWS Redshift is exceptionally fast when tuned, but it is notoriously easy to architect yourself into an unexpected AWS bill.
Unlike Snowflake or BigQuery, where cost is directly tied to a specific warehouse or query scan, the Redshift billing surface comprises RPUs (Serverless), Nodes (Provisioned), Concurrency Scaling clusters, and Managed Storage.
This guide explores practical optimization tactics to stop AWS Redshift from draining your data platform budget.
1. Redshift Serverless: Tuning Base Capacity
Redshift Serverless sizes compute automatically in Redshift Processing Units (RPUs). The minimum configurable base RPU is 8.
The cost trap: The base capacity is a hard floor.
If you set your base capacity to 128 RPUs to guarantee fast BI dashboard load times, you pay for 128 RPUs anytime the workgroup is active, even if the active query is just SELECT COUNT(1) FROM dim_date.
- The Fix: Lower the base RPU capacity and let Serverless scale up automatically for complex jobs. Use a dedicated smaller workgroup for small ad-hoc BI tasks.
2. Provisioned RA3: Pause and Resume
If you are running provisioned RA3 nodes, you pay per node per hour.
If your data team only works Monday to Friday, 9 to 5, leaving a 4-node ra3.4xlarge cluster running over the weekend wastes thousands of dollars.
- The Fix: Use AWS EventBridge and Redshift’s “Pause and Resume” API to shut down development and staging clusters automatically at 6 PM on Friday and wake them up at 8 AM on Monday.
3. Concurrency Scaling Costs
Concurrency scaling automatically spins up transient clusters when your workload experiences query queueing. You get 1 free hour of concurrency scaling per 24 hours the main cluster operates.
- The Trap: If a bad dashboard or an automated tool slams Redshift with hundreds of simultaneous queries, concurrency scaling will deploy up to 10 additional server clusters in seconds, billing by the second.
- The Fix: Limit
max_concurrency_scaling_clusterson your Workload Management (WLM) queues to a safe threshold (e.g., 1 or 2) for ad-hoc users.
4. Query & Storage Tuning
Like all columnar databases, scanning unnecessary blocks burns CPU and memory.
- Use
SYS_QUERY_HISTORYto find queries returning huge data but spending long times in the execution phase. - Ensure large tables have correct Sort Keys (so Redshift can skip blocks) and Distribution Keys (to minimize network broadcast during joins).
Before deploying sweeping architectural changes, use our [[Cost Estimator|/compare/cost-estimator/]] to compare how a theoretical workload on Redshift Serverless compares directly to competitors like Snowflake.
Senior Data & AI Engineer · SnowPro Core & Gen AI Certified
4+ years building production data platforms on Snowflake, Databricks, AWS, and Azure. I write from hands-on experience with Medallion architectures, dbt, Airflow, PySpark, and Snowflake Cortex AI. Every tutorial on this blog reflects real pipeline decisions — not documentation rewrites.
Read more about the author →
