Amazon Redshift Pricing: RG vs RA3 vs Serverless Costs

Amazon Redshift pricing has always been tricky to estimate from the pricing page alone. You get rates, but not totals. Now this AWS data warehouse has gotten more complex: Redshift has three provisioned node generations (RG, RA3, and DC2), two deployment models with completely different billing clocks, and a set of savings options that most teams never fully explore. If you're estimating your total AWS bill before deploying or trying to understand why last month's Redshift charge was higher than expected, this article gives you worked monthly totals for three real scenarios and a framework for picking the right model. I've worked through enough surprise Redshift bills to know where the traps hide, and this is the breakdown I wish I'd had when I started sizing clusters.

Here's the short version before we dig in:

• Provisioned clusters bill per compute node per hour; the leader node is always free
• Redshift Serverless bills at $0.375/RPU-hour with per-second granularity and zero charge during idle
• RG nodes (GA May 2026) are 30% cheaper per vCPU than RA3 and eliminate Spectrum scan charges entirely
• Serverless Reservations now offer terms up to 3 years, saving up to 50% vs. on-demand with the All Upfront option added in July 2026
• Three worked scenarios: RA3 provisioned ($10,602/month), RG provisioned ($9,868/month), Serverless dashboarding ($15,120/month compute-only)

All rates are for us-east-1 in USD from the Amazon Redshift pricing page. Other regions differ.

How Redshift Billing Works

The billing clocks run differently between the two models, and several costs apply regardless of which you choose.

The Two Deployment Models and Their Billing Clocks

Provisioned clusters start billing at creation and stop at deletion. If your cluster sits idle at 3 AM, you're still paying. The exception is the pause feature: pausing suspends on-demand compute billing, and only backup storage continues to accrue. Partial hours after a status change (create, delete, pause, resume) are billed in one-second increments.

Redshift Serverless works the opposite way. Billing starts when a query begins running and stops when it completes, is rolled back, or is cancelled. Idle time between queries costs nothing. That's a fundamentally different cost model, and it's why the comparison isn't a simple rate lookup.

Multi-AZ provisioned clusters pay the same per-node hourly rate but for nodes in both availability zones, so the compute bill doubles. No surcharge, just twice the compute.

Shared Costs Across Both Models

Both RG/RA3 provisioned and Serverless share Redshift Managed Storage (RMS) at $0.024/GB-month in us-east-1. DC2 is the exception: its local NVMe SSD is built into the node, so no separate RMS charge applies.

Manual snapshots for RG and RA3 are billed at standard S3 rates. Data transfer between Redshift and S3 within the same region is free for COPY, UNLOAD, backup, and restore. JDBC/ODBC connections from a VPC and cross-region transfers bill at standard rates.

Provisioned Cluster Pricing

Provisioned clusters bill per compute node per hour. The leader node is always included free; your bill is based entirely on compute nodes. Provisioned pricing starts at $0.543/hr for the smallest configurations.

Node Types: RG (New), RA3, and DC2

AWS released RG nodes in May 2026, and by July 2026 had rounded out the lineup to four sizes: rg.large and rg.12xlarge joined the original rg.xlarge and rg.4xlarge. RG instances are powered by AWS Graviton processors, run 30% cheaper per vCPU than RA3, and include an integrated data lake engine that eliminates Spectrum charges. AWS recommends RG for all new workloads. If you're reading an article that doesn't mention them, it's already stale.

RA3 has four node types (ra3.large, ra3.xlplus, ra3.4xlarge, ra3.16xlarge). Only ra3.large and ra3.xlplus support a single-node configuration; ra3.4xlarge and ra3.16xlarge, like every RG size, need a minimum of two compute nodes. That minimum matters for the break-even math further down: a one-node rg.4xlarge cluster isn't something you can actually deploy. Both RG and RA3 now support Multi-AZ. DC2 caps at 1 TB compressed, has no Multi-AZ, and can't disable automated snapshots on the larger dc2.8xlarge size. For any new deployment, skip DC2.

On-Demand Rates and Monthly Math

The AWS pricing page's own worked examples show the node type impact clearly. Both use 4 nodes, 40 TB RMS, 100% uptime, and no Reserved Instances (us-east-1, on-demand).

The RA3 cluster (4 x ra3.4xlarge, 20 TB Spectrum) breaks down as: 4 x $3.26/hr x 730 hr = $9,519.20 compute, plus $983.04 RMS, plus $100.00 Spectrum, totaling $10,602.24/month.

The RG cluster (4 x rg.4xlarge, same data lake) breaks down as: 4 x $3.04267/hr x 730 hr = $8,884.60 compute, plus $983.04 RMS, plus $0.00 for data lake queries (integrated engine, no Spectrum charge), totaling $9,867.64/month.

The RG cluster saves $734.60/month, $8,815/year, from one node type decision before any Reserved Instance savings. Actual bills also include snapshot storage, data transfer, and any concurrency scaling overages.

Multi-AZ: Same Rate, Double the Compute

There's no Multi-AZ surcharge; you pay the same per-node rate for nodes in both zones. For the RA3 configuration above (4 x ra3.4xlarge), enabling Multi-AZ brings the compute line from $9,519.20 to approximately $19,038.40/month. Multi-AZ deployment supports RG and RA3 node types that use Redshift Managed Storage; DC2, with its local NVMe storage, is not eligible. Check the Amazon Redshift pricing page for current regional availability before planning a Multi-AZ deployment.

Pausing Clusters to Suspend Compute Billing

Pausing a provisioned cluster stops on-demand compute billing; only storage costs continue. It's effective for dev/test environments, batch-window clusters, and anything that doesn't need to run continuously.

A few important caveats: pausing takes approximately 15 minutes and creates a snapshot; DC2 clusters with no-backup tables don't retain those tables after resume (RG and RA3 handle this safely); and if you hold a Reserved Instance, RI charges continue while the cluster is paused. Pausing does not suspend RI billing.

Redshift Managed Storage (RMS) Pricing

RMS applies to both RG and RA3 across provisioned and serverless deployments at $0.024/GB-month in us-east-1, regardless of whether your data sits on fast local SSDs or has spilled to S3.

Usage is calculated hourly and converted to GB-months using 720 hours as one billing month. The AWS pricing page example: store 100 GB for the first 15 days of a month, then scale to 100 TB for the remaining 15 days:

• First 15 days: 100 GB x 15 days x 24 hr = 36,000 GB-hours
• Final 15 days: 100 TB x 1,024 GB/TB x 15 days x 24 hr = 36,864,000 GB-hours
• Total: 36,900,000 / 720 = 51,250 GB-months x $0.024 = $1,230

That mid-month data growth hits harder than most engineers expect. Growth on day 20 of a 30-day month still gets counted for the remaining 10 days of the billing period.

Automated snapshots for RG and RA3 are included in RMS billing with no separate charge. Manual snapshots bill at S3 rates and persist until you delete them, including after cluster deletion.

Redshift Serverless Pricing

Redshift Serverless bills at $0.375 per RPU-hour in us-east-1, per second with a 60-second minimum per query or transaction. No compute charge during idle periods. Starting price is $1.50/hr at the 4 RPU minimum (1 RPU = 16 GB memory), which became available in most regions as of May 2026.

The RPU-hour charge includes automatic scaling, concurrency scaling, S3 data lake queries (Parquet, Apache Iceberg, and other formats), and federated queries. What it excludes: RMS at $0.024/GB-month, manual snapshots, and data transfer.

RPU-Hours Explained

An RPU is Redshift's serverless compute unit. You set base capacity (the minimum RPUs the workgroup holds in reserve) and MaxRPU (the scaling ceiling). Base range is 4 to 1,024 RPU; MaxRPU can reach 5,632. Setting MaxRPU to -1 removes the cap, which is a fast way to get a surprise bill.

The per-query cost formula: (seconds x RPU x $0.375) / 3,600. A 10-minute query at 128 RPU costs (600 x 128 x $0.375) / 3,600 = $8.00 for that query alone.

Scale-down after load drops is not immediate. The cluster may hold a higher RPU level for a few minutes, so your "idle" period after a peak can carry some compute cost.

Serverless Billing Gotchas

A few patterns show up as unexpected charges on serverless bills:

1. Open transactions: A BEGIN TRAN without COMMIT or ROLLBACK keeps RPUs consumed continuously. The idle transaction timeout is 6 hours, so an abandoned session can bill for hours. Set explicit SESSION TIMEOUT values.
2. Cancelled queries: Still billed for the time they ran before cancellation.
3. Connection pool heartbeats: SELECT 1 health checks from connection pools are billed as compute. Reduce frequency or disable validation queries in your pool config.
4. Scale-down lag: After a busy period, the cluster may stay at a higher RPU level for several minutes before winding down.

The serverless billing documentation covers these mechanics in detail. Worth reading before buying a Serverless Reservation.

Worked Monthly Example: Dashboarding App

Here's the AWS pricing page's dashboarding example broken down by period (us-east-1):

Daily total: 1,344 RPU-hours x $0.375 = $504/day. Monthly estimate (30 days): $15,120 compute-only. RMS is billed separately on top. The 9-11 AM and 2-3 PM peaks drive most of the cost; a lower-concurrency workload scales down proportionally.

Provisioned vs. Serverless: Finding Your Break-Even Point

The pricing pages quote different units, so there's no way to compare them without picking one deployable configuration and running the actual numbers. A single rg.4xlarge node isn't that configuration: RG has no single-node option, so the smallest rg.4xlarge cluster you can create has 2 nodes, and the pricing page's own worked examples (the ones this article uses above) run 4.

Take the 4-node rg.4xlarge cluster from the worked example earlier in this article: $8,884.60/month in on-demand compute (4 x $3.04267/hr x 730 hr). To find the RPU level where continuous Serverless spend matches that number, solve for R in R x $0.375/hr x 730 hr = $8,884.60:

R = $8,884.60 / ($0.375 x 730) = ~32.5 RPU

If a Serverless workgroup ran nonstop, 24 hours a day, at a steady 32-33 RPU, its monthly compute bill would land close to what that 4-node rg.4xlarge cluster costs on-demand. RMS is priced identically for both models at the same data volume, so it cancels out of this comparison and isn't included.

This isn't a claim that 32 RPU equals four rg.4xlarge nodes in compute capacity; AWS publishes no such equivalence, and none should be assumed. It's a cost-equality check for one specific, deployable configuration running continuously. Change the node count, the node type, or the hours of actual daily use, and the break-even RPU level moves with it. What stays true regardless of the specific numbers: nonstop 24/7 usage almost always favors provisioned, because Serverless has nothing to discount when there's no idle time to skip. The moment your workload has real idle hours, that math shifts back toward Serverless. Run the five-step framework below with your own workload before deciding, since this single scenario won't match yours exactly.

The Break-Even Framework

Run this five-step check for your workload:

1. Estimate daily active query hours (hours when queries actually run, not just cluster availability)
2. Estimate typical RPU level during those hours (run a trial and check the Serverless dashboard)
3. Monthly serverless compute: (daily active seconds x RPU x $0.375) / 3,600 x 30
4. Monthly provisioned on-demand: node count x hourly rate x 730
5. Compare. If provisioned wins, apply RI savings to find the committed price.

Rule of thumb: under 8-10 active hours per day at moderate RPU levels, serverless on-demand is competitive. Running queries most of the day, provisioned with RIs wins convincingly.

Decision Checklist

Choose Serverless for intermittent or unpredictable workloads, zero-ops requirements, dev/test, and situations where you can't yet establish steady-state RPU consumption.

Choose Provisioned for steady 24/7 workloads with a known data size and query pattern, when you want RI savings (up to 76% all-upfront 3-year), when you need Multi-AZ, or when you need more than 1,024 RPU base capacity.

Migrate RA3 to RG whenever possible. The 30% price-per-vCPU reduction and Spectrum elimination make it the single highest-impact provisioned cost lever. Migrate via Snapshot & Restore, Elastic Resize, or Classic Resize.

Start with the free trial: $300 in serverless credits (90-day expiry) or 750 hours/month for 2 months on provisioned in regions without Serverless.

Savings Options: RIs, Serverless Reservations, and Spectrum Control

Once you know which model fits, the next question is whether to commit for savings.

Reserved Instances for Provisioned Clusters

Redshift Reserved Instances (RIs) are a billing discount, not a resource reservation. You still need your cluster running; the RI reduces the per-hour rate. RI discounts are shared across accounts in a consolidated billing setup.

Savings ranges: No Upfront ~20%, Partial Upfront up to 41-73%, All Upfront up to 42-76% (both depending on 1-year vs. 3-year term). For specific dollar rates by node type, check the Amazon Redshift pricing page directly.

Two caveats that rarely get mentioned. First, resizing to a different node type voids existing RI coverage. On-demand rates apply until you buy a matching RI for the new type. I've seen teams commit to a 3-year RA3 RI, need to resize, and pay on-demand for months while sorting out the replacement. Lock in your node type before committing.

Second, pausing does not suspend RI billing. The RI hourly rate continues while your cluster is paused. Redshift RIs are also separate from AWS Savings Plans and AWS Database Savings Plans; those plans do not apply to Redshift.

RG nodes launched with No Upfront RIs only; AWS added Partial Upfront and All Upfront options for RG in June 2026, so all three payment plans across 1-year and 3-year terms now match RA3.

Serverless Reservations

Serverless Reservations are easy to miss. Introduced April 2025 with 1-year terms; 3-year terms added February 2026, with an All Upfront payment option for that 3-year term following in July 2026. If you're running consistent serverless workloads, this is the first optimization most teams skip.

Savings vs. on-demand: 1-year No Upfront up to 20%, 1-year All Upfront up to 24%, 3-year No Upfront up to 45%, 3-year All Upfront up to 50%.

The key trap: unlike serverless on-demand (pay only for active compute), a Reservation bills continuously from purchase date, 24 hours a day, metered per second. It behaves the same as a provisioned RI. Overages above the reserved RPU level pay on-demand rates. Reservations are purchased at the payer account level, shared across linked accounts, cannot be cancelled or modified, and free trial credits do not apply.

Buy only after establishing steady-state RPU patterns. Check the Serverless dashboard or Cost Explorer for 2-4 weeks of production data. Under-reserving means on-demand overages; over-reserving locks in spend you can't refund.

Redshift Spectrum: Per-TB Scan Costs and How to Cut Them

Spectrum lets RA3 provisioned clusters query S3 directly at $5.00/TB scanned in us-east-1, rounded to the next MB, with a 10 MB minimum per query. DDL statements and failed queries are not charged.

The format choice has a dramatic effect on the same 4 TB source dataset:

*AWS computes this row from the source-to-columnar formula: 1 TB Parquet x (1/100 columns) x $5.00/TB = $0.05.

That's a 400x cost range on the same data. Parquet with column pruning is nearly free for narrow queries; uncompressed text is a budget hazard. If you're using RA3 Spectrum heavily for ad-hoc S3 queries, also check whether Athena's per-query pricing model fits your pattern better.

RG eliminates Spectrum entirely via its integrated data lake engine. For heavy Spectrum users, migrating from RA3 to RG removes that per-TB line item permanently.

Concurrency Scaling Credits and Overages

Each active provisioned cluster earns 1 hour of free Concurrency Scaling credits per 24 hours, accumulating up to 30 hours. AWS says free credits cover 97% of customers. Overages bill at the per-second on-demand rate for your node type and count, with a 1-minute minimum per transient cluster activation.

To illustrate: the AWS pricing page example uses a 10 rg.4xlarge cluster in us-west-1 at $33.66/hr. Two transient clusters each used 5 minutes beyond free credits: $0.00935/sec x 300 sec x 2 clusters = $5.61 overage. That's a us-west-1 example; your rate differs by region and node type. As of May 2026, Concurrency Scaling also covers COPY operations.

Set usage limits (daily, weekly, monthly, in minutes) with automated disable actions to cap exposure for the 3% of workloads that regularly exceed free credits.

Costs the Pricing Page Buries

These costs tend to appear on the bill without much warning. Each category below has caught teams off guard, sometimes weeks after they thought they had shut everything down.

Backup and Snapshot Costs

Automated snapshots for RG and RA3 are included in RMS billing at no separate charge. Retention is configurable from 1 to 35 days; you can't disable automated snapshots on RG or RA3.

Manual snapshots bill at S3 rates and persist until you delete them, even after cluster deletion. I've seen teams delete a cluster to stop billing, then discover manual snapshots from months ago still generating charges. Delete them before decommissioning.

DC2 can disable automated snapshots (set retention to 0). For DC2-specific backup cost details, check the pricing page directly. Cross-region snapshot copy adds data transfer charges (incremental data only, billed in the source region).

For Serverless: automatic recovery points for the last 24 hours are free at 30-minute granularity. Recovery points older than 24 hours incur charges within RMS.

Data Transfer

In-region S3 data movement is free for COPY, UNLOAD, backup, and restore. Everything else is billed. JDBC/ODBC connections from within a VPC generate data transfer charges. This catches teams querying Redshift from EC2 or Lambda in the same region but different VPC. Enhanced VPC Routing redirects UNLOAD through the VPC; if your S3 bucket is in a different region, that UNLOAD generates charges. Data sharing across regions is billed in the consumer region.

Free Trial Limits

The Serverless free trial gives you $300 in credits per AWS account, expiring 90 days after your first workgroup creation (or when credits run out, whichever comes first). Usage doesn't appear in the billing console during the trial; check the SYS_SERVERLESS_USAGE system view instead. Serverless Reservation charges are not covered by trial credits; those only apply to on-demand RPUs.

In regions without Serverless: 750 hours/month for 2 months on a provisioned cluster, then standard on-demand rates.

Cost Optimization Playbook

Here's the actual Redshift cost optimization work, organized by where your bill is coming from. Each track maps directly to the billing dimensions covered above, so skip to the section that matches your deployment model.

For Provisioned Clusters

1. Migrate RA3 to RG: 30% lower price per vCPU plus Spectrum elimination. That's $734/month on the worked example above, before RI savings. Migrate via Snapshot & Restore, Elastic Resize, or Classic Resize.
2. Buy Reserved Instances after locking in your node type: All Upfront 3-year saves up to 76%. Resizing after purchase voids RI coverage; on-demand rates apply until you buy a new RI. The Well-Architected Analytics Lens best practice on managing analytics infrastructure cites RI commitment and pause/resume as the primary cost levers.
3. Schedule pause/resume for non-continuous clusters: Dev/test, reporting clusters, batch-window workloads. Only storage accrues while paused.
4. Use Elastic Resize or Resize Scheduler: Add nodes for peak hours, reduce for off-peak. You only pay for full-size compute during the hours you need it.
5. Set Concurrency Scaling usage limits: Define daily/weekly/monthly limits with automated disable actions as a backstop.
6. Right-size before committing: Use the Redshift console's Help me choose sizing guide. Oversized DC2 clusters are among the most common waste patterns.

For Redshift Serverless

1. Start at the lowest base RPU that meets performance: 4 RPU is the right starting point for dev/test and low-volume workloads in most regions now.
2. Set a MaxRPU ceiling on every workgroup: The default (-1) is uncapped. Set a realistic ceiling based on expected peak and validate with load testing.
3. Set RPU-hour usage limits: Daily, weekly, and monthly budgets with automated alert or turn-off actions guard against runaway costs.
4. End open transactions: Every open BEGIN TRAN without COMMIT/ROLLBACK is billing you. The idle transaction timeout is 6 hours, so set your own SESSION TIMEOUT values lower.
5. Optimize connection pool health checks: SELECT 1 validation queries are billed compute. Reduce frequency or disable them.
6. Buy Serverless Reservations after 2-4 weeks of steady-state data: 3-year commitments save up to 45% no-upfront or up to 50% all-upfront. Don't buy before you know your baseline.

For Spectrum Workloads

1. Compress your S3 data: GZIP or Snappy gives roughly 4:1 compression, cutting scanned bytes and cost by about 75%.
2. Convert to columnar formats: Parquet or ORC let Spectrum scan only the required columns. For wide tables, this is the highest-impact change.
3. Filter on partition keys in every Spectrum query: Without a partition filter, Spectrum scans everything.
4. Migrate to RG to eliminate Spectrum entirely: For heavy Spectrum users, this is the highest-impact long-term option.

Frequently Asked Questions

What to Do Next

Amazon Redshift pricing has five real variables: compute model, node type, commitment level, storage volume, and Spectrum usage. Most surprise bills trace to one of three mistakes: provisioned clusters sitting idle without pause schedules, RA3 clusters running heavy Spectrum workloads instead of migrating to RG, or buying Serverless Reservations before establishing steady-state RPU consumption.

The three decisions that matter most before you commit: pick RG over RA3 for any new or migrated workload; match your commitment to your usage pattern (RIs for steady-state provisioned, Reservations for consistent serverless, on-demand for everything variable); and set MaxRPU and usage limits on every serverless workgroup before it hits production.

If you want to model your specific configuration before committing, the Redshift Pricing Calculator handles provisioned and serverless side by side. Once your Redshift costs are under control, the next question is how to keep them from drifting back, and that's where shifting FinOps left into your IaC review process becomes the logical next step.

If you're working through an RA3-to-RG migration or weighing provisioned against serverless, I'm curious where your break-even point lands. Drop a note in the comments below.