[アップデート] AWS Backup の復元テストが Amazon Redshift に対応したので試してみた

AWS Backup の復元テスト機能が Amazon Redshift のプロビジョニングクラスターに対応しました。実際に復元テスト計画を作成し、復元からデータ確認、自動削除までを試してみた結果をお伝えします。
2026.11.04
クラウド事業統括本部の石川です。AWS Backup の復元テストが Amazon Redshift のプロビジョニングクラスターに対応しましたので、実際に復元テスト計画を作成し、復元からデータの確認、検証結果の登録、自動削除までを試してみました。
https://aws.amazon.com/jp/about-aws/whats-new/2026/10/aws-backup-adds-redshift-restore-testing/
AWS Backup の復元テストで Amazon Redshift がサポートされました。復元テストは、バックアップから実際に復元できるかを、スケジュールに従って自動で確認する機能です。復元ジョブの完了までにかかった時間も記録されるため、目標復旧時間（RTO）と比べることができます。
これまで復元テストの対象は、Aurora、Amazon DocumentDB、Amazon DynamoDB、Amazon EBS、Amazon EC2、Amazon EFS、Amazon FSx、Amazon Neptune、Amazon RDS、Amazon S3 でした。今回のアップデートで、ここに Amazon Redshift が加わりました。復元テスト計画への割り当ては ARN またはタグで行い、復旧ポイントは最新のものかランダムなものかを選べます。
https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html
 AWS Backup の復元テストとは復元テストは、「復元テスト計画」と「リソースの割り当て（復元テスト選択）」の2つで構成されます。
復元テスト計画: テストの頻度（cron 式）、開始時刻、開始ウィンドウ（開始時刻から何時間以内に始めるか）、どのボールトのどの期間の復旧ポイントを使うか（最新またはランダム）を指定します
リソースの割り当て: 対象のリソースタイプと保護されたリソース（ARN またはタグ条件）、復元に使う IAM ロール、復元パラメータの上書き、クリーンアップ前の保持時間を指定します
ドキュメントによると、スケジュールの時刻になると、AWS Backup は開始ウィンドウ内でランダムに決めた時刻に復元ジョブを開始します。復元ジョブはオンデマンドの復元と同じ方法で実行され、CloudTrail には StartRestoreJob の呼び出しとして記録されます。コンソールのジョブ一覧では、復元タイプが「テスト」のジョブとして表示されます。復元されたリソースは、検証結果が登録されるか保持時間が終わると、AWS Backup によって削除されます。削除はすぐには行われず、かかる時間はリソースタイプによって異なります。
このうち、開始ウィンドウ内に復元ジョブが開始されることと、検証結果の登録後に復元されたリソースが削除されることは、後半の「やってみた」で確認しました。CloudTrail の記録と、コンソールのジョブ一覧での復元タイプの表示は、今回は確認していません。
https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html
 Amazon Redshift の復元テストで押さえておくこと公式ドキュメントで確認した、Amazon Redshift 固有の仕様です。このうち、推定メタデータの内容と、コンソールで上書きできるパラメータは、「やってみた」の手順 3・5 でも確認しました。Redshift Serverless が対象外であること、クォータ、料金の構成は、ドキュメントと料金ページの記載に基づくもので、今回の検証では確認していません。
 対象はプロビジョニングクラスターのみAWS Backup の機能別サポート表では、復元テストの列にチェックがあるのは「Amazon Redshift」だけです。「Amazon Redshift Serverless」の行にはチェックがありません。Redshift Serverless の名前空間は、現時点では復元テストの対象外です。
https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html
 推定される復元メタデータと上書きできるパラメータ復元テストでは、復元に必要なメタデータを AWS Backup が推定します。Redshift の場合、推定されるのは次の4項目です。


キー
推定される値


clusterIdentifier
awsbackup-restore-test- で始まるランダムな値

encrypted
true

publiclyAccessible
false

restoreType
CLUSTER_RESTORE

上書きできるパラメータは、availabilityZone、clusterParameterGroupName、clusterSubnetGroupName、vpcSecurityGroupIds、nodeType、numberOfNodes、kmsKeyId、iamRoles、manageMasterPassword、port などです。vpcSecurityGroupIds のようなリスト型の値は、"[\"sg-xxxx\"]" のように JSON 配列を文字列にして指定します。
また、ドキュメントによると、AWS Backup はリソースをデフォルトの設定に復元するようにメタデータを推定することがあり（例として、Amazon EC2 インスタンスや Amazon RDS クラスターをデフォルト VPC に復元する場合が挙げられています）、デフォルト VPC やサブネットが削除されていて上書きも指定していない場合、復元は成功しません。今回の検証では、デフォルト VPC の無いアカウントでサブネットグループとセキュリティグループを上書きし、復元が成功することを確認しました。上書きを指定しなかった場合に復元が失敗するかどうかは試していません。
https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing-inferred-metadata.html
 クォータと料金ドキュメントのクォータ一覧によると、復元テスト計画から同時に実行できる Redshift の復元ジョブ数は、デフォルトで 30 です（引き上げ可能）。今回の検証で実行した復元ジョブは 1 つだけです。
https://docs.aws.amazon.com/aws-backup/latest/devguide/aws-backup-limits.html
料金ページによると、復元テストの料金は次の 2 つで構成されます。
評価料金: 復元テスト計画で復元を実行した復旧ポイントごとにかかる固定の料金。東京リージョンでは 1 復旧ポイントあたり $1.80 でした（2026 年 11 月 4 日時点、AWS Price List API で確認）
復元したデータ量に応じた料金: 特定のリソースタイプについて、月内に復元したデータ量（GB）に応じてかかる料金。単価は通常の復元料金と同じです
データ量に応じた料金について、AWS Price List API で東京リージョンの AWS Backup の料金項目を確認したところ、復元したデータ量（GB）単位の料金項目があるのは Amazon EFS、Amazon S3、Amazon DynamoDB、Amazon Timestream、Aurora DSQL、SAP HANA on Amazon EC2、VMware などで、Amazon Redshift の項目はありませんでした（2026 年 11 月 5 日時点）。
また、料金ページの注記にあるとおり、復元テストの料金とは別に、復元されたリソースを保持している間の料金がかかります。Redshift の場合は、復元されたクラスターが存在する間のノード料金です。
料金は改定されることがあるため、最新の単価と対象リソースタイプは料金ページで確認してください。
https://aws.amazon.com/backup/pricing/
 やってみた 前提条件リージョン: アジアパシフィック（東京）ap-northeast-1
Amazon Redshift: rg.large の単一ノードクラスター（クラスターバージョン 1.0.520420）
東京リージョンにデフォルト VPC が無いアカウントで検証しました。そのため、検証専用の VPC とプライベートサブネット 2 つ（1a / 1c）、Redshift のサブネットグループ、インバウンドルールの無いセキュリティグループを先に作成しています
復元用の IAM ロールは AWS Backup のデフォルトロール（AWSBackupDefaultServiceRole）を使いました
検証の流れは次のとおりです。前提リソースの作成、バックアップ、データ確認は AWS CLI で、復元テスト計画の作成はマネジメントコンソールで行いました。
 1. 検証用のクラスターとサンプルデータを用意するrg.large の単一ノードクラスターを作成しました。
% aws redshift create-cluster \
  --cluster-identifier rsrt-source \
  --node-type rg.large \
  --cluster-type single-node \
  --db-name dev \
  --master-username awsuser \
  --master-user-password "${MASTER_PW}" \
  --cluster-subnet-group-name rsrt-subnet-group \
  --vpc-security-group-ids sg-04a466d0eac8c0ffd \
  --no-publicly-accessible \
  --query 'Cluster.{Id:ClusterIdentifier,NodeType:NodeType,Nodes:NumberOfNodes,Status:ClusterStatus,Encrypted:Encrypted,AZ:AvailabilityZone}' \
  --output table
-----------------------------------------------------------------------
|                            CreateCluster                            |
+------+------------+--------------+-----------+---------+------------+
|  AZ  | Encrypted  |     Id       | NodeType  |  Nodes  |  Status    |
+------+------------+--------------+-----------+---------+------------+
|  None|  True      |  rsrt-source |  rg.large |  1      |  creating  |
+------+------------+--------------+-----------+---------+------------+
Redshift Data API で、テーブル作成と 5 行の INSERT を行いました。Data API の --db-user を指定すると一時的な認証情報で接続できるため、管理者パスワードを使わずに SQL を実行できます。
% aws redshift-data execute-statement \
  --cluster-identifier rsrt-source --database dev --db-user awsuser \
  --sql "CREATE TABLE public.sales (sale_id INT, item VARCHAR(32), amount INT, sold_at DATE);"

% aws redshift-data execute-statement \
  --cluster-identifier rsrt-source --database dev --db-user awsuser \
  --sql "INSERT INTO public.sales VALUES (1,'coffee',450,'2026-11-01'),(2,'tea',380,'2026-11-01'),(3,'cake',520,'2026-11-02'),(4,'coffee',450,'2026-11-03'),(5,'sandwich',680,'2026-11-03');"
バックアップ前の値を記録しておきます。復元後にこの値と比べます。
SELECT COUNT(*) AS cnt, SUM(amount) AS total_amount, MAX(sold_at) AS last_sold FROM public.sales;


cnt
total_amount
last_sold


5
2480
2026-11-03

 2. AWS Backup でオンデマンドバックアップを取得するこのアカウントでは、AWS Backup のサービスのオプトインで Redshift が無効になっていました。有効にしてから、検証専用のボールト rsrt-vault を作成しました。
% aws backup update-region-settings --resource-type-opt-in-preference Redshift=true
% aws backup create-backup-vault --backup-vault-name rsrt-vault
オンデマンドバックアップを開始します。
% aws backup start-backup-job \
  --backup-vault-name rsrt-vault \
  --resource-arn arn:aws:redshift:ap-northeast-1:123456789012:cluster:rsrt-source \
  --iam-role-arn arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole \
  --lifecycle DeleteAfterDays=7 \
  --output table
----------------------------------------------------------
|                     StartBackupJob                     |
+---------------+----------------------------------------+
|  BackupJobId  |  876e43e8-00a8-46e4-ad2e-7f07a419c414  |
|  CreationDate |  2026-11-04T11:55:15.634000+09:00      |
|  IsParent     |  False                                 |
+---------------+----------------------------------------+
バックアップジョブは約 1 分で COMPLETED になりました。Redshift の復旧ポイントは、Redshift の手動スナップショットとして作成されます。
% aws backup describe-backup-job --backup-job-id 876e43e8-00a8-46e4-ad2e-7f07a419c414 \
  --query "{State:State,ResourceType:ResourceType,RecoveryPointArn:RecoveryPointArn,Created:CreationDate,Completed:CompletionDate,Message:StatusMessage}" \
  --output table
----------------------------------------------------------------------------------------------------------------------------------------------
|                                                              DescribeBackupJob                                                             |
+------------------+-------------------------------------------------------------------------------------------------------------------------+
|  Completed       |  2026-11-04T11:56:17.164000+09:00                                                                                       |
|  Created         |  2026-11-04T11:55:15.634000+09:00                                                                                       |
|  Message         |  None                                                                                                                   |
|  RecoveryPointArn|  arn:aws:redshift:ap-northeast-1:123456789012:snapshot:rsrt-source/awsbackup:job-876e43e8-00a8-46e4-ad2e-7f07a419c414   |
|  ResourceType    |  Redshift                                                                                                               |
|  State           |  COMPLETED                                                                                                              |
+------------------+-------------------------------------------------------------------------------------------------------------------------+
 3. 推定メタデータを確認するget-restore-testing-inferred-metadata で、復元テストのときに AWS Backup が推定するメタデータを事前に確認できます。
% aws backup get-restore-testing-inferred-metadata \
  --backup-vault-name rsrt-vault \
  --recovery-point-arn "arn:aws:redshift:ap-northeast-1:123456789012:snapshot:rsrt-source/awsbackup:job-876e43e8-00a8-46e4-ad2e-7f07a419c414"
{
    "InferredMetadata": {
        "clusteridentifier": "awsbackup-restore-test-ab1a338f-2092-43e4-aeac-247d957c9f2d",
        "encrypted": "true",
        "publiclyaccessible": "false",
        "restoretype": "CLUSTER_RESTORE"
    }
}
ドキュメントのとおり、推定されるのは 4 項目だけでした。サブネットグループとセキュリティグループは推定メタデータに含まれていません。前述のとおり、ドキュメントでは、デフォルト VPC やサブネットが存在せず上書きも指定していない場合、復元は成功しないと説明されています。今回のアカウントにはデフォルト VPC が無いため、次の手順でサブネットグループとセキュリティグループを上書きすることにしました。
 4. 復元テスト計画を作成する（コンソール）AWS Backup コンソールの「復元テスト」から「復元テストプランを作成」を選びます。設定した内容は次のとおりです。
復元テストプラン名: rsrt_redshift_plan
テスト頻度: 毎日
開始時間: 12:10（Asia/Tokyo）
次の時間以内に開始: 1 時間（指定できる最小値）
ソースボールト: 特定のボールト（rsrt-vault）
対象となる復旧ポイント: 過去 7 日間
復旧ポイントの選択基準: 最近の復旧ポイント
開始ウィンドウを 1 時間にすると、「開始時間枠が短いと、同時に実行できる復元テストジョブ数のクォータが原因で失敗する可能性がある」という趣旨の警告が表示されました。今回はジョブが 1 つだけなので、そのまま進めています。
 5. リソースを割り当てて復元パラメータを上書きする（コンソール）計画を作成すると、そのまま「リソースを割り当てる」画面に移ります。リソースタイプの一覧に「Redshift」が追加されています。
設定した内容は次のとおりです。
リソース割り当て名: rsrt_redshift_selection
IAM ロール: デフォルトのロール
クリーンアップ前の保持期間: 特定の時間数について保持（2 時間）
リソースタイプ: Redshift
リソースの選択の範囲: 特定の保護されたリソース（rsrt-source）
「復元パラメータ」には、編集できない既定値として「クラスター識別子（ランダムな識別子は awsbackup-restore-test で始まる）」「暗号化: True」「パブリックにアクセス可能: False」「復元のタイプ: クラスター」が表示されます。手順 3 で確認した推定メタデータと同じ内容です。
「オプションパラメータを追加」から上書きできるパラメータは、次の 13 個でした。
ここで「クラスターサブネットグループ」に rsrt-subnet-group を、「VPC セキュリティグループ」に rsrt-redshift-sg を指定しました。
作成した計画と割り当てを CLI で確認すると、コンソールで指定した上書きが RestoreMetadataOverrides に入っていました。VpcSecurityGroupIds は JSON 配列の文字列になっています。
% aws backup get-restore-testing-selection \
  --restore-testing-plan-name rsrt_redshift_plan \
  --restore-testing-selection-name rsrt_redshift_selection
{
    "RestoreTestingSelection": {
        "CreationTime": "2026-11-04T12:00:19.835000+09:00",
        "IamRoleArn": "arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole",
        "ProtectedResourceArns": [
            "arn:aws:redshift:ap-northeast-1:123456789012:cluster:rsrt-source"
        ],
        "ProtectedResourceConditions": {
            "StringEquals": [],
            "StringNotEquals": []
        },
        "ProtectedResourceType": "Redshift",
        "RestoreMetadataOverrides": {
            "ClusterSubnetGroupName": "rsrt-subnet-group",
            "VpcSecurityGroupIds": "[\"sg-04a466d0eac8c0ffd\"]"
        },
        "RestoreTestingPlanName": "rsrt_redshift_plan",
        "RestoreTestingSelectionName": "rsrt_redshift_selection",
        "ValidationWindowHours": 2
    }
}
計画のほうは、コンソールの「毎日 12:10」が cron(10 12 ? * * *)、「最近の復旧ポイント」が LATEST_WITHIN_WINDOW として保存されていました。
% aws backup get-restore-testing-plan --restore-testing-plan-name rsrt_redshift_plan
{
    "RestoreTestingPlan": {
        "CreationTime": "2026-11-04T11:58:17.809000+09:00",
        "LastUpdateTime": "2026-11-04T11:58:17.809000+09:00",
        "RecoveryPointSelection": {
            "Algorithm": "LATEST_WITHIN_WINDOW",
            "ExcludeVaults": [],
            "IncludeVaults": [
                "arn:aws:backup:ap-northeast-1:123456789012:backup-vault:rsrt-vault"
            ],
            "RecoveryPointTypes": [
                "SNAPSHOT"
            ],
            "SelectionWindowDays": 7
        },
        "RestoreTestingPlanArn": "arn:aws:backup:ap-northeast-1:123456789012:restore-testing-plan:rsrt_redshift_plan-9e90b8bc-454c-4764-83e3-238ffc2500b6",
        "RestoreTestingPlanName": "rsrt_redshift_plan",
        "ScheduleExpression": "cron(10 12 ? * * *)",
        "ScheduleExpressionTimezone": "Asia/Tokyo",
        "StartWindowHours": 1
    }
}
 6. 復元ジョブの結果を確認する次のループで list-restore-jobs を 60 秒間隔で実行して、ジョブが作成されるのを待ちました。出力の各行の先頭の時刻は、ループ内で付けた実行時刻（JST）です。ジョブが COMPLETED になった後に、ジョブ一覧を JSON で出力しています。開始時刻の 12:10 から約 21 分後の 12:31 にジョブが作成され、12:33 に COMPLETED になりました。
% PLAN_ARN="arn:aws:backup:ap-northeast-1:123456789012:restore-testing-plan:rsrt_redshift_plan-9e90b8bc-454c-4764-83e3-238ffc2500b6"

% for i in $(seq 1 150); do
  L=$(aws backup list-restore-jobs --by-restore-testing-plan-arn "$PLAN_ARN" \
        --query "RestoreJobs[0].[RestoreJobId,Status,PercentDone,CreatedResourceArn]" --output text 2>&1)
  echo "$(TZ=Asia/Tokyo date +%H:%M:%S) $L"
  S=$(echo "$L" | awk '{print $2}')
  case "$S" in COMPLETED|FAILED|ABORTED) break;; esac
  sleep 60
done
12:00:44 None
12:01:45 None
12:02:46 None
12:03:46 None
12:04:47 None
12:05:48 None
12:06:48 None
12:07:49 None
12:08:50 None
12:09:50 None
12:10:51 None
12:11:52 None
12:12:52 None
12:13:53 None
12:14:54 None
12:15:54 None
12:16:55 None
12:17:56 None
12:18:56 None
12:19:57 None
12:20:58 None
12:21:58 None
12:22:59 None
12:24:00 None
12:25:00 None
12:26:01 None
12:27:02 None
12:28:02 None
12:29:03 None
12:30:04 None
12:31:05 None
12:32:05 63a3d8a4-54a4-4faa-9ae7-e92f4c51e223	RUNNING	0.00%	None
12:33:06 63a3d8a4-54a4-4faa-9ae7-e92f4c51e223	RUNNING	0.00%	arn:aws:redshift:ap-northeast-1:123456789012:cluster:awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22
12:34:06 63a3d8a4-54a4-4faa-9ae7-e92f4c51e223	COMPLETED	100.00%	arn:aws:redshift:ap-northeast-1:123456789012:cluster:awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22

% aws backup list-restore-jobs --by-restore-testing-plan-arn "$PLAN_ARN" --output json
{
    "RestoreJobs": [
        {
            "AccountId": "123456789012",
            "RestoreJobId": "63a3d8a4-54a4-4faa-9ae7-e92f4c51e223",
            "RecoveryPointArn": "arn:aws:redshift:ap-northeast-1:123456789012:snapshot:rsrt-source/awsbackup:job-876e43e8-00a8-46e4-ad2e-7f07a419c414",
            "SourceResourceArn": "arn:aws:redshift:ap-northeast-1:123456789012:cluster:rsrt-source",
            "BackupVaultArn": "arn:aws:backup:ap-northeast-1:123456789012:backup-vault:rsrt-vault",
            "CreationDate": "2026-11-04T12:31:27.995000+09:00",
            "CompletionDate": "2026-11-04T12:33:45.841000+09:00",
            "Status": "COMPLETED",
            "PercentDone": "100.00%",
            "BackupSizeInBytes": 0,
            "IamRoleArn": "arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole",
            "CreatedResourceArn": "arn:aws:redshift:ap-northeast-1:123456789012:cluster:awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22",
            "ResourceType": "Redshift",
            "RecoveryPointCreationDate": "2026-11-04T11:55:15.634000+09:00",
            "IsParent": false,
            "CreatedBy": {
                "RestoreTestingPlanArn": "arn:aws:backup:ap-northeast-1:123456789012:restore-testing-plan:rsrt_redshift_plan-9e90b8bc-454c-4764-83e3-238ffc2500b6"
            }
        }
    ]
}
describe-restore-job の結果です。CreationDate から CompletionDate までは 2 分 18 秒でした。CreatedBy に復元テスト計画の ARN が入っていて、ValidationStatus は VALIDATING になっています。
% aws backup describe-restore-job --restore-job-id 63a3d8a4-54a4-4faa-9ae7-e92f4c51e223
{
    "AccountId": "123456789012",
    "RestoreJobId": "63a3d8a4-54a4-4faa-9ae7-e92f4c51e223",
    "RecoveryPointArn": "arn:aws:redshift:ap-northeast-1:123456789012:snapshot:rsrt-source/awsbackup:job-876e43e8-00a8-46e4-ad2e-7f07a419c414",
    "SourceResourceArn": "arn:aws:redshift:ap-northeast-1:123456789012:cluster:rsrt-source",
    "BackupVaultArn": "arn:aws:backup:ap-northeast-1:123456789012:backup-vault:rsrt-vault",
    "CreationDate": "2026-11-04T12:31:27.995000+09:00",
    "CompletionDate": "2026-11-04T12:33:45.841000+09:00",
    "Status": "COMPLETED",
    "PercentDone": "100.00%",
    "BackupSizeInBytes": 0,
    "IamRoleArn": "arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole",
    "CreatedResourceArn": "arn:aws:redshift:ap-northeast-1:123456789012:cluster:awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22",
    "ResourceType": "Redshift",
    "RecoveryPointCreationDate": "2026-11-04T11:55:15.634000+09:00",
    "CreatedBy": {
        "RestoreTestingPlanArn": "arn:aws:backup:ap-northeast-1:123456789012:restore-testing-plan:rsrt_redshift_plan-9e90b8bc-454c-4764-83e3-238ffc2500b6"
    },
    "ValidationStatus": "VALIDATING",
    "IsParent": false
}
コンソールの復元テストプランの詳細画面にも、ステータス「完了」、復元時間「2 分」のジョブが表示されました。
get-restore-job-metadata で、実際の復元に使われたメタデータを確認しました。推定された 4 項目に、上書きした clustersubnetgroupname と vpcsecuritygroupids が加わっています。
% aws backup get-restore-job-metadata --restore-job-id 63a3d8a4-54a4-4faa-9ae7-e92f4c51e223
{
    "RestoreJobId": "63a3d8a4-54a4-4faa-9ae7-e92f4c51e223",
    "Metadata": {
        "clusteridentifier": "awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22",
        "clustersubnetgroupname": "rsrt-subnet-group",
        "encrypted": "true",
        "publiclyaccessible": "false",
        "restoretype": "CLUSTER_RESTORE",
        "vpcsecuritygroupids": "[\"sg-04a466d0eac8c0ffd\"]"
    }
}
復元されたクラスターは、元のクラスターと同じ rg.large の単一ノードで、指定したサブネットグループとセキュリティグループに作成されていました。AZ は元のクラスター（ap-northeast-1c）とは異なる ap-northeast-1a でした。
% aws redshift describe-clusters --cluster-identifier awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22 \
  --query "Clusters[0].{Id:ClusterIdentifier,Status:ClusterStatus,NodeType:NodeType,Nodes:NumberOfNodes,AZ:AvailabilityZone,SubnetGroup:ClusterSubnetGroupName,SG:VpcSecurityGroups[0].VpcSecurityGroupId,VpcId:VpcId,Encrypted:Encrypted,Public:PubliclyAccessible,Created:ClusterCreateTime}" \
  --output table
--------------------------------------------------------------------------------
|                               DescribeClusters                               |
+-------------+----------------------------------------------------------------+
|  AZ         |  ap-northeast-1a                                               |
|  Created    |  2026-11-04T03:33:31.841000+00:00                              |
|  Encrypted  |  True                                                          |
|  Id         |  awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22   |
|  NodeType   |  rg.large                                                      |
|  Nodes      |  1                                                             |
|  Public     |  False                                                         |
|  SG         |  sg-04a466d0eac8c0ffd                                          |
|  Status     |  available                                                     |
|  SubnetGroup|  rsrt-subnet-group                                             |
|  VpcId      |  vpc-02c2dca3c3d3d8bf1                                         |
+-------------+----------------------------------------------------------------+
復元されたクラスターのタグも確認しました。元のクラスターに付けていた 4 つのタグがそのまま付いていて、ドキュメントで説明されている awsbackup-restore-test タグは、この時点（13:02）では付いていませんでした。
% aws redshift describe-clusters --cluster-identifier awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22 \
  --query "Clusters[0].Tags" --output table
---------------------------------------
|          DescribeClusters           |
+----------+--------------------------+
|    Key   |          Value           |
+----------+--------------------------+
|  owner   |  ishikawa                |
|  run_id  |  rsrt-20261104-9847c7a8  |
|  purpose |  blog-verification       |
|  ttl     |  2026-11-04T08:52:43Z    |
+----------+--------------------------+
 7. 復元されたクラスターのデータを確認する復元されたクラスターに、手順 1 と同じ集計 SQL を Data API で実行しました。
aws redshift-data execute-statement \
  --cluster-identifier awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22 \
  --database dev --db-user awsuser \
  --sql "SELECT COUNT(*) AS cnt, SUM(amount) AS total_amount, MAX(sold_at) AS last_sold FROM public.sales;"
+-----+--------------+------------+
| cnt | total_amount | last_sold  |
+-----+--------------+------------+
| 5   | 2480         | 2026-11-03 |
+-----+--------------+------------+
全行も取得しました。バックアップ前に投入した 5 行と一致しています。


sale_id
item
amount
sold_at


1
coffee
450
2026-11-01

2
tea
380
2026-11-01

3
cake
520
2026-11-02

4
coffee
450
2026-11-03

5
sandwich
680
2026-11-03

 8. 検証結果を登録して自動削除を確認する確認した結果を put-restore-validation-result で登録しました。
% aws backup put-restore-validation-result \
  --restore-job-id 63a3d8a4-54a4-4faa-9ae7-e92f4c51e223 \
  --validation-status SUCCESSFUL \
  --validation-status-message "row count 5 / sum(amount) 2480 / max(sold_at) 2026-11-03 matched source"
登録の 5 秒後に確認すると、ValidationStatus が SUCCESSFUL になっていました。この時点では DeletionStatus は空で、復元されたクラスターは available のままでした。
% aws backup describe-restore-job --restore-job-id 63a3d8a4-54a4-4faa-9ae7-e92f4c51e223 \
  --query "{Status:Status,ValidationStatus:ValidationStatus,ValidationStatusMessage:ValidationStatusMessage,DeletionStatus:DeletionStatus,DeletionStatusMessage:DeletionStatusMessage}" \
  --output table
--------------------------------------------------------------------------------------------------------
|                                          DescribeRestoreJob                                          |
+--------------------------+---------------------------------------------------------------------------+
|  DeletionStatus          |  None                                                                     |
|  DeletionStatusMessage   |  None                                                                     |
|  Status                  |  COMPLETED                                                                |
|  ValidationStatus        |  SUCCESSFUL                                                               |
|  ValidationStatusMessage |  row count 5 / sum(amount) 2480 / max(sold_at) 2026-11-03 matched source  |
+--------------------------+---------------------------------------------------------------------------+
% aws redshift describe-clusters --cluster-identifier awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22 \
  --query "Clusters[0].ClusterStatus" --output text
available
コンソールのジョブ詳細画面でも、検証ステータスが「成功」になりました。
その後、次のループで、削除ステータスと復元されたクラスターの状態を 60 秒間隔で確認しました。出力の各行の先頭の時刻は、ループ内で付けた実行時刻（JST）です。DeletionStatus が SUCCESSFUL になった後に、復元ジョブの状態をテーブルで出力しています。
% RJ_ID=63a3d8a4-54a4-4faa-9ae7-e92f4c51e223
% RESTORED=awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22

% for i in $(seq 1 90); do
  D=$(aws backup describe-restore-job --restore-job-id $RJ_ID \
        --query "[DeletionStatus,DeletionStatusMessage]" --output text 2>&1)
  C=$(aws redshift describe-clusters --cluster-identifier $RESTORED \
        --query "Clusters[0].ClusterStatus" --output text 2>&1 | tail -1)
  echo "$(TZ=Asia/Tokyo date +%H:%M:%S) deletion=[$D] cluster=[$C]"
  case "$D" in SUCCESSFUL*|FAILED*) break;; esac
  sleep 60
done
13:03:10 deletion=[None	None] cluster=[available]
13:04:12 deletion=[None	None] cluster=[available]
13:05:14 deletion=[None	None] cluster=[available]
13:06:15 deletion=[None	None] cluster=[available]
13:07:17 deletion=[None	None] cluster=[available]
13:08:18 deletion=[None	None] cluster=[available]
13:09:20 deletion=[None	None] cluster=[available]
13:10:22 deletion=[None	None] cluster=[available]
13:11:23 deletion=[None	None] cluster=[available]
13:12:25 deletion=[None	None] cluster=[available]
13:13:26 deletion=[DELETING	None] cluster=[deleting]
13:14:28 deletion=[DELETING	None] cluster=[aws: [ERROR]: An error occurred (ClusterNotFound) when calling the DescribeClusters operation: Cluster awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22 not found.]
13:15:29 deletion=[DELETING	None] cluster=[aws: [ERROR]: An error occurred (ClusterNotFound) when calling the DescribeClusters operation: Cluster awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22 not found.]
13:16:30 deletion=[DELETING	None] cluster=[aws: [ERROR]: An error occurred (ClusterNotFound) when calling the DescribeClusters operation: Cluster awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22 not found.]
13:17:31 deletion=[DELETING	None] cluster=[aws: [ERROR]: An error occurred (ClusterNotFound) when calling the DescribeClusters operation: Cluster awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22 not found.]
13:18:33 deletion=[DELETING	None] cluster=[aws: [ERROR]: An error occurred (ClusterNotFound) when calling the DescribeClusters operation: Cluster awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22 not found.]
13:19:34 deletion=[DELETING	None] cluster=[aws: [ERROR]: An error occurred (ClusterNotFound) when calling the DescribeClusters operation: Cluster awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22 not found.]
13:20:35 deletion=[DELETING	None] cluster=[aws: [ERROR]: An error occurred (ClusterNotFound) when calling the DescribeClusters operation: Cluster awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22 not found.]
13:21:36 deletion=[DELETING	None] cluster=[aws: [ERROR]: An error occurred (ClusterNotFound) when calling the DescribeClusters operation: Cluster awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22 not found.]
13:22:37 deletion=[SUCCESSFUL	None] cluster=[aws: [ERROR]: An error occurred (ClusterNotFound) when calling the DescribeClusters operation: Cluster awsbackup-restore-test-17b2d653-504e-4466-a6dd-9233e8182e22 not found.]

% aws backup describe-restore-job --restore-job-id $RJ_ID \
  --query "{Status:Status,ValidationStatus:ValidationStatus,DeletionStatus:DeletionStatus,DeletionStatusMessage:DeletionStatusMessage}" \
  --output table
------------------------------------------------------------------------------
|                             DescribeRestoreJob                             |
+----------------+-------------------------+------------+--------------------+
| DeletionStatus |  DeletionStatusMessage  |  Status    | ValidationStatus   |
+----------------+-------------------------+------------+--------------------+
|  SUCCESSFUL    |  None                   |  COMPLETED |  SUCCESSFUL        |
+----------------+-------------------------+------------+--------------------+
検証結果を登録した 13:02 から約 10 分後の 13:13 に DeletionStatus が DELETING になりました。その 1 分後にはクラスターが ClusterNotFound になり、13:22 に DeletionStatus が SUCCESSFUL になりました。保持時間に設定した 2 時間を待たずに、検証結果の登録をきっかけに削除が始まっています。
削除後に Redshift のスナップショットを確認すると、残っていたのは AWS Backup の復旧ポイント（手動スナップショット）だけでした。復元されたクラスターの最終スナップショットは作成されていません。
% aws redshift describe-cluster-snapshots \
  --query "Snapshots[?starts_with(ClusterIdentifier, \`awsbackup-restore-test\`) || ClusterIdentifier==\`rsrt-source\`].{Id:SnapshotIdentifier,Cluster:ClusterIdentifier,Type:SnapshotType,Status:Status,Created:SnapshotCreateTime}" \
  --output table
-------------------------------------------------------------------
|                    DescribeClusterSnapshots                     |
+---------+-------------------------------------------------------+
|  Cluster|  rsrt-source                                          |
|  Created|  2026-11-04T02:55:29.210000+00:00                     |
|  Id     |  awsbackup:job-876e43e8-00a8-46e4-ad2e-7f07a419c414   |
|  Status |  available                                            |
|  Type   |  manual                                               |
+---------+-------------------------------------------------------+
 考察 デフォルト VPC が無い環境では、サブネットグループとセキュリティグループを上書きするRedshift の推定メタデータには、サブネットグループとセキュリティグループが含まれていませんでした。ドキュメントでは、デフォルトの設定が存在せず上書きも無い場合、復元は失敗すると説明されています。今回はデフォルト VPC の無いアカウントで clusterSubnetGroupName と vpcSecurityGroupIds を上書きし、指定したとおりの場所に復元されることを確認しました。上書きしなかった場合の動作は、今回は試していません。
本番のクラスターを復元テストに入れる場合は、復元先のサブネットグループとセキュリティグループを本番とは別に用意しておくと、本番のネットワークに復元テスト用のクラスターが作られることを避けられます。
 復元時間はデータ量に依存するため、実際のクラスターで測る今回の復元ジョブは 2 分 18 秒で完了しました。これはバックアップサイズ 48 MB（get-recovery-point-restore-metadata の TotalBackupSizeInMegaBytes）、rg.large の単一ノードという小さな構成での値です。RTO の確認に使う場合は、実際のクラスターを対象にした復元テストの結果を使う必要があります。
復元時間を継続的に評価したい場合は、AWS Backup Audit Manager の「Restore time for resources meet target」コントロールで、目標の復元時間を超えていないかを確認できます。
https://docs.aws.amazon.com/help-panel/aws-backup/latest/helppanel/control-restore-time-meets-target.html
 開始時刻はウィンドウ内でばらつく開始時刻を 12:10、開始ウィンドウを 1 時間にした今回の計画では、ジョブの作成は 12:31 でした。開始ウィンドウの最小値は 1 時間です（ドキュメントのクォータ一覧では最小 1 時間、最大 168 時間）。
また、本検証時点（2026 年 11 月 4 日）では、復元テスト計画をその場で実行する操作を確認できませんでした。確認した範囲は、AWS CLI（aws-cli/2.39.3）の aws backup help のコマンド一覧のうち名前に restore-testing・restore-job・validation を含むコマンドと、マネジメントコンソールの復元テストプランの作成画面と詳細画面です。これ以外の方法で実行できるかどうかは確認していません。
復元後にデータを確認する作業を人が行う場合は、開始ウィンドウと保持時間の両方を考慮して時間を確保しておく必要があります。
https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html
 データの確認は Data API で行える復元されたクラスターはパブリックアクセスが無効で、インバウンドルールの無いセキュリティグループに作成されています。それでも、Redshift Data API に --db-user を指定することで、ネットワークの経路を用意せずに SQL を実行してデータを確認できました。ドキュメントでは、復元ジョブの完了イベント（EventBridge の Restore Job State Change）で Lambda 関数を起動し、確認結果を PutRestoreValidationResult で登録する方法が紹介されています。Data API を使ったこの確認は、その Lambda 関数の処理として組み込めます。
https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing-validation.html
なお、AWS Backup のドキュメントの「Restore an Amazon Redshift cluster」のページでは、Amazon Redshift の管理パスワード（AWS Secrets Manager で管理する管理者パスワード）を使っているクラスターを復元する場合、復元メタデータで ManageMasterPassword を true にすることと、復元用の IAM ロールに Secrets Manager の権限（secretsmanager:CreateSecret など）を追加することが必要と説明されています。このページは復元テストではなく、通常の復元について説明したものです。
今回の検証は管理パスワードを使わないクラスターで行ったため、この設定は試していません。管理パスワードを使うクラスターを復元テストの対象にした場合の動作や、復元テストの割り当てで manageMasterPassword を上書きした場合の動作は確認していません。
https://docs.aws.amazon.com/aws-backup/latest/devguide/redshift-restores.html
 検証結果を登録すると、保持時間を待たずに削除が始まる保持時間を 2 時間に設定していましたが、検証結果を登録してから約 10 分後に削除が始まり、約 20 分後に削除ステータスが SUCCESSFUL になりました。検証を自動化して、復元の完了後に結果を登録すれば、復元されたクラスターが存在する時間を短くでき、その分のノード料金を抑えられます。
 復元されたクラスターには元のクラスターのタグが付く復元されたクラスターには、元のクラスターに付けていたタグがそのまま付いていました。一方で、ドキュメントで tag-on-restore 対応リソースに付くと説明されている awsbackup-restore-test タグは、今回確認した時点では付いていませんでした。元のクラスターのタグを使ってコスト配分やタグベースの自動処理をしている場合は、復元されたクラスターも同じタグを持つことを前提にしておく必要があります。なお、通常のバックアッププランは、名前が awsbackup-restore-test で始まるリソースを対象外にするとドキュメントに書かれています。
 今後に期待することRedshift Serverless の名前空間への対応（現時点では復元テストの対象外）
復元テスト計画をその場で実行する操作
 最後にAWS Backup の復元テストが Amazon Redshift のプロビジョニングクラスターに対応したので、復元テスト計画の作成から、復元、データの確認、検証結果の登録、自動削除までを一通り試しました。
コンソールのリソースタイプに Redshift が追加され、ARN で指定したクラスターの復元テストを、ほかのリソースと同じ手順で設定できました
推定メタデータにはサブネットグループとセキュリティグループが含まれないため、デフォルト VPC が無い環境では上書きが必要でした
復元されたクラスターに Data API で接続し、バックアップ前と同じデータであることを確認できました
復元ジョブは 2 分 18 秒で完了しました。ただし、これはバックアップサイズ 48 MB、rg.large の単一ノードという小さな構成での値です。RTO の確認には、実際のクラスターを対象にした復元テストの結果を使う必要があります
検証結果を登録すると、保持時間を待たずに復元されたクラスターが削除され、最終スナップショットも残りませんでした
これまで Redshift の復元確認を手作業のスナップショット復元で行っていた場合は、復元テスト計画に置き換えることで、定期的な実行、復元時間の記録、テスト後の削除を AWS Backup に任せられます。まずは小さなクラスターを 1 つだけ割り当てて、復元先のネットワーク設定と所要時間、費用を確認してから、対象を広げていくとよいと思います。Redshift Serverless を使っている場合は、現時点では復元テストの対象外である点に注意してください。