
Amazon Redshift Now Supports Automated Cross-Region Backups, So I Tried It Out
This page has been translated by machine translation. View original
Introduction
Automated cross-Region snapshot copy is now available in Amazon Redshift. It continuously copies the latest snapshots to another Region and keeps the transfer volume to incremental changes.
In this article, I enable this feature on a provisioned cluster in Tokyo and observe the process until the snapshot appears in the list in Osaka.
Test Environment
| Item | Value |
|---|---|
| Source / Destination | ap-northeast-1 (Tokyo) / ap-northeast-3 (Osaka) |
| Node | rg.large, single node |
| Redshift version | 1.0.520420 |
| Encryption | Default (AWS owned key, KMS not configured) |
| Retention period of automated snapshots in Tokyo | 1 day |
| Snapshot schedule | cron(30 15 *) (daily at 15:30 UTC) |
| Retention period at the destination | Automated: 1 day, manual: 1 day |
| Registered data | 3 records registered in 1 table using the Data API. The snapshot's TotalBackupSizeInMegaBytes was 47.0 |
| AWS CLI | 2.39.3 |
Configuration
When you enable automated cross-Region snapshot copy, the latest snapshot at the time of enabling also becomes a copy target. This time, I configure copying from the cluster in Tokyo to Osaka.
Cluster and Snapshot Schedule
I create a schedule that takes a snapshot in Tokyo every day at 15:30 UTC. The cron for a Redshift snapshot schedule is specified with 3 fields.
aws redshift create-snapshot-schedule --region ap-northeast-1 --schedule-identifier devio-xrc-schedule --schedule-definitions "cron(30 15 *)" --schedule-description "devio verify"
I created a single-node cluster with this schedule attached.
Cluster creation command
aws redshift create-cluster --region ap-northeast-1 --cluster-identifier devio-xrc-test --node-type rg.large --cluster-type single-node --master-username awsuser --manage-master-password --db-name dev --no-publicly-accessible --automated-snapshot-retention-period 1 --snapshot-schedule-identifier devio-xrc-schedule
Enabling Snapshot Copy
I specified Osaka as the destination Region, and set the retention periods for both automated and manual snapshots at the destination to 1 day.
aws redshift enable-snapshot-copy --region ap-northeast-1 --cluster-identifier devio-xrc-test --destination-region ap-northeast-3 --retention-period 1 --manual-snapshot-retention-period 1
Results
All times below are in UTC.
Snapshot at the Time of Enabling
Before enabling, in Tokyo, an automated snapshot rs:devio-xrc-test-2026-11-03-14-25-16-850 had been taken at 14:25:16Z, about 3.5 minutes after the cluster was created (14:21:48Z). It was taken before the scheduled 15:30Z.
I executed the copy enablement at 14:26:35Z. After that, I checked the list in Osaka at 10-second intervals and recorded only the points when the content changed.
14:26:42Z osaka: []
14:28:48Z osaka: [copy:rs:devio-xrc-test-2026-11-03-14-25-16-850 automated copying]
14:30:44Z osaka: [copy:rs:devio-xrc-test-2026-11-03-14-25-16-850 automated available]
The 14:25:16Z snapshot that existed in Tokyo before enabling appeared in Osaka with a name prefixed with copy:. It took 2 minutes 13 seconds from enabling to first observing copying, and 4 minutes 9 seconds to first observing available.
The attributes of the snapshot in Osaka are as follows.
{
"SnapshotIdentifier": "copy:rs:devio-xrc-test-2026-11-03-14-25-16-850",
"SnapshotCreateTime": "2026-11-03T14:25:16.850000+00:00",
"Status": "available",
"SnapshotType": "automated",
"Encrypted": true,
"KmsKeyId": "AWS_OWNED_KMS_KEY",
"SourceRegion": "ap-northeast-1",
"SnapshotRetentionStartTime": "2026-11-03T14:30:40.093000+00:00"
}
SnapshotCreateTime remained the time at which the snapshot was taken in Tokyo, and SnapshotRetentionStartTime was 14:30:40Z, just before 14:30:44Z, when available was first observed in Osaka.
Snapshot Taken by the Schedule
After enabling, I performed no operations and monitored at 5-second intervals until the Tokyo snapshot taken by the 15:30Z schedule reached Osaka. For both Tokyo and Osaka, I recorded only the points when the list changed.
15:29:31Z tokyo:
rs:devio-xrc-test-2026-11-03-14-25-16-850 automated available
15:29:31Z osaka:
copy:rs:devio-xrc-test-2026-11-03-14-25-16-850 automated available
15:30:25Z tokyo:
rs:devio-xrc-test-2026-11-03-14-25-16-850 automated available
rs:devio-xrc-test-2026-11-03-15-30-20-614 automated available
15:32:12Z osaka:
copy:rs:devio-xrc-test-2026-11-03-14-25-16-850 automated available
copy:rs:devio-xrc-test-2026-11-03-15-30-20-614 automated copying
15:33:54Z osaka:
copy:rs:devio-xrc-test-2026-11-03-14-25-16-850 automated available
copy:rs:devio-xrc-test-2026-11-03-15-30-20-614 automated available
The snapshot in Tokyo was created 20 seconds after the scheduled 15:30:00Z (at 15:30:20.614Z). The SnapshotRetentionStartTime in Osaka was 15:33:52.590Z, 3 minutes 32 seconds after the creation in Tokyo.
The ActualIncrementalBackupSizeInMegaBytes of the snapshots in Osaka was 48.0 for the first (the 14:25:16Z one) and 7.0 for the second (the 15:30:20Z one), and TotalBackupSizeInMegaBytes was 47.0 for both.
Summary
I was able to confirm the behavior of cross-Region snapshot copy on an Amazon Redshift cluster.
Cross-Region copy is now supported as a native Redshift feature. Without any manual operations, the latest snapshots (automated and manual) are copied continuously and incrementally.
Cross-Region copy could previously also be achieved through integration with AWS Backup, but now a Redshift-native option has been added as well. The two cannot be used together, and snapshot management needs to be consolidated on one or the other, so please choose the one that suits your workload.
Notes
- Only one Region can be specified as the destination at a time. To change it, disable copying once and then configure it again.
- Automated snapshots at the destination cannot be deleted manually. They are deleted when the retention period is reached.
- In this test, even about 4 minutes after I disabled copying and deleted the source cluster, the 2 automated snapshots at the destination remained available.
