How Redshift Concurrency Scaling works?
When a WLM queue reaches its concurrency capacity, Redshift can route eligible queries to temporary scaling clusters instead of leaving them waiting.Enable the feature by setting Concurrency Scaling mode to auto for the relevant WLM queue.
AWS supports eligible read queries and the following write operations:
COPY
INSERT
DELETE
UPDATE
CREATE TABLE AS
VACUUM
manual materialized-view refresh
automatic vacuum
Review the current AWS Concurrency Scaling documentation for supported Regions, node types, and workload restrictions.
Check cluster eligibility first
Concurrency Scaling is for eligible provisioned Redshift clusters.Before configuring WLM, confirm that your cluster:
uses the EC2-VPC platform
is not a single-node cluster
uses a supported node type
operates in a supported Region
meets AWS's supported node-count requirements
How Redshift Concurrency Scaling pricing works
Free credit model
Every active provisioned cluster earns credits hourly, up to one hour for every 24 hours that the main cluster runs.A cluster can accumulate up to 30 hours.
Credits:
belong to the cluster that earned them
cannot be pooled across clusters
cannot be transferred to another cluster
remain available while the cluster exists
Paid billing formula
After the available credits are exhausted:Paid cost = (main cluster On-Demand hourly rate ÷ 3,600) × total billable scaling-cluster seconds
AWS charges only while a scaling cluster is serving queries. Startup and shutdown time are not charged, but every activation has a one-minute minimum.
If multiple scaling clusters run for different durations, add the billable seconds for each cluster before applying the formula.
AWS pricing example
AWS provides an example using a 10-node rg.4xlarge cluster in US West (N. California) at $33.66 per hour.If two scaling clusters each operate for five paid minutes:
This is an AWS example, not a universal cost estimate. Current prices vary by Region, node type, and cluster size. Check the Amazon Redshift pricing page before forecasting your bill.
Concurrency Scaling compared with other Redshift options
| Option | Best for | Billing effect | Main limitation |
|---|---|---|---|
| Concurrency Scaling | Short, unpredictable queue spikes | Free credits first, then per-second On-Demand pricing | Only eligible work is routed |
| Elastic Resize | Sustained or scheduled capacity changes | Changes main-cluster provisioned cost | Not designed for second-by-second bursts |
| Reserved Instances | Stable provisioned baseline | Discounts eligible main-cluster capacity | Does not discount scaling clusters |
| Redshift Serverless | Managed, variable demand | RPU-hour pricing, billed per second with a 60-second minimum | Requires a full workload cost comparison |
Use our Redshift Reserved Instances guide and 1-year versus 3-year Redshift commitment comparison when evaluating stable baseline usage.
When to scale, resize, or commit
A simple decision rule can help:Short, unpredictable queue spikes: Concurrency Scaling
Sustained capacity pressure: Elastic Resize or additional baseline capacity
Stable long-term provisioned baseline: Evaluate Reserved Instances
Highly variable workloads that benefit from managed scaling: Compare Redshift Serverless
How to configure and control Concurrency Scaling
1. Identify bursty queues
Start with dashboards, BI queries, or ad hoc workloads where queue time rises during short demand spikes.2. Enable eligible queues
Set Concurrency Scaling mode to auto in WLM.Do not enable every queue automatically. First confirm that its workloads are eligible and genuinely benefit from temporary capacity.
3. Set the scaling-cluster count
max_concurrency_scaling_clusters defaults to 1.AWS documents values from 0 to 10, with the upper limit treated as an adjustable quota. Increasing the value can improve throughput but also consumes free credits faster and can increase paid usage.
4. Create a usage limit
AWS supports daily, weekly, and monthly Concurrency Scaling usage limits.A limit can:
log the event
emit a CloudWatch metric
disable Concurrency Scaling
See the AWS usage-limit API documentation for current behavior.
5. Review actual usage
Use the Redshift console and system views such as STL_QUERY and SVCS_CONCURRENCY_SCALING_USAGE to understand:queue wait time
queries routed to scaling clusters
credit consumption
paid scaling usage
recurring burst patterns
For optimization outside Concurrency Scaling, review our Redshift Advisor recommendations guide.
Redshift Concurrency Scaling checklist
Before enabling or expanding the feature:Confirm the cluster uses EC2-VPC, is not single-node, and meets the supported Region, node-type, and node-count requirements.
Separate queues by workload and enable scaling only where bursts matter.
Verify that important reads and writes meet AWS eligibility requirements.
Include the credit balance and one-minute minimum in your cost model.
Set max_concurrency_scaling_clusters deliberately.
Create a usage limit before production rollout.
Decide whether metric emission is enough or whether the limit should disable scaling.
Compare sustained paid scaling with Elastic Resize, added capacity, or Serverless.
Recheck pricing whenever Region, node type, or node count changes.
Where Usage.ai fits
Concurrency Scaling is a variable On-Demand cost layer. Usage.ai helps optimize eligible, stable Redshift baseline usage, not the Concurrency Scaling rate itself.That means teams can manage short-term burst costs through Concurrency Scaling settings and usage limits, while assessing predictable baseline capacity separately for commitment savings.
With AWS Flex Insured Commitments, eligible teams can access up to 57% savings associated with a three-year AWS commitment without taking on the same long-term commitment exposure. If a qualifying Flex Commitment becomes more expensive than equivalent On-Demand usage, cashback protection can help cover the difference, subject to current program eligibility and terms.
We provide cloud cost optimization and commitment-management services. Product references in this article explain where our commitment analysis may fit and do not guarantee savings.
Amazon Redshift, Concurrency Scaling, Reserved Instances, Elastic Resize, and Redshift Serverless are AWS products. AWS controls their pricing, eligibility, service behavior, and availability. Verify current AWS documentation before purchasing capacity or changing production settings.
Get a Redshift commitment recommendation, coverage estimate, and downside scenario based on stable usage.
Frequently asked questions
How much does Redshift Concurrency Scaling cost?
Provisioned clusters use earned credits first. After those credits are exhausted, AWS charges the On-Demand rate for each scaling cluster based on its billable usage. Each activation has a one-minute minimum.
Do Redshift Concurrency Scaling credits expire?
AWS says credits remain available while the cluster continues to exist. Each cluster can accumulate up to 30 hours, and credits stay with the cluster that earned them.
Does Concurrency Scaling support writes?
Yes, for supported operations on eligible RG and RA3 provisioned clusters. Examples include COPY, INSERT, DELETE, UPDATE, CTAS, and VACUUM. Other operations and table configurations may be ineligible.
How can teams prevent unexpected Concurrency Scaling charges?
Control simultaneous clusters with max_concurrency_scaling_clusters, configure usage limits, monitor credit consumption, and route only appropriate WLM queues. Use the disable action if you need the configured usage limit to stop further Concurrency Scaling for that period.
Is Concurrency Scaling free with Redshift Serverless?
Redshift Serverless does not have a separate Concurrency Scaling charge. Serverless compute is priced in RPU-hours and metered per second with a 60-second minimum, so automatic scaling still contributes to total compute cost.