The largest Amazon Redshift cost lever is right sizing the cluster on RA3 node types, which separate compute from managed storage so you scale each independently instead of paying for a fixed bundle. After that, the order is clear: control concurrency scaling with usage limits so burst handling stays cheaper than oversizing, pause or move to serverless any cluster that sits idle overnight, and only then reserve the compute baseline you are certain you will keep. The mistake teams make is to reach for Reserved nodes first, locking in a cluster that is too big. Optimize the shape of the workload, settle on the true steady state, and reserve last. That sequence is what turns Redshift from a fixed monthly charge into a cost that tracks the work it actually does.
Here are the levers in priority order, with the mechanics of each.
What is the biggest Redshift cost lever?
Cluster sizing on RA3. Older dense compute and dense storage node families bundled compute and storage together, so growing one meant paying for the other. RA3 nodes decouple them: compute scales with node count and type, while data sits in Redshift managed storage that grows on its own and is billed separately. This matters because the common failure mode is a cluster provisioned for a historic peak, holding fixed compute capacity day and night even though the heavy queries run for a few hours. Moving to RA3 and sizing the node count to the real concurrent compute need, with storage left to scale independently, removes the structural overpay before any other lever is touched.
Does concurrency scaling save or cost money?
It does both, and the difference is control. Concurrency scaling spins up temporary cluster capacity to absorb query bursts, then removes it when the burst passes. AWS grants a free credit allowance that accrues as the main cluster runs, and usage beyond that allowance is billed per second. Left uncapped, a busy reporting period can push concurrency scaling spend up quietly. The right approach is to keep the base cluster sized for the steady load, let concurrency scaling handle the peaks, and set usage limits so the per second spend cannot run away. That is almost always cheaper than sizing the base cluster large enough to never burst, because you stop paying peak capacity rates for off peak hours.
Can you pause a Redshift cluster to save money?
Yes, and it is one of the easiest wins for non production clusters. Pause and resume halts compute billing on a provisioned cluster while keeping the data intact, so a development, test, or internal reporting cluster that no one touches overnight or at weekends stops costing compute during those hours. Schedule the pause and resume around working patterns and the cluster simply is not billed for the idle time. Redshift Serverless takes this further by charging for compute only while queries actually run, measured in Redshift Processing Units, which suits spiky or unpredictable workloads where even a scheduled pause leaves idle capacity on the table. Match the model to the pattern: steady clusters stay provisioned, intermittent ones lean toward serverless or scheduled pause.
A European SaaS company ran a single large provisioned Redshift cluster on an older node family, sized for a quarterly reporting peak and left at full capacity the rest of the time. Moving to RA3 separated storage from compute and let the team cut the node count to the real steady compute need, with concurrency scaling and usage limits absorbing the quarterly bursts. The development and staging clusters were put on a pause and resume schedule for nights and weekends. Once the new steady baseline was clear, a portion of it was placed on Reserved nodes for the committed discount. The combined changes reduced Redshift spend by roughly a third while query performance on the workloads that mattered was unchanged. The figures are verified against billing data and anonymised.
Where do reservations fit?
Last, not first. Redshift Reserved nodes trade a one or three year commitment for a substantial discount over on demand, which is real money on a cluster you are certain to keep. But a reservation locks the node count, so reserving before you have right sized and settled the steady baseline simply commits you to the oversized cluster you were trying to fix. The correct sequence is to optimize shape and confirm the durable baseline first, then reserve only that baseline, leaving headroom for concurrency scaling and serverless to handle variability on demand. Reserve the floor you will always use, never the peak you occasionally touch. This is the same risk adjusted commitment logic that applies across AWS, applied to the data warehouse.
Don't forget storage and query hygiene
Two smaller levers round it out. On the storage side, RA3 managed storage is billed by volume, so dropping tables no one queries, archiving cold data to S3, and using Redshift Spectrum to query infrequently accessed data in place keeps managed storage lean. On the query side, well chosen distribution and sort keys, vacuum and analyze maintenance, and result caching reduce how much compute each query consumes, which lowers both the base cluster size you need and the concurrency scaling you trigger. These do not produce the headline saving that RA3 sizing does, but they compound it, and they keep the cluster from drifting back toward overprovisioning over time.
Frequently asked questions
What is the biggest Redshift cost lever?
Does concurrency scaling save or cost money?
Can you pause a Redshift cluster to save money?
Optimize your Redshift estate with us
We right size Redshift on RA3, control concurrency scaling, schedule pauses, and reserve only the proven baseline, so the warehouse cost tracks the work it does. We take zero provider commissions and answer only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on either a Fixed Fee or a no risk Gainshare basis. Book a strategy call to scope it, and follow more in The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.