AWS
Microsoft Azure
Google Cloud
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.
Redshift cross-Region disaster recovery primarily adds snapshot-copy transfer and retained snapshot storage. Recovery drills also incur compute and storage for the restored environment. EBS Fast Snapshot Restore is a separate service and is not a Redshift snapshot fee; the earlier DSU-based estimate in this guide was incorrect.
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.
Provisioned automated snapshot retention is limited to 35 days. To retain a point beyond that window, create a manual snapshot with an explicit retention setting and account for its storage charges.
Manual snapshots: charged until deleted
Manual snapshot billing depends on node family. RG and Serverless charge for unique retained blocks across active snapshots; RA3 manual backups are a separate backup-storage item at the applicable regional rate. Snapshots persist until their configured expiration or deletion, including after the cluster is removed.
Snapshots are billed until they expire or are deleted, including when the cluster is paused or deleted. Source: aws.amazon.com/redshift/pricing/. 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
Cross-Region snapshot copies transfer changed blocks after the initial copy. Storage billing also depends on node family: RG and Serverless explicitly use unique blocks across active snapshots, while RA3 manual snapshots have separate backup-storage billing. Use measured billable snapshot bytes for the selected family rather than assuming a universal number of full copies.
For a simplified RG or Serverless retained-block model, 10,000 GB of base data plus nine distinct 100-GB changed-block sets is 10,900 GB, not 100,000 GB. Actual snapshots can share, overwrite, compress or retain blocks differently, so measured billable storage is the basis for the invoice.
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/.
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: Transfer, Storage and Recovery Tests
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
Copied snapshots can incur retained storage charges in the destination. Use that destination’s snapshot rate and the actual snapshot type; a copied automated snapshot is not automatically the same as a manually retained backup.
Destination retention is configured separately. Provisioned Redshift copied automated snapshots default to seven days; Serverless copied manual snapshots default to indefinite retention, while copied recovery points have a one-day retention rule. These defaults must not be conflated. Sources: provisioned copy retention and Serverless copy retention.
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.
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.
An indefinite manual-snapshot retention setting can accumulate storage over time. Review the actual retention configuration instead of assuming every automatic copy is retained indefinitely.
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: Restored environment and test costs
A restored Redshift environment has compute and storage charges while it is running. Budget recovery tests using the target node count or RPU-hours and storage duration. There is no EBS Fast Snapshot Restore DSU fee to add to a Redshift snapshot.
The $0.75-per-hour FSR example belongs to Amazon EBS and applies to enabled EBS snapshot/Availability Zone pairs. It does not map to Redshift node counts. Source: AWS EBS Fast Snapshot Restore.
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.
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
Illustration checked October 15, 2026: copy from N. Virginia to Oregon at $0.02/GB, then retain a measured average 11,300 GB of chargeable manual snapshot storage in Oregon at $0.023/GB-month. This storage assumption must come from billing measurements; it is not guaranteed by selecting 14-day retention.
| Component | Assumption and calculation | Cost |
|---|---|---|
| Initial transfer | 10,000 billable GB × $0.02 | $200.00 once |
| Ongoing transfer | 100 GB/day × 30 days × $0.02 | $60.00 per modeled month |
| Retained manual snapshots | 11,300 average billable GB × $0.023 | $259.90/month |
| Ongoing subtotal | Transfer plus retained snapshots | $319.90/month |
The recurring subtotal excludes the initial copy, source cluster, restored compute during tests, KMS and any other applicable charges. A first month is not automatically $519.90 because average retained storage builds over time. Rates use AWS Redshift pricing and the Oregon public catalog. The former $0.024 rate was managed storage, not the correct Oregon snapshot rate.
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
Choose retention using recovery requirements and measured changed-block volume. A 30-day window does not automatically cost four times a seven-day window: both may share a large common base, and the incremental block footprint varies. Model each retained data set before estimating savings.
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.
Budget and measure recovery drills
Run periodic recovery drills to measure actual restore time and workload readiness. Budget the restored cluster’s compute, storage and related services for the test duration. Stop test resources when the drill is complete according to your recovery process; there is no Redshift FSR switch or DSU charge to manage.
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, recovery-test resources, 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, recovery tests, retention period configuration — needs recurring review as data volume, change rates and recovery requirements evolve.
The combination: reserve the stable compute floor at the highest appropriate discount level, configure cross-region DR with a deliberately chosen retention period and an explicit budget for recovery-test resources, 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?
Budget cross-Region transferred bytes, destination snapshot storage, and any restored compute used for drills or recovery. In the explicit example, $60 of monthly transfer plus $259.90 of measured retained storage totals $319.90, excluding the initial copy and other charges. There is no EBS FSR fee for a Redshift snapshot.
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/.
4. What is Fast Snapshot Restore and what does it cost?
Fast Snapshot Restore is an Amazon EBS feature billed for enabled EBS snapshot/Availability Zone pairs. It is not a Redshift snapshot pricing component. For Redshift, estimate the actual restored cluster or Serverless compute and storage used during recovery and testing.
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.
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/.
