![[アップデート] Amazon Redshift の自動クロスリージョンバックアップを Redshift Serverless で試してみた](https://devio2024-media.developers.io/image/upload/f_auto,q_auto,w_3840/f_auto,q_auto/v1790870385/eyecatch/y1ipevknntjfjxlyd7ow.png)
[アップデート] Amazon Redshift の自動クロスリージョンバックアップを Redshift Serverless で試してみた
クラウド事業統括本部の石川です。Amazon Redshift で、最新のスナップショットを手動操作なしで別リージョンへコピーする自動クロスリージョンバックアップが発表されましたので、Amazon Redshift Serverless で実際に試してみました。
Amazon Redshift の自動クロスリージョンスナップショットコピー（hands-off automated cross-region backups）が発表されました。Amazon Redshift provisioned cluster または Serverless workgroup を、選択したリージョンに自動でバックアップできます。
この機能は手動操作なしで常に最新のスナップショットをコピー先リージョンにコピーします。システム上で利用可能な最新のスナップショットをコピーするため、次のスナップショットが作成されるのを待つ必要がなく、ローカルクラスターのスナップショットスケジュールとは独立して動作します。全ての商用リージョンと AWS GovCloud (US) リージョンで利用できます。
一方で、本記事執筆時点（2026 年 10 月 31 日）の AWS CLI の CHANGELOG（2.39.3 まで）には、Redshift のスナップショットコピーに関する API 変更は見当たりませんでした。Redshift Serverless の create-snapshot-copy-configuration は、コピー先リージョンを --destination-region で 1 つ指定する形式です。また、公式ドキュメントには「一度に 1 つのコピー先リージョンのみ」と記載されています。そこで本記事では、アナウンスの記述がどのような動作として現れるのかを実機で確認しました。
Amazon Redshift の自動クロスリージョンバックアップとは
Amazon Redshift のクロスリージョンバックアップは、ソースリージョンで作成されたバックアップを、指定したコピー先リージョンに自動でコピーする機能です。コピー先リージョンにあるバックアップから新しいクラスターやワークグループにリストアできるため、ソースリージョンで障害が発生した場合の復旧手段になります。
Redshift Serverless では、バックアップとして手動で作成するスナップショットと、自動で作成されるリカバリーポイントの 2 種類があります。リカバリーポイントは 30 分ごと、またはノードあたり 5 GB のデータ変更ごとに作成され、24 時間保持されます。クロスリージョンバックアップを設定すると、スナップショットとリカバリーポイントの両方がコピー先リージョンにコピーされます。
ドキュメントに記載されている Redshift Serverless のクロスリージョンバックアップの仕様は以下のとおりです。
| 項目 | 内容 |
|---|---|
| コピー先リージョン | 一度に 1 つ |
| コピー先でのスナップショット保持期間 | 既定は無期限。指定する場合は 1〜3653 日 |
| リカバリーポイントの保持期間 | 1 日（変更不可） |
| 暗号化 | 既定は AWS 所有のキー（AWS_OWNED_KMS_KEY）。カスタマー管理キーを選んだ場合は、コピー先リージョンでそのキーを使用する許可（KMS のグラント）を Amazon Redshift Serverless が自動で作成 |
| 必要な IAM 権限 | redshift-serverless:CreateSnapshotCopyConfiguration / UpdateSnapshotCopyConfiguration / ListSnapshotCopyConfigurations / DeleteSnapshotCopyConfiguration（カスタマー管理キー使用時は kms:CreateGrant と kms:DescribeKey も必要） |
プロビジョニングされたクラスター向けのドキュメントでは、クロスリージョンコピーを有効にすると「新しく作成された手動・自動スナップショット」がコピーされ、コピーされたスナップショットの名前には copy: が付くと説明されています。今回のアナウンスに記載されている「次のスナップショットを待たずに最新のスナップショットをコピーする」動作は、この「新しく作成されたスナップショットがコピーされる」という説明とは異なる内容です。
やってみた
前提条件
- ソースリージョン: 東京（ap-northeast-1）、コピー先リージョン: 大阪（ap-northeast-3）
- Amazon Redshift Serverless: ベース容量 4 RPU、パッチバージョン 206、ワークグループバージョン 1.0.520420
- 東京は検証用に作成した VPC（3 AZ のサブネット）、大阪はデフォルト VPC を使用
本記事では Redshift Serverless のみを検証しています。プロビジョニングされたクラスターは検証していません。
検証環境のシステム構成
確認すること
アナウンスとドキュメントの記述の差分から、以下の 4 点を確認します。
| No. | 確認すること | アナウンス・ドキュメントの記述 |
|---|---|---|
| 1 | 有効化前に作成済みのスナップショットが、次のスナップショットを待たずにコピーされるか | アナウンス: 最新のスナップショットをコピー |
| 2 | 有効化時にコピーされるのは最新の 1 つだけか、既存の全てか | アナウンス: the most recent snapshot |
| 3 | コピー先リージョンを複数設定できるか | アナウンス: region(s)、ドキュメント: 一度に 1 つ |
| 4 | コピー先のスナップショット名、リカバリーポイントのコピー、リストアの結果 | アナウンス: copy プレフィックス、新しいワークグループへのリストア |
検証用の Serverless 環境を作成する
東京リージョンに検証用の名前空間とワークグループを作成します。
% aws redshift-serverless create-namespace \
--region ap-northeast-1 \
--namespace-name xrb-tokyo-ns \
--db-name dev \
--query 'namespace.{name:namespaceName,status:status,kmsKeyId:kmsKeyId,creationDate:creationDate}' \
--output json
{
"name": "xrb-tokyo-ns",
"status": "AVAILABLE",
"kmsKeyId": "AWS_OWNED_KMS_KEY",
"creationDate": "2026-10-31T06:03:16.103000+00:00"
}
% aws redshift-serverless create-workgroup \
--region ap-northeast-1 \
--workgroup-name xrb-tokyo-wg \
--namespace-name xrb-tokyo-ns \
--base-capacity 4 \
--subnet-ids $SUBNET_IDS \
--security-group-ids $SECURITY_GROUP_ID \
--no-publicly-accessible \
--query 'workgroup.{name:workgroupName,status:status,baseCapacity:baseCapacity}' \
--output json
{
"name": "xrb-tokyo-wg",
"status": "CREATING",
"baseCapacity": 4
}
ワークグループが利用可能になったことを確認します。
% aws redshift-serverless get-workgroup \
--region ap-northeast-1 \
--workgroup-name xrb-tokyo-wg \
--query 'workgroup.{name:workgroupName,namespace:namespaceName,status:status,baseCapacity:baseCapacity,patchVersion:patchVersion,workgroupVersion:workgroupVersion}' \
--output table
--------------------------------------
| GetWorkgroup |
+-------------------+----------------+
| baseCapacity | 4 |
| name | xrb-tokyo-wg |
| namespace | xrb-tokyo-ns |
| patchVersion | 206 |
| status | AVAILABLE |
| workgroupVersion | 1.0.520420 |
+-------------------+----------------+
テーブルを作成してデータを投入する
リストア後にデータを比較できるように、テーブルを作成して 3 行を投入しました。note 列には、どのタイミングで投入した行かを記録します。
CREATE TABLE public.backup_test (id INT, note VARCHAR(100), inserted_at TIMESTAMP DEFAULT GETDATE());
INSERT INTO public.backup_test (id, note) VALUES (1, 'before enable'), (2, 'before enable'), (3, 'before enable');
SELECT id, note, inserted_at FROM public.backup_test ORDER BY id;
| id | note | inserted_at |
|---|---|---|
| 1 | before enable | 2026-10-31 06:04:44 |
| 2 | before enable | 2026-10-31 06:04:44 |
| 3 | before enable | 2026-10-31 06:04:44 |
有効化前に手動スナップショットを作成する
クロスリージョンバックアップを有効化する前に、手動スナップショット xrb-snap-before-enable を作成します。
% aws redshift-serverless create-snapshot \
--region ap-northeast-1 \
--namespace-name xrb-tokyo-ns \
--snapshot-name xrb-snap-before-enable \
--retention-period 1
% aws redshift-serverless list-snapshots \
--region ap-northeast-1 \
--namespace-name xrb-tokyo-ns \
--query 'snapshots[].{name:snapshotName,status:status,createTime:snapshotCreateTime,sizeMB:totalBackupSizeInMegaBytes}' \
--output table
----------------------------------------------------
| ListSnapshots |
+-------------+------------------------------------+
| createTime | 2026-10-31T06:05:05.826000+00:00 |
| name | xrb-snap-before-enable |
| sizeMB | 104.0 |
| status | AVAILABLE |
+-------------+------------------------------------+
この時点で、大阪リージョンにはスナップショットもリカバリーポイントもありません。
% aws redshift-serverless list-snapshots --region ap-northeast-3 --output json
{
"snapshots": []
}
% aws redshift-serverless list-recovery-points --region ap-northeast-3 --output json
{
"recoveryPoints": []
}
マネジメントコンソールで設定画面を確認する
CLI で設定する前に、マネジメントコンソールのクロスリージョンバックアップの設定画面を確認しました。名前空間の［データバックアップ］タブにある［バックアップの詳細］の［編集］から開きます。
［バックアップをコピー］で［はい］を選ぶと、送信先の AWS リージョン、復旧ポイントの保持期間、スナップショット保持期間、暗号化設定が表示されます。復旧ポイント（リカバリーポイント）の保持期間は 1 日で固定されていて変更できません。スナップショット保持期間の既定値は［無期限］です。
送信先の AWS リージョンのドロップダウンは単一選択で、複数のリージョンを選ぶ UI はありませんでした。
今回は設定を保存せずにキャンセルし、以降の設定は CLI で行いました。
クロスリージョンバックアップを有効化する
06:07:44 に、東京の名前空間から大阪へのスナップショットコピー設定を作成しました。コピー先での保持期間は 1 日にしています。
% aws redshift-serverless create-snapshot-copy-configuration \
--region ap-northeast-1 \
--namespace-name xrb-tokyo-ns \
--destination-region ap-northeast-3 \
--snapshot-retention-period 1 \
--output json
{
"snapshotCopyConfiguration": {
"destinationKmsKeyId": "AWS_OWNED_KMS_KEY",
"destinationRegion": "ap-northeast-3",
"namespaceName": "xrb-tokyo-ns",
"snapshotCopyConfigurationArn": "arn:aws:redshift-serverless:ap-northeast-1:123456789012:snapshotcopyconfiguration/419bed9b-a916-4be1-8436-ede43294444b",
"snapshotCopyConfigurationId": "419bed9b-a916-4be1-8436-ede43294444b",
"snapshotRetentionPeriod": 1
}
}
コンソールの［バックアップの詳細］にも、送信先リージョンと保持期間（復旧ポイント 1 日、スナップショット 1 日）が反映されました。
有効化前のスナップショットがコピーされるか確認する
有効化した直後から、大阪リージョンで list-snapshots を 30 秒間隔で実行しました。
有効化から 11 秒後（06:07:55）の出力です。
% aws redshift-serverless list-snapshots \
--region ap-northeast-3 \
--query 'snapshots[].[snapshotName,status,snapshotCreateTime]' \
--output text
copy:xrb-snap-before-enable COPYING 2026-10-31T06:05:05.826000+00:00
06:10:00 の出力です。
% aws redshift-serverless list-snapshots \
--region ap-northeast-3 \
--query 'snapshots[].[snapshotName,status,snapshotCreateTime]' \
--output text
copy:xrb-snap-before-enable AVAILABLE 2026-10-31T06:05:05.826000+00:00
結果を時系列でまとめると以下のとおりです。
| 時刻（UTC） | 東京 | 大阪 |
|---|---|---|
| 06:05:05 | xrb-snap-before-enable を作成 |
なし |
| 06:07:44 | コピー設定を作成 | なし |
| 06:07:55 | - | copy:xrb-snap-before-enable が COPYING |
| 06:09:29 | - | copy:xrb-snap-before-enable が COPYING |
| 06:10:00 | - | copy:xrb-snap-before-enable が AVAILABLE |
有効化から 11 秒後には、有効化前に作成したスナップショットのコピーが大阪で始まっていました。この間、東京では新しいスナップショットを作成していません。有効化から約 2 分 16 秒以内にコピーが完了しています。
コピーされたスナップショットの詳細です。
% aws redshift-serverless get-snapshot \
--region ap-northeast-3 \
--snapshot-name 'copy:xrb-snap-before-enable' \
--output json
{
"snapshot": {
"accountsWithProvisionedRestoreAccess": [],
"accountsWithRestoreAccess": [],
"actualIncrementalBackupSizeInMegaBytes": 106.0,
"adminUsername": "admin",
"backupProgressInMegaBytes": 106.0,
"currentBackupRateInMegaBytesPerSecond": 2.1828,
"elapsedTimeInSeconds": 1,
"estimatedSecondsToCompletion": 0,
"kmsKeyId": "AWS_OWNED_KMS_KEY",
"namespaceArn": "arn:aws:redshift-serverless:ap-northeast-3:123456789012:namespace/3e3023a9-7c50-4dec-923b-205fc7ac6501",
"namespaceName": "xrb-tokyo-ns",
"ownerAccount": "123456789012",
"snapshotArn": "arn:aws:redshift-serverless:ap-northeast-3:123456789012:snapshot/555654c1-f2b9-4093-ae50-cef4c9f70e22",
"snapshotCreateTime": "2026-10-31T06:05:05.826000+00:00",
"snapshotName": "copy:xrb-snap-before-enable",
"snapshotRemainingDays": 0,
"snapshotRetentionPeriod": 1,
"snapshotRetentionStartTime": "2026-10-31T06:05:05.826000+00:00",
"status": "AVAILABLE",
"totalBackupSizeInMegaBytes": 104.0
}
}
- スナップショット名には
copy:が付きます namespaceNameはコピー元のxrb-tokyo-nsのままですnamespaceArnはリージョンがap-northeast-3で、名前空間 ID（3e3023a9-...）はコピー元と同じですsnapshotCreateTimeはコピー元のスナップショットの作成時刻と同じです
コピー先リージョンを 2 つ設定できるか試す
アナウンスには「destination region(s)」とあるため、同じ名前空間に 2 つ目のコピー設定（バージニア北部 us-east-1）を追加してみました。
% aws redshift-serverless create-snapshot-copy-configuration \
--region ap-northeast-1 \
--namespace-name xrb-tokyo-ns \
--destination-region us-east-1 \
--snapshot-retention-period 1 \
--output json
aws: [ERROR]: An error occurred (ValidationException) when calling the CreateSnapshotCopyConfiguration operation: You can only have one snapshot copy configuration per namespace.
名前空間あたりのコピー設定は 1 つまでというエラーになりました。本記事執筆時点の Redshift Serverless では、コピー先リージョンは 1 つです。
有効化後に作成したスナップショットもコピーされるか確認する
2 行を追加してから、新しい手動スナップショット xrb-snap-after-enable を作成しました。
INSERT INTO public.backup_test (id, note) VALUES (4, 'after enable'), (5, 'after enable');
% aws redshift-serverless create-snapshot \
--region ap-northeast-1 \
--namespace-name xrb-tokyo-ns \
--snapshot-name xrb-snap-after-enable \
--retention-period 1 \
--query 'snapshot.{name:snapshotName,status:status,createTime:snapshotCreateTime}' \
--output json
{
"name": "xrb-snap-after-enable",
"status": "CREATING",
"createTime": "2026-10-31T06:10:50.589000+00:00"
}
15 秒間隔で東京と大阪の状態を確認した結果です。
| 時刻（UTC） | 東京 xrb-snap-after-enable |
大阪 copy:xrb-snap-after-enable |
|---|---|---|
| 06:10:50 | CREATING | なし |
| 06:11:06 | AVAILABLE | なし |
| 06:13:49 | AVAILABLE | なし |
| 06:14:05 | AVAILABLE | COPYING |
| 06:15:26 | AVAILABLE | COPYING |
| 06:15:42 | AVAILABLE | AVAILABLE |
有効化後に作成したスナップショットも自動でコピーされました。スナップショットの作成から約 3 分 15 秒後にコピーが始まり、約 4 分 50 秒後に完了しています。有効化直後のコピー（11 秒後に開始）と比べると、開始までの時間が長くなりました。
有効化時にコピーされるのは最新のスナップショットだけか確認する
前の手順では、有効化前のスナップショットが 1 つしかなかったため、「最新の 1 つだけがコピーされる」のか「既存の全てがコピーされる」のかを区別できません。そこで、コピー設定をいったん削除し、無効の状態でスナップショットを 2 つ作成してから、再度有効化しました。
まず、コピー設定を削除します。
% aws redshift-serverless delete-snapshot-copy-configuration \
--region ap-northeast-1 \
--snapshot-copy-configuration-id 419bed9b-a916-4be1-8436-ede43294444b \
--output json
{
"snapshotCopyConfiguration": {
"destinationKmsKeyId": "AWS_OWNED_KMS_KEY",
"destinationRegion": "ap-northeast-3",
"namespaceName": "xrb-tokyo-ns",
"snapshotCopyConfigurationArn": "arn:aws:redshift-serverless:ap-northeast-1:123456789012:snapshotcopyconfiguration/419bed9b-a916-4be1-8436-ede43294444b",
"snapshotCopyConfigurationId": "419bed9b-a916-4be1-8436-ede43294444b",
"snapshotRetentionPeriod": 1
}
}
削除の直後も、大阪にコピー済みのスナップショット 2 件は残っていました。
% aws redshift-serverless list-snapshots \
--region ap-northeast-3 \
--query 'snapshots[].[snapshotName,status,snapshotCreateTime]' \
--output text
copy:xrb-snap-after-enable AVAILABLE 2026-10-31T06:10:50.589000+00:00
copy:xrb-snap-before-enable AVAILABLE 2026-10-31T06:05:05.826000+00:00
コピーが無効の状態で、1 行ずつ追加しながらスナップショットを 2 つ作成しました。
INSERT INTO public.backup_test (id, note) VALUES (6, 'while disabled 1');
-- この後に xrb-snap-disabled-1 を作成
INSERT INTO public.backup_test (id, note) VALUES (7, 'while disabled 2');
-- この後に xrb-snap-disabled-2 を作成
再有効化する直前の東京のスナップショットは以下のとおりです。
% aws redshift-serverless list-snapshots \
--region ap-northeast-1 \
--namespace-name xrb-tokyo-ns \
--query 'snapshots[].[snapshotName,status,snapshotCreateTime]' \
--output text
xrb-snap-disabled-2 AVAILABLE 2026-10-31T06:19:02.573000+00:00
xrb-snap-disabled-1 AVAILABLE 2026-10-31T06:16:17.761000+00:00
xrb-snap-after-enable AVAILABLE 2026-10-31T06:10:50.589000+00:00
xrb-snap-before-enable AVAILABLE 2026-10-31T06:05:05.826000+00:00
06:21:26 にコピー設定を再作成し、大阪を 15 秒間隔で確認しました。
% aws redshift-serverless create-snapshot-copy-configuration \
--region ap-northeast-1 \
--namespace-name xrb-tokyo-ns \
--destination-region ap-northeast-3 \
--snapshot-retention-period 1 \
--query 'snapshotCopyConfiguration.{id:snapshotCopyConfigurationId,destinationRegion:destinationRegion,retention:snapshotRetentionPeriod}' \
--output json
{
"id": "1b27b7a3-8936-4818-bae6-063b14bbeeb2",
"destinationRegion": "ap-northeast-3",
"retention": 1
}
| 時刻（UTC） | copy:xrb-snap-disabled-1 |
copy:xrb-snap-disabled-2 |
|---|---|---|
| 06:21:26 | なし | なし（コピー設定を再作成） |
| 06:22:45 | なし | なし |
| 06:23:01 | なし | COPYING |
| 06:23:48 | なし | AVAILABLE |
| 06:30:35 | なし | AVAILABLE |
再有効化から約 1 分 35 秒後に、最新の xrb-snap-disabled-2 のコピーが始まりました。その前に作成した xrb-snap-disabled-1 は、観測を終えた 06:30:35 まで（再有効化から約 9 分間）コピーされませんでした。有効化時にコピーされるのは、その時点で最新のスナップショット 1 つだけです。
リカバリーポイントもコピーされるか確認する
東京では 06:29:55 にリカバリーポイントが自動作成されていました。
% aws redshift-serverless list-recovery-points \
--region ap-northeast-1 \
--namespace-name xrb-tokyo-ns \
--query 'recoveryPoints[].{id:recoveryPointId,createTime:recoveryPointCreateTime,namespace:namespaceName,sizeMB:totalSizeInMegaBytes}' \
--output table
--------------------------------------------------------
| ListRecoveryPoints |
+-------------+----------------------------------------+
| createTime | 2026-10-31T06:29:55.006000+00:00 |
| id | 3485facc-b0f9-40bc-98f5-7de43bec741b |
| namespace | xrb-tokyo-ns |
| sizeMB | 104.0 |
+-------------+----------------------------------------+
大阪で 30 秒間隔で確認したところ、06:32:05 には同じ ID のリカバリーポイントが大阪に存在していました。
% aws redshift-serverless get-recovery-point \
--region ap-northeast-3 \
--recovery-point-id 3485facc-b0f9-40bc-98f5-7de43bec741b \
--output json
{
"recoveryPoint": {
"namespaceArn": "arn:aws:redshift-serverless:ap-northeast-3:123456789012:namespace/3e3023a9-7c50-4dec-923b-205fc7ac6501",
"namespaceName": "xrb-tokyo-ns",
"recoveryPointCreateTime": "2026-10-31T06:29:55.006000+00:00",
"recoveryPointId": "3485facc-b0f9-40bc-98f5-7de43bec741b",
"totalSizeInMegaBytes": 104.0
}
}
リカバリーポイントは、スナップショットと違って名前に copy: が付かず、ID もコピー元と同じでした。
大阪のコンソールでコピーされたスナップショットを確認する
大阪リージョンの Redshift Serverless の［データバックアップ］画面にも、コピーされたスナップショット 3 件が［使用可能］で表示されました。xrb-snap-disabled-1 はありません。
コピー元のスナップショットには 4 つのタグを付けていましたが、コピー先のスナップショットのタグは［0 タグ］と表示されています。また、［名前空間］列は［-］と表示されました。
大阪でリストアする
最後に、大阪にコピーされた最新のスナップショット copy:xrb-snap-disabled-2 から、大阪の新しい名前空間にリストアします。リストア先として、大阪に名前空間とワークグループを作成しました。
% aws redshift-serverless create-namespace \
--region ap-northeast-3 \
--namespace-name xrb-osaka-ns \
--db-name dev \
--query 'namespace.{name:namespaceName,status:status}' \
--output json
{
"name": "xrb-osaka-ns",
"status": "AVAILABLE"
}
% aws redshift-serverless create-workgroup \
--region ap-northeast-3 \
--workgroup-name xrb-osaka-wg \
--namespace-name xrb-osaka-ns \
--base-capacity 4 \
--subnet-ids $OSAKA_SUBNET_IDS \
--security-group-ids $OSAKA_SECURITY_GROUP_ID \
--no-publicly-accessible \
--query 'workgroup.{name:workgroupName,status:status,baseCapacity:baseCapacity}' \
--output json
{
"name": "xrb-osaka-wg",
"status": "CREATING",
"baseCapacity": 4
}
ワークグループが利用可能になってから、リストアを実行します。
% aws redshift-serverless restore-from-snapshot \
--region ap-northeast-3 \
--namespace-name xrb-osaka-ns \
--workgroup-name xrb-osaka-wg \
--snapshot-name 'copy:xrb-snap-disabled-2' \
--query '{namespace:namespace.namespaceName,status:namespace.status,snapshotName:snapshotName}' \
--output json
{
"namespace": "xrb-osaka-ns",
"status": "MODIFYING",
"snapshotName": "copy:xrb-snap-disabled-2"
}
06:31:12 にリストアを開始し、06:39:41 に名前空間が AVAILABLE になりました（約 8 分 30 秒）。
大阪のワークグループでテーブルを確認します。
SELECT id, note, inserted_at FROM public.backup_test ORDER BY id;
| id | note | inserted_at |
|---|---|---|
| 1 | before enable | 2026-10-31 06:04:44 |
| 2 | before enable | 2026-10-31 06:04:44 |
| 3 | before enable | 2026-10-31 06:04:44 |
| 4 | after enable | 2026-10-31 06:10:46 |
| 5 | after enable | 2026-10-31 06:10:46 |
| 6 | while disabled 1 | 2026-10-31 06:16:13 |
| 7 | while disabled 2 | 2026-10-31 06:19:00 |
xrb-snap-disabled-2 を作成した時点の 7 行が大阪に復元されており、東京で同じ SELECT を実行した結果と一致しました。
後片付け
検証後、コピー設定、両リージョンのワークグループ・名前空間・スナップショット、検証用 VPC を削除しました。
大阪にコピーされたリカバリーポイント（3485facc-...）だけは残りました。Redshift Serverless の CLI にはリカバリーポイントを削除するコマンドがなく（convert-recovery-point-to-snapshot、get-recovery-point、list-recovery-points、restore-from-recovery-point、restore-table-from-recovery-point のみ）、保持期間の 1 日が経過すると削除されます。
考察
有効化した時点の最新スナップショットがコピーされる
有効化前に作成したスナップショットが、有効化の 11 秒後にコピーされ始めました。再有効化した場合も、その時点の最新スナップショットが約 1 分 35 秒後にコピーされ始めています。ドキュメントの「新しく作成されたスナップショットがコピーされる」という説明とは異なり、アナウンスにある「次のスナップショットを待つ必要がない」動作を確認できました。
ただし、本検証では発表前の動作を同じ環境で確認していません。従来との違いは、ドキュメントの記述との比較によるものです。
コピーされるのは最新の 1 つだけ
有効化時にコピーされたのは最新のスナップショット 1 つだけで、それより前に作成したスナップショットは、観測した約 9 分間コピーされませんでした。本検証の範囲では、コピー先に作成されたのは、有効化した時点の最新スナップショットと、それ以降に作成されたスナップショットおよびリカバリーポイントです。有効化より前の時点のスナップショットをコピー先に置く必要がある場合は、この動作を前提に計画する必要があります。
コピー先は 1 リージョンまで
アナウンスには「destination region(s)」とありますが、Redshift Serverless では 2 つ目のコピー設定が ValidationException で拒否され、コンソールのリージョン選択も単一選択でした。本記事執筆時点では、1 つの名前空間に設定できるコピー先リージョンは 1 つです。
運用上の注意点
- コピー先でのスナップショット保持期間は、指定しないと無期限になります（ドキュメントとコンソールの既定値）。コピー先のストレージ料金を管理するには、保持期間を明示的に指定します
- コピー元のスナップショットに付けたタグは、コピー先のスナップショットには付いていませんでした。タグでコスト配分やリソースの棚卸しをしている場合は、コピー先のスナップショットを別途管理する必要があります
- コピー設定を削除しても、コピー済みのスナップショットはコピー先に残りました（削除の直後に確認）。不要になったコピーは、保持期間の経過を待つか手動で削除します
- コピー先にコピーされたリカバリーポイントは CLI から削除できず、1 日で削除されます
- 今回のスナップショットは 104 MB で、本記事のコピー時間とリストア時間はこのサイズでの結果です
料金
アナウンスでは、料金は Amazon Redshift の料金ページの「Backup and storage」と「Data transfer」を参照するよう案内されています。コンソールのクロスリージョンバックアップの編集画面にも、スナップショットがコピー先リージョンにコピーされるとデータ転送コストが発生する旨が表示されています。
AWS Pricing API で確認した、今回の検証に関係する東京リージョンの料金は以下のとおりです（2026 年 10 月 31 日時点）。
| 項目 | 料金 |
|---|---|
| Redshift Serverless コンピューティング | $0.494 / RPU 時間 |
| Redshift Serverless のスナップショットストレージ（PaidUniqueSnapshots:Serverless） | $0.025 / GB 月 |
また、Redshift Serverless のコンソールには、2026 年 6 月 8 日から RG ノードのプロビジョニングされたクラスターと Serverless の手動スナップショットに新しい課金モデルが適用され、アカウント内の全スナップショットにわたるユニークなデータブロックに基づいて課金されるという案内が表示されていました。
最後に
Amazon Redshift の自動クロスリージョンバックアップを、Redshift Serverless の東京から大阪へのコピーで試しました。クロスリージョンバックアップを有効化すると、その時点の最新スナップショットが次のスナップショットを待たずにコピーされ、その後に作成されたスナップショットとリカバリーポイントも自動でコピーされました。大阪にコピーされたスナップショットからのリストアも約 8 分 30 秒で完了し、データが東京と一致することを確認しました。
設定は既存の create-snapshot-copy-configuration（コンソールではクロスリージョンバックアップの編集画面）で行います。新たに有効化する場合は、有効化した時点の最新スナップショットからコピーが始まること、コピー先は 1 リージョンであること、コピー先の保持期間の既定が無期限であることを踏まえて設定してください。東京と大阪のように 2 つのリージョンで災害対策を構成している環境では、コピー先にどの時点以降のスナップショットがあるかと、保持期間を確認しておくことをおすすめします。
参考リンク
