Amazon Redshift cost optimization in 2026 comes down to five levers: right compute model (RA3 vs Serverless), correct sizing, Reserved Instances timed to stable usage, capped concurrency scaling, and WLM plus materialized view tuning.
Updated: July 15, 2026
Amazon Redshift cost optimization in 2026 comes down to five levers: pick the right compute model (RA3 provisioned vs. Redshift Serverless), size nodes or RPUs against actual concurrency, commit to Reserved Instances only after 30–60 days of stable usage, cap concurrency scaling before it silently 3x's your bill, and tune WLM and materialized views to shrink query hours. Teams that pull all five typically cut Redshift spend 40–70% without touching a single query.
Before you can cut a Redshift bill, you need to know what you're actually being charged for. In 2026 the invoice has five line items, and mixing them up is the single most common reason FinOps teams misdiagnose spend. I've watched a team spend a whole week chasing a "compute spike" that turned out to be Managed Storage growth on a fact table nobody had pruned in two years.
DC2 (Dense Compute) node types are still bookable, but AWS has been steadily pushing customers to RA3 or Serverless. DC2 pricing hasn't dropped since 2020 and it lacks Managed Storage, so you pay to add compute you don't need just to hold data. If you're on DC2 in 2026, migrating to RA3 is almost always a cost cut, not a cost increase. The official Amazon Redshift pricing page is the authoritative source for current per-region hourly rates. Always check it against the regions you actually run in, because inter-region pricing gaps of 15–20% are common.
This is the first decision that determines your ceiling on savings. Redshift Serverless bills per RPU-second only when a query runs; a provisioned RA3 cluster bills 24/7 unless you pause it. That sounds like Serverless always wins. But past a certain sustained-load threshold, provisioned is dramatically cheaper.
| Dimension | RA3 Provisioned | Redshift Serverless |
|---|---|---|
| Billing granularity | Per hour, per node | Per second, 60-sec minimum |
| Idle cost | Full hourly rate unless paused | Zero (only pays when queries run) |
| Minimum spend / month (us-east-1) | ~$260 (1x ra3.xlplus on-demand) | ~$0 if truly idle |
| Reserved Instance discount | Yes, up to 63% (3yr All Upfront) | No RI; commit via AWS Compute Savings Plan (limited coverage) |
| Concurrency scaling | Separate line item, capped by hour/day | Built into RPU auto-scaling |
| Break-even threshold | Wins above ~6–8 active query-hours/day | Wins for spiky/intermittent workloads |
| Best for | 24/7 BI, always-on ETL, predictable load | Ad-hoc analytics, dev clusters, monthly reporting |
So the rule of thumb: if your cluster runs queries less than ~30% of the day and never at 3am, Serverless is almost certainly cheaper. If you have overnight ETL followed by a 12-hour BI workday, RA3 with Reserved Instances almost always wins. Honestly, many mid-size shops end up with both. A provisioned RA3 cluster for the always-on workload, plus a Serverless workgroup for ad-hoc queries and quarterly reporting jobs.
Once you're on RA3, right-sizing is the fastest way to shave 30–50% off compute. The three node sizes have very different price/performance profiles:
Use elastic resize (not classic) to add or remove nodes with only a few minutes of connection drops rather than hours of read-only mode. To size correctly, pull the last 14 days of STL_QUERY_METRICS and SVL_QUERY_METRICS_SUMMARY and look for two signals: peak concurrent queries (drives node count) and mean CPU during your busiest hour (drives node type).
-- Find your true peak concurrency over the last 14 days
SELECT
DATE_TRUNC('hour', start_time) AS hour,
COUNT(DISTINCT query) AS queries,
MAX(concurrency_scaling_status) AS scaling_used
FROM STL_QUERY
WHERE start_time > DATEADD(day, -14, CURRENT_DATE)
AND userid > 1 -- exclude system queries
GROUP BY 1
ORDER BY queries DESC
LIMIT 20;If peak concurrent queries stays under 15 and CPU never exceeds 60% during that peak, you can almost certainly drop one node. Test with elastic resize. It takes minutes and it's reversible. For a repeatable process, see our AWS Compute Optimizer guide; while Compute Optimizer doesn't cover Redshift directly, the same right-sizing discipline applies.
Redshift RIs discount the compute portion of RA3 or DC2 nodes only. They do not apply to Managed Storage, Serverless RPUs, Concurrency Scaling, or Spectrum. In 2026 the discount tiers on RA3 are approximately:
Three rules will keep you out of trouble:
Reserved Instances are non-transferable across regions and node types. A 3-year RA3.4xlarge RI in us-east-1 is worthless if you migrate the workload to eu-west-1 or shrink to ra3.xlplus. AWS will let you sell them on the Reserved Instance Marketplace, but Redshift RI resale volumes are thin and typical clearing discounts run 15–30%.
Concurrency Scaling is the sneakiest line item on the Redshift bill. Every active cluster earns one free hour of scaling per calendar day, credited toward on-demand scaling usage. Beyond that, you're charged the on-demand per-second rate for the equivalent cluster size. On an ra3.4xlarge 4-node cluster, an hour of concurrency scaling costs roughly $13; a dashboard fleet that hammers your cluster all day can rack up $300–$800 daily in scaling if left uncapped.
I once inherited a cluster where a single misbehaving Looker dashboard was pinning 22 hours a day of scaling. The fix (setting the cap below) took ten minutes. The bill dropped $18k the following month.
You should always set max_concurrency_scaling_clusters. It defaults to 1 in newer clusters, but many older clusters were provisioned with a higher default. Check and pin it:
-- See current parameter group values
SHOW max_concurrency_scaling_clusters;
-- Set an absolute cap in the parameter group (via CLI)
-- aws redshift modify-cluster-parameter-group \
-- --parameter-group-name my-pg \
-- --parameters ParameterName=max_concurrency_scaling_clusters,ParameterValue=1,ApplyType=dynamicAlso enable per-queue scaling explicitly in WLM. Turn it on for the queues used by BI tools that occasionally spike, and off for the ETL queue where you'd rather back up than pay for scaling. Combine this with a CloudWatch alarm on the ConcurrencyScalingSeconds metric: alarm at (24 * 3600 * 3) = 3x your free daily budget, and get a Slack ping the moment a runaway dashboard kicks in.
Redshift Managed Storage (RMS) on RA3 and Serverless costs approximately $0.024/GB-month in us-east-1. That's cheaper than S3 Standard on a per-GB basis but not free. Because storage decoupled from compute in 2019, most clusters accumulate garbage over years: old fact-table snapshots, staging schemas from migrations, materialized views nobody refreshes, and cluster snapshots outside the retention window.
Three cleanup wins that consistently return 20–40% storage savings:
SVV_TABLE_INFO for tables with zero rows or where size is disproportionate to actual usage in STL_SCAN. A table that hasn't been scanned in 90 days is almost always safe to unload to S3 and drop.auto_vacuum in newer versions.-- Find the top 20 storage offenders
SELECT
"schema" AS schema_name,
"table" AS table_name,
size AS size_mb,
tbl_rows,
unsorted,
vacuum_sort_benefit
FROM SVV_TABLE_INFO
ORDER BY size DESC
LIMIT 20;Redshift Spectrum lets you query Parquet, ORC, or CSV files directly on S3 without loading them into managed storage. At $5/TB scanned, Spectrum is a lever, not a tax. Used correctly, it moves cold-and-huge data off Managed Storage entirely, saving both storage cost and compute (Spectrum's scan runs on separate Spectrum nodes, not your cluster).
The optimization playbook is identical to Athena's: convert to Parquet, partition aggressively by date, and use ZSTD compression. See our Athena partitioning and Parquet guide; every technique there applies verbatim to Spectrum. The official Redshift Spectrum documentation also documents predicate pushdown behavior. Anything that pushes down is scanned server-side and doesn't hit your $5/TB budget.
Data sharing (across accounts and regions) is compute-metered on both producer and consumer sides in 2026. The producer pays for the query's scan portion, the consumer pays for the compute that reshapes the result. Consolidate share consumers wherever possible; a share used by five downstream Serverless workgroups often costs more than replicating the data into one shared warehouse.
Everything above optimizes what you pay per hour. This section reduces the number of hours you need. In my experience the two biggest levers are Workload Management (WLM) tuning and materialized views.
Automatic WLM (the default since 2021) sizes queues dynamically, but you still control the priority mix. Assign LOW priority to background ETL and HIGHEST only to executive dashboards. Redshift's short-query acceleration (SQA) will fast-path anything under a few seconds. Leave it enabled, but monitor STL_WLM_QUERY to confirm your critical dashboards aren't waiting behind long ETL.
If a BI tool runs the same GROUP BY over a 500M-row fact table every 15 minutes, a materialized view refreshed every 30 minutes usually turns a 40-second query into a 200ms query and drops the fact-table scan volume by 95%. Track candidate queries with:
-- Top repeated queries by total execution time (7 days)
SELECT
LEFT(TRIM(querytxt), 80) AS query_head,
COUNT(*) AS runs,
SUM(elapsed) / 1000000 AS total_seconds,
AVG(elapsed) / 1000000 AS avg_seconds
FROM STL_QUERY
WHERE starttime > DATEADD(day, -7, CURRENT_DATE)
AND aborted = 0
GROUP BY 1
HAVING COUNT(*) > 20
ORDER BY total_seconds DESC
LIMIT 25;Automatic Query Rewriting to Materialized Views (introduced in 2020, GA on all clusters by 2022) means you often don't even need to update the query. Redshift silently rewrites it to hit the materialized view when possible.
You cannot cut what you cannot see. Three dashboards belong on every FinOps team's wall for Redshift:
query_group label to pass a source-app tag from your BI tool.ConcurrencyScalingSeconds. Any daily total > 3600s (1 hour) is unfree; more than a few hours warrants a query hunt.For anomaly-style alerting on the bill itself, plug Redshift into the same pipeline you use for the rest of your AWS spend. See our cloud cost anomaly detection setup for the CloudWatch and AWS Cost Anomaly Detection wiring.
Ship these ten changes in order and expect a 40–70% reduction on most non-optimized clusters within one quarter:
max_concurrency_scaling_clusters = 1 unless you have a documented reason otherwise.Only for intermittent workloads. Serverless wins when your cluster runs queries less than roughly 30% of the day; above that threshold, an RA3 cluster with a 1-year Reserved Instance is meaningfully cheaper. The break-even is typically 6–8 active query-hours per day for equivalent capacity.
Every active cluster earns one free concurrency-scaling hour per day. Beyond that, you're billed the on-demand per-second rate for the equivalent cluster size, roughly $13/hour on an ra3.4xlarge 4-node cluster. Uncapped, a runaway BI dashboard can add $300–$800 per day.
The three fastest wins are: pause dev and QA clusters outside business hours (up to 76% off those workloads), cap max_concurrency_scaling_clusters at 1, and elastic-resize down one node if peak CPU stays under 60%. All three can ship in a single afternoon and typically reduce total Redshift spend 20–35%.
No. Redshift RIs discount RA3 or DC2 provisioned compute only. Redshift Serverless RPU usage is not covered by Redshift RIs; the closest commitment vehicle is an AWS Compute Savings Plan, which offers limited coverage on Serverless usage in most regions in 2026.
Yes, almost always. DC2 lacks Managed Storage, so you pay to add compute just to hold data. RA3 decouples the two and typically ships better price/performance per query. AWS provides an in-place elastic resize path from DC2 to RA3 that keeps your cluster online for the duration.
The ra3.xlplus at ~$1.086/node-hour on-demand in us-east-1 is the cheapest RA3 entry point, but "cheapest" depends on your workload. For workloads with fewer than ~15 concurrent queries and modest CPU, a 2-node ra3.xlplus cluster with a 1-year No Upfront RI is the price floor for a 24/7 Redshift deployment, roughly $415/month per node before storage.
Which managed PostgreSQL is actually cheapest in 2026? Side-by-side pricing for RDS, Aurora, Cloud SQL, and Azure Flexible Server across four real workloads, with commitment discounts and workload-by-workload picks.
Master AWS Compute Optimizer to right-size EC2, EBS, Lambda, and Auto Scaling group fleets. Covers enhanced metrics setup, performance risk scoring, export pipelines, and the pitfalls that trip up new FinOps teams.
How to cut a BigQuery bill 45-68% in 2026: choose between on-demand and Editions slots, partition and cluster correctly, use materialized views, and monitor cost with INFORMATION_SCHEMA SQL you can copy-paste.