Redshift Reserved Nodes: Node Types, Pricing, and the Commitment Risk You Need to Understand First

Redshift is expensive to run on on-demand pricing, and meaningfully cheaper on reserved nodes. That much everyone knows.

What gets glossed over is that Redshift reserved nodes are also considerably less forgiving than reserved instances for most other AWS services. There is no size flexibility, no convertible offering class, and no marketplace to sell reservations you no longer need.

Before you commit tens of thousands of dollars to a 3-year term on a specific node type, those three constraints deserve more than a footnote.

This guide covers Redshift’s current node families, how reserved node pricing actually works, the payment option math, and the specific things you should validate before committing to anything. By the end, you will have a clear picture of both the savings opportunity and the risk you are accepting when you buy into it.

The Node Families: RG, RA3, DC2 — and Which One to Actually Use in 2026

Redshift has gone through a few generations of node types, and the recommendations have shifted materially in recent years. Understanding which family you should be building on matters both for the performance you get and for what reserved node options are actually available to you.

RG: the new recommended family

RG nodes are Graviton-powered and represent the current recommended generation. AWS’s own documentation is direct about this: RG is the node family AWS recommends for new clusters. Compared to RA3 nodes, RG runs data warehouse and data lake workloads up to 2.4x faster, driven by more compute cores, higher memory bandwidth, and lower memory latency. The price per vCPU is 30% lower than RA3.

RG nodes also include an integrated data lake query engine that queries Apache Iceberg tables and other formats directly in Amazon S3, using the cluster’s own compute resources. RA3 clusters use Redshift Spectrum for data lake queries, which is a separate service. For teams doing significant data lake querying, this difference has cost implications — RG eliminates Spectrum per-terabyte scan charges for supported formats.

Reserved nodes are supported for RG. If you are building a new Redshift deployment or planning a migration from RA3, RG should be your starting point.

RA3: still widely deployed, still fully supported for reservations

RA3 was the previous recommended generation before RG, and it remains fully supported with reserved node pricing. RA3 nodes separate compute from storage: compute is what you reserve, and Redshift Managed Storage is billed separately based on actual data stored, regardless of the number of compute nodes provisioned. The managed storage model uses high-performance SSDs for hot data and Amazon S3 for cold data, with automatic tiering.

Three RA3 sizes exist: ra3.xlplus, ra3.4xlarge, and ra3.16xlarge. Reserved node purchasing is available for all three. If you are running an existing RA3 cluster and considering a reserved commitment, the process is the same as for RG — but factor in whether a migration to RG before committing might deliver better price-performance over the reservation term.

DC2: legacy, limited reserved options

DC2 (Dense Compute) nodes use local SSD storage and are the older generation. AWS recommends DC2 only for datasets under 1 TB compressed where you need compute-intensive performance with local storage. Dense Storage (DS2) nodes are no longer available. For any new deployment or migration, AWS’s guidance points to RG or RA3. Reserved node support for DC2 is more limited than for RG and RA3. If you are still on DC2, Elastic Resize can upgrade your cluster to RA3 without requiring a full rebuild.

Serverless: a newer reservation option

Redshift Serverless lets you run queries without managing a provisioned cluster. AWS added a reserved purchasing option for Serverless as well. Serverless reservations can be purchased at a payer account or linked account level, with multiple linked accounts or serverless workgroups consuming the purchased RPUs (Redshift Processing Units).

The savings structure is similar in concept to provisioned reserved nodes, committing to a usage level in exchange for a discount versus on-demand Serverless rates. This guide focuses primarily on provisioned clusters, but if your team is on Serverless and running consistent workloads, the Serverless reservation option deserves a separate cost evaluation.

Also read: RDS Reserved Instances: the complete guide to commitment mechanics across all RDS engines

How Redshift Reserved Node Pricing Works

The basic concept is familiar if you have used reserved instances on EC2 or RDS: you commit to paying for a specific node type for 1 or 3 years, and in exchange you get a lower hourly rate than on-demand pricing. But the specifics of how Redshift implements this differ from other services in ways that matter.

What you are actually buying

When you purchase a Redshift reserved node, you are buying a pricing discount for a specific node type in a specific region. You are not pre-provisioning a cluster or reserving capacity in the traditional sense. The reservation applies to any running compute node of the matching type in the matching region, up to the number of nodes reserved. If you run more nodes than you have reserved, the excess runs at on-demand rates.

The leader node is always free in Redshift. You never reserve or pay for the leader node. Only compute nodes count for billing and reservation purposes. A two-node cluster has one leader node (free) and two compute nodes (billed and reservable).

On-demand pricing as the baseline

On-demand pricing is billed per compute node per hour, with no commitment. AWS documentation describes it as the most expensive but most flexible option: you pay only for nodes in a running cluster, and if you shut down or delete the cluster, charges stop immediately. On-demand rates vary significantly by node type and region. A single ra3.4xlarge on-demand in US East can run between approximately $2,350 and $3,800 per month depending on the region. At that scale, even a modest reserved discount adds up quickly.

The three payment options

Redshift reserved nodes follow the same three-tier payment structure as most AWS reserved purchases.

No Upfront: you pay nothing upfront and commit to a fixed hourly rate over the reservation term. No Upfront is available only for 1-year terms in Redshift — it cannot be combined with a 3-year commitment. Savings compared to on-demand are meaningful but the smallest of the three options, typically in the range of 20-30% depending on node type and region.

Partial Upfront: you pay a portion of the total commitment cost at purchase, and the remainder is billed at a lower hourly rate over the term. Available for both 1-year and 3-year terms. Savings are typically in the 40-50% range, again depending on node type and region.

All Upfront: you pay the full reservation cost at purchase, with no ongoing hourly charges for the reserved capacity. Available for both 1-year and 3-year terms. This option delivers the deepest discount, up to approximately 75% off on-demand rates for a 3-year All Upfront commitment in favorable regions. The gap between All Upfront and No Upfront in Redshift is smaller than many people expect — typically 3-5 percentage points — which means the cash flow cost of paying everything upfront often outweighs the incremental discount.

Verify current exact rates for your specific node type and region at aws.amazon.com/redshift/pricing/ before comparing payment options. The rates differ meaningfully by region, and the discount percentages above are directional rather than exact.

One thing the AWS documentation calls out explicitly: for All Upfront and Partial Upfront in Redshift, the gap in savings between those options and No Upfront is relatively small — around 3-5% depending on node type and region. If preserving cash flow matters to your business, No Upfront on a 3-year term delivers most of the savings while keeping capital free. The decision changes if you have specific finance or accounting reasons to prefer a capital expense over an operational one.

3-year vs 1-year terms

A 3-year term provides a meaningfully deeper discount than a 1-year term. Depending on the node type and region, 3-year All Upfront can save close to 60-75% compared to on-demand, while 1-year terms typically land in the 40-50% range for All Upfront. The additional commitment is significant — three years is a long time in a data infrastructure landscape that moves quickly. The question worth asking is whether your Redshift architecture, node type choice, and cluster size are genuinely stable for the next 36 months. Given that Redshift introduced the RG family in 2025 and has been actively evolving the platform, a 1-year term with optional renewal may be more defensible than locking in 3 years on a node type that could have a better successor before the term expires.

The Constraints That Make Redshift Reservations Higher-Stakes Than Most

If you have bought reserved instances for EC2 or RDS before, you are probably used to having at least some flexibility in how the discount applies. Redshift is different, and the differences are not minor.

No instance size flexibility

For open-source RDS engines like MySQL and PostgreSQL, a reserved instance discount applies across different sizes within the same instance family. An r6g.xlarge RI covers two r6g.large instances or half an r6g.2xlarge, based on normalized units. Redshift has no equivalent mechanism. A reservation for an ra3.4xlarge covers only ra3.4xlarge nodes — it does not apply to ra3.xlplus or ra3.16xlarge nodes of the same family. If you reserve for one size and your cluster requires a different size, the reservation is stranded and you pay on-demand rates for the actual running nodes until the term expires.

This makes right-sizing before purchasing a reserved node considerably more important than it is for EC2 or RDS. You need to be confident in the specific node type and size before committing, not just the family.

No convertible offering class

EC2 Reserved Instances have a Convertible type that lets you exchange one instance type for another (at equal or greater value) during the term. If your workload requirements shift from c5 to m5, you can adapt the reservation. Redshift has no convertible equivalent. Once you commit to ra3.4xlarge, there is no mechanism to convert to ra3.16xlarge or to RG nodes if your needs change. You are locked to the exact node type for the full term.

No AWS Reserved Instance Marketplace

For EC2, if you have reserved capacity you no longer need, you can list it on the AWS Reserved Instance Marketplace and potentially recover some of the remaining value. Redshift reserved nodes are explicitly excluded from the marketplace. If you over-provision Redshift reservations or your architecture changes in a way that makes them redundant, there is no resale path. The only option is to wait out the term while paying for capacity that is not being used productively.

The combination of no size flexibility, no convertible class, and no marketplace makes Redshift reserved nodes among the least forgiving commitment instruments in AWS. The upside is real — up to 75% off is meaningful for expensive nodes. The downside is that a miscalculated purchase can cost tens of thousands of dollars in wasted committed spend over a 3-year term with no practical exit. That is the core argument for purchasing conservatively at a shorter term initially, validating that the node type and size hold steady, and then committing more aggressively only after your architecture has proved stable.

Consolidated billing applies

If you have AWS Consolidated Billing enabled, Redshift reserved node discounts apply across all running nodes in your linked accounts, up to the number of nodes reserved. This means if you purchase reservations at the payer account level, the discount applies to matching node types running in any linked account, not just the account where the reservation was purchased. For organizations with multiple AWS accounts running Redshift, this shared discount mechanism is an advantage and can improve effective utilization of a reservation portfolio.

Also read: AWS Database Savings Plans: the flexible alternative to per-engine reserved instances

What Storage Costs Look Like Separately

For RG and RA3 nodes, storage is always billed separately from the compute reservation. When you buy reserved nodes, you are buying a discount on compute hours only. The Redshift Managed Storage (RMS) charges accrue based on the actual amount of data stored, measured hourly and billed per GB-month. This is true whether or not the compute nodes are reserved.

The benefit of the RG and RA3 architecture is that you can size your compute cluster for the query performance you need and scale storage independently as your data grows. You do not have to add compute nodes just because you have more data. The cost implication is that your Redshift bill has two components even after you purchase reserved nodes: the discounted compute rate plus the current data volume multiplied by the managed storage rate for your region.

Backup storage is handled separately: there is no additional charge for backup storage up to 100% of your provisioned storage. For example, a cluster with 10 TB of provisioned storage gets 10 TB of backup storage in S3 at no extra charge. Manual snapshots beyond that free tier do carry storage charges.

For DC2 nodes, storage is included in the compute charge — DC2 uses local SSD storage priced within the node hourly rate rather than the separate managed storage model. If you are comparing a DC2 reservation against a RG or RA3 reservation, factor this difference into the cost model.

Concurrency Scaling: The Variable Charge Reserved Nodes Don’t Cover

Concurrency Scaling is Redshift’s mechanism for handling traffic spikes without provisioning additional permanent nodes. When query queue depth grows, Redshift can automatically add transient compute capacity to maintain performance. Each cluster earns up to one hour of free Concurrency Scaling credits per day. AWS documentation notes this is sufficient for 97% of customers. Beyond the free tier, you pay the per-second on-demand rate for Concurrency Scaling usage.

Reserved nodes do not cover Concurrency Scaling charges. The reservation applies to your base provisioned cluster. If your workload regularly exhausts the one-hour daily credit and incurs additional Concurrency Scaling charges, those are billed separately at on-demand rates regardless of your reserved node coverage.

For most teams, Concurrency Scaling charges are a minor or zero line item. But if your workload has pronounced peaks that frequently exceed the free tier, modeling Concurrency Scaling charges separately from your reserved node cost is worth doing before assuming the reservation covers your full Redshift bill.

The Process for Getting a Redshift Reserved Purchase Right

Given how unforgiving Redshift reservations are, the pre-purchase process matters more here than for almost any other AWS commitment. The sequence that works:

Optimize first, commit second

This is the same principle that applies to EC2 and RDS right-sizing, but it is even more important for Redshift because there is no size flexibility to bail you out. Before purchasing reserved nodes, ensure your queries are optimized, your workload management configuration is tuned, and your cluster size has stabilized. A cluster that is still being actively tuned is not a good candidate for a long-term commitment.

The specific metrics to validate: CPU utilization, disk I/O, network throughput, and query queue depth over a meaningful observation window — at least 30 days, ideally 60-90 days that includes your peak workload periods. If you have seasonal peaks, make sure the observation window captures them. The node type you reserve should be able to handle your expected workload over the full reservation term without requiring a resize.

Start with 1-year No Upfront if uncertain

If this is your first Redshift reserved purchase, or if you have recently changed node types, a 1-year No Upfront reservation gives you meaningful savings from day one without requiring upfront cash and without locking in a 3-year commitment to a potentially wrong configuration. If the cluster runs stably for a year at the same node type and size, you have 12 months of evidence to support a more aggressive 3-year All Upfront commitment at renewal.

The discount difference between 3-year and 1-year is real, but it is not so large that it is worth taking on the risk of a wrong 3-year commitment just to capture it. The additional savings from going 3-year versus 1-year typically represent a few percentage points. The cost of committing to the wrong node type for 3 years at Redshift’s price point can be tens of thousands of dollars.

Account for the RG migration question

If you are currently on RA3 and evaluating whether to reserve RA3 nodes or migrate to RG first, the migration question should be answered before the reservation is purchased, not after. RG delivers up to 2.4x the performance of RA3 at 30% lower price per vCPU. If your cluster is a good candidate for RG, committing to 3 years of RA3 reserved nodes before completing that evaluation may lock you into a more expensive, lower-performance configuration for longer than necessary.

The migration from RA3 to RG uses the same snapshot and restore process as other Redshift migrations. AWS provides migration wizards in the console and supports Elastic Resize for minimal-downtime transitions. For teams on RA3 who have not yet evaluated RG, running the comparison before making any reservation commitment is time well spent.

How Usage.ai Handles Redshift Reserved Nodes

Redshift is one of the services where the commitment risk is high enough that getting the recommendation wrong is genuinely expensive. Usage.ai approaches Redshift reserved node purchasing with the same framework it applies to all commitment instruments, but with a few Redshift-specific additions.

Node type and size validation: before generating a Redshift reserved node recommendation, Usage.ai verifies that the running cluster has maintained the same node type, node count, and configuration for a minimum observation window. A cluster that has been modified recently — resized, retyped, or migrated — does not receive a reservation recommendation until the new configuration has stabilized. This prevents recommending a reservation for a configuration that is still changing.

RG migration check: for clusters currently running on RA3, Usage.ai surfaces the RG migration opportunity alongside any reservation recommendation. The pricing data for RG reserved nodes is compared against RA3 reserved nodes to show whether migrating before committing would improve the effective savings rate over the term.

Conservative sizing: Redshift reserved node recommendations are sized to the stable floor of compute usage, not the average and not the peak. Given that there is no size flexibility to absorb an over-commitment, the recommendation is designed to have a high probability of being fully utilized throughout the term rather than optimizing for the theoretical maximum savings.

Buyback guarantee: this is the Usage.ai differentiator that matters most for Redshift specifically. Because Redshift reserved nodes cannot be sold on the Reserved Instance Marketplace and have no flexibility mechanisms, a stranded reservation has no value recovery path under standard AWS terms.

Usage.ai Insured Flex Reserved Nodes include a buyback guarantee: if a reserved node becomes stranded — because the cluster is resized, migrated to a different node family, or decommissioned — the unused commitment is bought back and the value returned as cashback in real money. That changes the risk profile of a Redshift reservation meaningfully. You can commit at the correct level for your current workload without holding back because of what might happen in year two of a three-year term.

$91M+ in savings delivered to 300+ enterprise customers across AWS, Azure, and GCP. Fee is a percentage of realized savings only. No savings, no fee. 30-minute setup, billing-layer access only.

Frequently Asked Questions

1. How much can Redshift reserved nodes save?

Reserved nodes can save up to approximately 40-75% compared to on-demand Redshift node pricing, depending on the node type, region, payment option, and term length. 1-year No Upfront typically saves in the 20-30% range. 3-year All Upfront delivers the deepest discount, approaching 75% for some node types in favorable regions. Verify exact rates for your node type and region at aws.amazon.com/redshift/pricing/ — rates vary significantly by region and change over time.

 

2. Do Redshift reserved nodes include storage?

No, for RG and RA3 node types. Storage is billed separately as Redshift Managed Storage, based on the actual amount of data stored per GB-month, independent of the number of reserved compute nodes. Backup storage up to 100% of provisioned storage is included at no additional charge. For DC2 nodes, local SSD storage is included in the node hourly rate.

 

3. What is the difference between RG and RA3 reserved nodes?

RG nodes are the new Graviton-powered generation that AWS now recommends for new deployments. Compared to RA3, RG runs workloads up to 2.4x faster and costs 30% less per vCPU. RG nodes include an integrated data lake query engine that eliminates Redshift Spectrum charges for supported formats. RA3 nodes remain fully supported with reserved pricing and are the right choice for teams not yet ready to migrate. If you are evaluating a new reservation purchase and have not yet evaluated RG, doing the comparison before committing is worthwhile.

 

4. Can I change my Redshift node type during a reserved term?

No. Redshift reserved nodes have no convertible offering class and no size flexibility. A reservation for a specific node type and size applies only to that exact node type and size. If you change node families or sizes during the term, your existing reservation is stranded and you pay on-demand rates for the new configuration. Redshift reservations also cannot be sold on the AWS Reserved Instance Marketplace, so there is no resale option for stranded capacity.

 

5. Is No Upfront or All Upfront better for Redshift reserved nodes?

The discount difference between All Upfront and No Upfront in Redshift is typically only 3-5 percentage points. All Upfront delivers the deepest discount, but requires paying the full reservation cost at purchase — which for multiple ra3.4xlarge or ra3.16xlarge nodes across a multi-year term can be a significant capital outlay. For most teams, the incremental savings from paying everything upfront do not justify the cash flow impact. No Upfront on a 1-year term is a reasonable starting point for a first reservation, allowing you to capture meaningful savings while preserving capital flexibility until you have 12 months of utilization data to support a more aggressive commitment.

 

6. Does Redshift have a Reserved Instance Marketplace?

No. Unlike EC2 Reserved Instances, Redshift reserved nodes cannot be listed or sold on the AWS Reserved Instance Marketplace. If you no longer need a Redshift reservation you have purchased, there is no mechanism to recover the remaining value by selling it to another AWS customer. This is a meaningful distinction from EC2 and makes the accuracy of your initial purchase more consequential.