New See exactly what you're overpaying AWS in under 60 seconds. Try the Calculator for free →

Redshift Concurrency Scaling Pricing: Free Credits, a Billing, and Cost Controls

Amazon Redshift Concurrency Scaling adds temporary capacity during spikes, with free credits first and On-Demand billing after they run out.
Picture of Debesh Singh
Principal FinOps Practitioner

Debesh Singh

Principal FinOps Practitioner
October 5, 2026

·

20 min read
Redshift Concurrency Scaling Pricing: Free Credits, a Billing, and Cost Controls
In this article
Key takeaways
1
Credits accrue hourly, up to one hour per day, and stay with the cluster that earned them.
2
Paid usage follows the On-Demand rate for the main cluster's node type and node count.
3
Charges apply while a scaling cluster serves queries, with a one-minute minimum per activation.
4
WLM routing, cluster limits, and usage limits help control performance and cost.
5
Write scaling supports selected operations on eligible RG and RA3 provisioned clusters.
6
Reserved Instances reduce eligible baseline provisioned cost but do not discount Concurrency Scaling charges.
Redshift Concurrency Scaling is designed for short bursts of demand, but its cost depends on how quickly free credits are consumed and how long temporary scaling clusters stay active. Understanding the billing model, eligibility rules, and usage controls helps teams avoid turning occasional bursts into recurring spend.

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

Write Concurrency Scaling is available only on supported RG and RA3 configurations. Queries using temporary tables, interleaved sort keys, certain system tables, Python or Lambda UDFs, and some restricted external resources may not be eligible.

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

A supported node family alone does not guarantee that a specific cluster configuration is eligible.

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

The 30-hour limit is a maximum credit balance, not a daily allowance.

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:
($33.66 ÷ 3,600) × 300 × 2 = $5.61
The resulting Concurrency Scaling charge is $5.61.

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.
Practical callout: A Reserved Instance discount applies to eligible baseline provisioned capacity, not paid Concurrency Scaling. AWS calculates scaling charges using the equivalent On-Demand rate, so model baseline and burst costs separately.

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
If paid scaling appears frequently, compare the burst bill against resizing your cluster or changing the deployment model.

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

If Concurrency Scaling becomes recurring paid usage rather than occasional burst capacity, revisit the underlying cluster design before simply increasing the scaling-cluster limit.

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

The distinction matters. Logging records the breach, and the CloudWatch-metric action emits a metric; neither action stops additional scaling charges. Only the disable action stops Concurrency Scaling for the rest of that usage period.

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 broader guardrails, see our AWS cloud cost governance guide.

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.

If the same workloads share data across warehouses, include Redshift data sharing pricing in your model because cross-Region access can introduce separate variable costs.

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.
Disclosure

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.
BEFORE YOU COMMIT
How much of your Redshift capacity is actually stable?

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.

Share
Facebook
X
LinkedIn
Reddit
See cloud commitment management in action.
More from Usage.ai
Latest from our blogs