Redshift Cross-Region Snapshots: Backup and DR Cost Breakdown

Most Redshift cross-region snapshot discussions focus on the how: how to enable cross-region copy, how to configure the retention period, how to restore from a DR snapshot. The cost discussion usually gets a single sentence: ‘standard data transfer rates apply.’ That is technically accurate and operationally useless.

The full cost of a cross-region DR strategy for Redshift involves three separate billing components that operate independently and compound over time. Getting any one of them wrong — particularly the Fast Snapshot Restore charge — can result in meaningful unplanned spend that doesn’t show up on the bill until the end of the month, long after the decision to enable it was made.

This guide covers exactly what each cost component is, how the billing mechanics work by node type, and the specific operational decisions that determine whether your DR costs are controlled or growing quietly in the background.

How Redshift Snapshot Billing Works in the Source Region First

Before getting into cross-region costs, it helps to understand the source region billing clearly because cross-region costs layer on top of it.

Automated snapshots: free up to 35 days

Amazon Redshift automatically takes incremental snapshots that track changes to the cluster since the previous automated snapshot. Automated snapshots are offered at no charge and can be retained for a maximum of 35 days. These are the snapshots Redshift takes on its own schedule — by default, every 8 hours or after every 5 GB of data change. Source: docs.aws.amazon.com/redshift/latest/mgmt/working-with-snapshots.html DIRECT QUOTE.

You cannot keep automated snapshots beyond 35 days under the automated retention policy. If you want a point-in-time backup retained for longer, you have two options: increase the retention period (which at some point crosses into charged storage) or convert the automated snapshot to a manual snapshot, which can be retained indefinitely.

Manual snapshots: charged until deleted

Manual snapshots — those you create yourself via the console, CLI, or API — are charged from the moment of creation until they are explicitly deleted. They do not expire automatically unless you configure a snapshot lifecycle policy. The billing is per GB-month based on unique data blocks, not per snapshot per the full logical size.

Snapshots are billed until they expire or are deleted, including when the cluster is paused or deleted. Source: aws.amazon.com/redshift/pricing/ DIRECT QUOTE. This means if you delete a Redshift cluster but forget to delete its manual snapshots, the snapshot storage charges continue.

Incremental billing: what unique data blocks means in practice

Redshift snapshots are incremental by nature and track changes to the cluster since the previous snapshot. Shared blocks across multiple snapshots are counted only once. This means you pay only for the actual incremental data retained for your snapshots, not the full size of each snapshot. Source: aws.amazon.com/redshift/pricing/ DIRECT QUOTE.

This has a meaningful practical implication. If your cluster stores 10 TB and you take 10 daily snapshots, you are not paying for 100 TB of snapshot storage. You are paying for the 10 TB of unique data blocks across all 10 snapshots. If your daily data change rate is 100 GB, your 10-snapshot window costs roughly 10 TB (the initial snapshot) plus 900 GB of incremental changes, not 100 TB.

This incremental billing model is why retention period decisions matter: adding more days of retention adds the incremental change volume for those additional days, not the full cluster size per day.

Also read: Redshift Concurrency Scaling Pricing: Free Credits, How Burst Billing Works

Snapshot billing by node type

The specific billing mechanism differs by node type, and this matters for cross-region cost calculations.

For RA3 nodes: data stored on RA3 clusters is part of Redshift Managed Storage (RMS) and is billed at RMS rates. Manual snapshots taken for RA3 clusters are billed separately as backup storage at standard Amazon S3 rates. For example, if your RA3 cluster has 10 TB of data and 30 TB of manual snapshots, you are billed for 10 TB of RMS and 30 TB of backup storage. Source: aws.amazon.com/redshift/pricing/ DIRECT QUOTE.

For RG nodes and Redshift Serverless: manual snapshots are billed based on the total unique data blocks across all active snapshots at the snapshot rate for your region. This is a unified billing model rather than the separate RMS plus backup storage model used for RA3.

For DC2 nodes: storage is included in the cluster and not billed separately, but backups are stored externally in Amazon S3. Backup storage beyond the provisioned storage size on DC2 clusters is billed at standard S3 rates.

Cross-Region Snapshot Costs: The Three Components

Component 1: Inter-region data transfer

When a snapshot is copied from a source region to a destination region, you pay standard AWS data transfer out rates for the amount of data transferred. The rate for most region pairs involving US East is approximately $0.02/GB, but rates vary depending on the source and destination region combination. Transfers between certain region pairs carry higher rates. Source: verified from cloudchipr.com analysis citing AWS official data transfer rates for Redshift snapshot copy at $0.02/GB outbound.

Because Redshift snapshots are incremental, the data transfer charge for each automated snapshot copy is based on the changed data blocks since the last snapshot, not the full cluster size. The first cross-region copy of a snapshot (or the first copy after a long gap) transfers more data than subsequent copies of incremental snapshots. This makes the ongoing monthly transfer cost substantially lower than the initial copy cost for most clusters.

Verify the exact data transfer rate between your specific source and destination regions at aws.amazon.com/ec2/pricing/on-demand/ under the Data Transfer section. The general AWS data transfer page lists inter-region rates by region pair.

Component 2: Snapshot storage in the destination region

Once copied, the snapshot lives in the destination region as a manual snapshot and incurs standard Redshift backup storage charges per GB-month at the destination region’s rate. The destination region’s storage rate may differ from the source region’s rate, so model costs using the destination region’s rates specifically.

A key billing behavior: the storage retention period for copied snapshots in the destination region is set separately from the retention period in the source region. When you configure cross-region copy, you specify how long to keep copied automated snapshots in the destination region — this defaults to keeping them indefinitely if not explicitly configured, which can cause snapshot storage to accumulate over time.

For Redshift Serverless: the destination region retention period for copied snapshots can be set between 1 and 3,653 days, with the default being indefinite retention if not specified. Source: docs.aws.amazon.com/redshift/latest/mgmt/serverless-backup-copy.html DIRECT.

The retention period in the destination region is the primary operational lever for controlling ongoing DR snapshot storage costs. A 7-day retention window for copied automated snapshots provides a meaningful DR window while containing storage accumulation. A retention period set to indefinite will accumulate storage charges continuously as each new automated snapshot copy lands in the destination region.

A common and costly configuration mistake: enabling cross-region snapshot copy with the default indefinite retention for automated snapshots. The first week, nothing visible happens on the bill.

Over six months, 180+ copied snapshots accumulate in the destination region, each carrying its incremental data blocks. The total storage charge is not the full cluster size times 180, but it can still be several times what was expected. Setting an explicit, finite retention period for copied automated snapshots in the destination region is the single most important cost control decision in a cross-region DR configuration.

Component 3: Fast Snapshot Restore charges

Fast Snapshot Restore (FSR) eliminates the performance penalty that normally occurs when restoring a cluster from a snapshot. Without FSR, a restored cluster is initially slow because data must be hydrated from S3 into the compute nodes during the restoration. FSR pre-warms snapshot data so the restored cluster performs at full speed immediately.

FSR billing works differently from how most people expect. You are charged per DSU (Data Service Unit) per hour for every hour that FSR is enabled on a snapshot in a given availability zone, regardless of whether you actually perform a restore. The AI Overview cites $0.75/DSU-hour as the rate for FSR. Verify the current rate for your region at aws.amazon.com/redshift/pricing/ before budgeting, as this rate varies by region.

The number of DSUs for a snapshot depends on the cluster configuration. Larger clusters with more nodes consume more DSUs. A cluster with 10 large nodes can generate FSR charges of many dollars per hour even without any restore activity.

The operational implication: Fast Snapshot Restore should be treated as an on-demand capability rather than an always-on setting for most DR configurations. The recommended approach is to enable FSR on relevant snapshots when a DR drill or actual recovery scenario is imminent, run the restore, and then disable FSR immediately after.

Leaving FSR enabled continuously on all cross-region DR snapshots generates substantial ongoing charges even in periods of complete inactivity.

Also read: Redshift Reserved Nodes: Node Types, Pricing, and the Commitment Risk

How Cross-Region Snapshot Copy Actually Works

You can configure Amazon Redshift to automatically copy snapshots — both automated and manual — for a cluster to another AWS region. When a snapshot is created in the cluster’s primary region, it is copied to a secondary region. The two regions are known as the source and destination.

The one-destination limitation

You can configure your cluster to copy snapshots to only one destination region at a time. Also, if your DR strategy requires snapshot availability in two different regions (for example, if you have users in both us-west-2 and eu-west-1 and want DR coverage near each), you cannot achieve this through the native cross-region copy mechanism for a single cluster. You would need to either maintain two separate clusters or use a different approach such as Redshift Data Sharing.

To change the destination region after it has been configured, you must first disable cross-region copying and then re-enable it with the new destination region specified. This is a console operation that can be performed without cluster downtime, but it means there is a gap in cross-region backup coverage during the reconfiguration window.

Automated vs manual snapshot copy behavior

When cross-region copy is enabled for a cluster, all new manual and automated snapshots are copied to the specified region. Copied snapshot names are prefixed with copy:. Source: docs.aws.amazon.com/redshift/latest/mgmt/snapshot-crossregioncopy-configure.html DIRECT QUOTE.

Automated snapshots that are copied to the destination region become independent copies there. The retention period for these copied snapshots is configured separately from the automated snapshot retention in the source region. If you set a 7-day automated snapshot retention in the source region, you can set a different retention period (say, 14 days or 30 days) for the copies in the destination region. This flexibility is useful for DR designs where you want longer coverage in the DR region than in the production region.

KMS encryption: the prerequisite step most teams miss

If your Redshift cluster is encrypted with AWS KMS, there is an additional prerequisite before cross-region snapshot copy can be configured: you must create a snapshot copy grant in the destination region that gives Redshift permission to use a KMS customer managed key in that destination region. You then select that grant when enabling cross-region copy in the source region.

This step is often overlooked during initial DR setup, particularly when teams are following a quick-start guide that assumes unencrypted clusters. The grant creation is a one-time setup step per destination region per KMS key, but if skipped, cross-region copy will fail for encrypted clusters with a permissions error that can take time to diagnose.

A Worked Cost Example for a Typical DR Configuration

Rather than abstract rates, it is helpful to see how the costs add up for a realistic configuration. The following example uses directional rates; verify exact figures at aws.amazon.com/redshift/pricing/ and aws.amazon.com/ec2/pricing/on-demand/ for your specific regions and current rates before modeling.

Scenario: an RA3 cluster with 10 TB of unique data, daily automated snapshots, cross-region copy from US East (N. Virginia) to US West (Oregon), 14-day retention for copied snapshots in the destination region, and no Fast Snapshot Restore enabled.

Data transfer: the initial cross-region copy of the first snapshot transfers approximately 10 TB. At $0.02/GB, that is approximately $200 for the initial transfer. Subsequent daily copies transfer only the incremental changes. If the daily change rate is 100 GB, each daily copy costs approximately $2.00. Over a 30-day month (after the initial transfer), ongoing transfer costs are roughly $60.

Snapshot storage in the destination: with 14-day retention, you hold 14 copies at any time. The total unique data blocks across those 14 copies is approximately 10 TB (base) plus 13 x 100 GB of incremental changes, roughly 11.3 TB. At $0.024/GB-month (RA3 backup storage rate for US-East), that is approximately $270/month in destination region snapshot storage. Verify current rates as these vary by region.

Total DR cost at this configuration (excluding FSR): approximately $330/month after initial setup — roughly $60/month in transfer and $270/month in storage. This is the ongoing cost of a 14-day DR window for a 10 TB RA3 cluster.

Adding Fast Snapshot Restore at $0.75/DSU-hour (verify at official pricing page) across multiple availability zones in the destination region would add substantial ongoing cost. For a 10-node RA3 cluster with FSR enabled in one AZ, the FSR charge can run to several hundred dollars per month continuously. This is why FSR as an always-on setting for DR is rarely the right choice for cost-conscious teams.

Controlling DR Costs Without Reducing DR Coverage

The cost levers in a cross-region DR configuration are relatively few, but each one has a meaningful impact.

Set an explicit retention period for copied snapshots

This is the single most impactful cost control decision. Every additional day of retention in the destination region adds the incremental change volume for that day to your storage bill. A 7-day window is adequate for many recovery scenarios. A 30-day window costs roughly four times as much in destination storage. Set the retention period to what your RTO and RPO requirements actually need, not the maximum allowed.

Use automated snapshot copy rather than manual snapshot copy for ongoing DR

Manual snapshots copied to another region are billed in the destination region until explicitly deleted, which makes cost accumulation harder to predict and control. Automated snapshots with a defined retention period are billed for a predictable window and then expire automatically. For ongoing DR coverage, relying on automated snapshot copy with defined retention is more cost-predictable than accumulating manual snapshot copies.

Enable Fast Snapshot Restore only before DR drills or actual recovery

FSR charges run continuously while enabled. For a DR strategy tested quarterly, the right posture is to enable FSR 24-48 hours before each planned test, run the test, and disable FSR immediately afterward. This converts the FSR cost from a continuous monthly charge to an intermittent, predictable per-event cost. In a genuine emergency, FSR can be enabled at that moment — the enabling process is fast, and even without pre-warming, the restore time for a small-to-mid-sized cluster is typically manageable.

Monitor destination region snapshot storage in CloudWatch

The SnapshotStorage CloudWatch metric tracks snapshot storage usage for both provisioned and Serverless Redshift. Setting a CloudWatch alarm on this metric in the destination region alerts you when storage is growing beyond expectations — which usually indicates either the retention period is set too long or manual snapshots are not being cleaned up.

Cross-Region Data Sharing as a DR Alternative

For some workloads, Redshift’s Cross-Region Data Sharing is worth evaluating as an alternative to snapshot-based DR. With Cross-Region Data Sharing, you can share data for read purposes across Redshift clusters in different regions without the need to copy data manually.

The billing model differs from snapshot-based DR: instead of paying for data transfer at snapshot copy time and then paying for storage in the destination region, Cross-Region Data Sharing charges are based on the bytes of data scanned for every successful query run. The consumer cluster pays the cross-region data transfer fee from the producer region to the consumer region.

Cross-Region Data Sharing also supports usage limits: you can set daily, weekly, or monthly limits on cross-region data transfer, with configurable actions when limits are reached (log only, CloudWatch alarm with SNS, or disable cross-region data sharing).

The practical distinction: snapshot-based DR provides the ability to restore a full, independent cluster in the destination region if the source region is unavailable. Cross-Region Data Sharing provides real-time read access to data across regions without a full restore, but requires the source region to be operational. For genuine disaster recovery where the source region might be unavailable, snapshot-based DR is the correct tool. For multi-region analytics access to the same dataset, Cross-Region Data Sharing is typically more cost-effective than maintaining a full snapshot-based DR copy.

How Redshift DR Fits Into a Broader Cost Strategy

Redshift cross-region snapshot costs are a variable cost component that sits alongside your base cluster costs. The base cluster charges — compute node hours and managed storage — are where reserved node purchasing delivers the largest savings. Cross-region DR costs are managed through the retention period, FSR usage decisions, and monitoring.

Usage.ai handles the reserved node layer of your Redshift cost: analyzing utilization, sizing reservation recommendations to your stable floor, purchasing nodes automatically, and monitoring utilization with a buyback guarantee if cluster configurations change. The DR cost layer — cross-region snapshots, FSR decisions, retention period configuration — is a one-time operational setup that, once correctly configured, maintains predictable costs without ongoing attention.

The combination: reserve the stable compute floor at the highest appropriate discount level, configure cross-region DR with a deliberately chosen retention period and FSR as on-demand-only, and monitor both costs through CloudWatch. $91M+ in savings delivered to 300+ customers across AWS, Azure, and GCP. Fee is a percentage of realized savings only. No savings, no fee.

Frequently Asked Questions

1. How much does Redshift cross-region snapshot copy cost?

Two primary costs apply. First, inter-region data transfer charges for the data moved when the snapshot is copied — approximately $0.02/GB for most US region pairs, varying by source and destination. Because Redshift snapshots are incremental, ongoing transfer costs reflect only the changed data since the last snapshot, not the full cluster size. Second, manual snapshot storage charges in the destination region per GB-month at standard Redshift backup storage rates for that region. If Fast Snapshot Restore is also enabled, a per-DSU-hour charge applies continuously while FSR is active. Verify current rates at aws.amazon.com/redshift/pricing/ and aws.amazon.com/ec2/pricing/on-demand/.

 

2. Are automated Redshift snapshots free?

Automated snapshots are free in the source region up to a 35-day retention period. When automated snapshots are copied to another region, the copies immediately incur storage charges in the destination region from the moment they land, even though the originals in the source region were free. Snapshots are billed until they expire or are deleted. Source: aws.amazon.com/redshift/pricing/.

 

3. Does Redshift charge for the full snapshot size or just changes?

Redshift uses incremental snapshot billing. Shared blocks across multiple snapshots are counted only once. You pay for the actual unique data blocks retained across all your snapshots, not the full logical size of each individual snapshot. A daily snapshot of a cluster with a 100 GB change rate costs approximately 100 GB per day in incremental storage, not the full cluster size per day. Source: aws.amazon.com/redshift/pricing/ DIRECT.

 

4. What is Fast Snapshot Restore and what does it cost?

Fast Snapshot Restore pre-warms snapshot data so that a restored cluster performs at full speed immediately rather than hydrating data from S3 during the post-restore period. FSR is charged per DSU-hour for every hour it is enabled on a snapshot in a given availability zone, regardless of whether a restore is performed. The published rate is approximately $0.75/DSU-hour (verify at aws.amazon.com/redshift/pricing/ for your region). FSR should typically be enabled on-demand before a DR test or recovery rather than left on continuously.

 

5. How many destination regions can a Redshift cluster copy snapshots to?

Only one. You can configure your cluster to copy snapshots to only one destination region at a time. To change the destination region, you must disable cross-region copying and re-enable it with the new destination specified. Source: docs.aws.amazon.com/redshift/latest/mgmt/cross-region-snapshot-copy.html DIRECT.

 

6. Do cross-region snapshot costs differ by node type?

The data transfer charge for copying the snapshot cross-region is the same regardless of node type. The snapshot storage billing model in the destination region differs: RA3 manual snapshots are billed at standard S3 backup storage rates. RG and Serverless manual snapshots are billed based on unique data blocks across all active snapshots at the snapshot rate for the region. DC2 backups are stored in S3 and billed at S3 rates beyond the free provisioned storage equivalent. Source: aws.amazon.com/redshift/pricing/.