[アップデート] Amazon Redshift Serverless のスナップショット復元で zero-ETL 統合と S3 イベント統合が自動維持されるようになったので試してみた

Amazon Redshift Serverless のスナップショット復元時に、zero-ETL 統合と S3 イベント統合が自動的に保持されるようになったこのアップデートを、実際に S3 Auto-copy で検証してみました。
2026.07.19
クラウド事業統括本部の石川です。Amazon Redshift Serverless のスナップショット復元時に zero-ETL 統合と Amazon S3 イベント統合が自動的に保持されるようになりましたので、実際に試してみました。
https://aws.amazon.com/jp/about-aws/whats-new/2026/07/redshift-serverless-zetl-autocopy-restore/
これまで Amazon Redshift Serverless では、スナップショットやリカバリポイントからネームスペースを復元すると、関連付けられた zero-ETL 統合や S3 イベント統合がFAILEDとしてマークされ、復元完了後に手動で再作成する必要がありました。データパイプラインの再設定に時間がかかるうえ、再構築中にデータ取り込みのギャップが発生する可能性もありました。
今回のアップデートにより、同一のサーバーレスネームスペースへ復元する場合、これらの統合は自動的に維持され、復元完了後にそのまま動作を再開するようになりました。この動作は Amazon Redshift の Patch 202 以降でデフォルトで有効になります。
https://docs.aws.amazon.com/redshift/latest/mgmt/behavior-changes.html#serverless-restore-integrations-patch202
本記事では、S3 イベント統合（auto-copy）を使って、復元前後で統合がどのように扱われるかを検証します。
 S3 イベント統合と auto-copy とはS3 イベント統合（Amazon S3 event integration）は、Amazon S3 バケットと Amazon Redshift の間で接続を確立し、ファイル作成イベントを検知するための基盤です。auto-copy はこの統合を利用した機能で、COPY コマンドに JOB CREATE 句を付けて COPY JOB を定義しておくと、S3 に追加された新しいファイルを検知して自動的にテーブルへロードします。ETL パイプラインを別途構築することなく、S3 への継続的なファイル連携を実現できます。
https://docs.aws.amazon.com/redshift/latest/dg/loading-data-copy-job.html
なお、zero-ETL 統合（Amazon Aurora、Amazon RDS、Amazon DynamoDB などからのフルマネージドなデータ連携）も今回のアップデートの対象ですが、本記事では構成がシンプルな S3 イベント統合で検証します。復元時の統合保持という観点では挙動は共通です。
 やってみた 前提条件AWS CLI v2（検証時: 2.36.2）
検証環境: ap-northeast-1（東京）
Amazon Redshift Serverless（ベースキャパシティ 8 RPU）
検証の流れは以下のとおりです。スナップショットの前後および復元の前後でファイルを追加し、統合とデータがどう扱われるかを確認します。
 Auto-copy用のS3 バケットの準備データソースとなる S3 バケットを作成し、S3 イベント統合の前提となるバケットポリシーを設定します。バケットポリシーでは redshift.amazonaws.com サービスプリンシパルに対してイベント通知関連の権限を許可します。
% aws s3 mb s3://cm-blog-tryit-autocopy --region ap-northeast-1
make_bucket: cm-blog-tryit-autocopy

% aws s3api put-bucket-policy --bucket cm-blog-tryit-autocopy \
  --policy '{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AutoCopyPolicy01",
      "Effect": "Allow",
      "Principal": {"Service": "redshift.amazonaws.com"},
      "Action": [
        "s3:GetBucketNotification",
        "s3:PutBucketNotification",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::cm-blog-tryit-autocopy",
      "Condition": {
        "ArnLike": {"aws:SourceArn": "arn:aws:redshift:ap-northeast-1:123456789012:integration:*"},
        "StringEquals": {"aws:SourceAccount": "123456789012"}
      }
    }
  ]
}'
あわせて、COPY JOB が S3 からデータを読み取るための IAM ロールを用意します。今回はマネジメントコンソールから作成済みの AmazonRedshift-CommandsAccessRole を利用しました。新規に作成する場合は、信頼ポリシーで redshift.amazonaws.com を許可し、対象バケットへの s3:GetObject と s3:ListBucket を付与したロールを作成してください。
 ネームスペースとワークグループの作成作成した IAM ロールをデフォルト IAM ロールとして関連付けたネームスペースと、最小構成（8 RPU）のワークグループを作成します。
ワークグループは 4 分ほどで AVAILABLE になりました。
 S3 イベント統合の作成統合を受け入れるためのリソースポリシーをネームスペースに設定してから、S3 イベント統合を作成します。マネジメントコンソールで作成する場合はウィザードの「Fix it for me」でリソースポリシーを自動設定できますが、CLI の場合は put-resource-policy で明示的に設定します。
% aws redshift put-resource-policy \
  --resource-arn "arn:aws:redshift-serverless:ap-northeast-1:123456789012:namespace/564c110c-a06e-40c3-bdb7-36759985e4fd" \
  --policy '{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"Service": "redshift.amazonaws.com"},
      "Action": "redshift:AuthorizeInboundIntegration",
      "Resource": "arn:aws:redshift-serverless:ap-northeast-1:123456789012:namespace/564c110c-a06e-40c3-bdb7-36759985e4fd",
      "Condition": {
        "StringEquals": {"aws:SourceArn": "arn:aws:s3:::cm-blog-tryit-autocopy"}
      }
    },
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
      "Action": "redshift:CreateInboundIntegration",
      "Resource": "arn:aws:redshift-serverless:ap-northeast-1:123456789012:namespace/564c110c-a06e-40c3-bdb7-36759985e4fd"
    }
  ]
}'

{
    "ResourcePolicy": {
        "ResourceArn": "arn:aws:redshift-serverless:ap-northeast-1:123456789012:namespace/564c110c-a06e-40c3-bdb7-36759985e4fd",
        "Policy": "{\n  \"Version\" : \"2012-10-17\",\n  \"Statement\" : [ {\n    \"Effect\" : \"Allow\",\n    \"Principal\" : {\n      \"Service\" : \"redshift.amazonaws.com\"\n    },\n    \"Action\" : \"redshift:AuthorizeInboundIntegration\",\n    \"Resource\" : \"arn:aws:redshift-serverless:ap-northeast-1:123456789012:namespace/564c110c-a06e-40c3-bdb7-36759985e4fd\",\n    \"Condition\" : {\n      \"StringEquals\" : {\n        \"aws:SourceArn\" : \"arn:aws:s3:::cm-blog-tryit-autocopy\"\n      }\n    }\n  }, {\n    \"Effect\" : \"Allow\",\n    \"Principal\" : {\n      \"AWS\" : \"arn:aws:iam::123456789012:root\"\n    },\n    \"Action\" : \"redshift:CreateInboundIntegration\",\n    \"Resource\" : \"arn:aws:redshift-serverless:ap-northeast-1:123456789012:namespace/564c110c-a06e-40c3-bdb7-36759985e4fd\"\n  } ]\n}"
    }
}

% aws redshift create-integration \
  --integration-name cm-blog-tryit-s3int \
  --source-arn "arn:aws:s3:::cm-blog-tryit-autocopy" \
  --target-arn "arn:aws:redshift-serverless:ap-northeast-1:123456789012:namespace/564c110c-a06e-40c3-bdb7-36759985e4fd"
{
    "IntegrationArn": "arn:aws:redshift:ap-northeast-1:123456789012:integration:2b946f12-6648-47c0-b8dc-392b763063da",
    "IntegrationName": "cm-blog-tryit-s3int",
    "SourceArn": "arn:aws:s3:::cm-blog-tryit-autocopy",
    "TargetArn": "arn:aws:redshift-serverless:ap-northeast-1:123456789012:namespace/564c110c-a06e-40c3-bdb7-36759985e4fd",
    "Status": "creating",
    "Errors": [],
    "CreateTime": "2026-07-19T06:25:29.590000+00:00",
    "Tags": []
}
統合は 30 秒ほどで Active になりました。
 テスト用テーブルとCOPY JOB の作成テスト用テーブルを作成します。
テスト用テーブルに対して、AUTO ON を指定した COPY JOB を定義します。
 初回ロードの確認検証用CSVの作成#!/usr/bin/env bash
set -euo pipefail

cat > orders_batch1.csv <<'EOF'
1,2026-07-16,Monitor,2,45000
2,2026-07-16,Keyboard,5,12500
3,2026-07-16,Mouse,3,6000
4,2026-07-16,USB Hub,1,3500
5,2026-07-16,Webcam,2,16000
EOF

cat > orders_batch2.csv <<'EOF'
6,2026-07-16,Headset,4,22000
7,2026-07-16,Docking Station,1,18000
8,2026-07-16,HDMI Cable,6,7200
EOF

cat > orders_batch3.csv <<'EOF'
9,2026-07-16,Laptop Stand,2,9800
10,2026-07-16,Desk Mat,3,5400
EOF

echo "created: orders_batch1.csv (5 rows), orders_batch2.csv (3 rows), orders_batch3.csv (2 rows)"

1 つ目のテストファイル（orders_batch1.csv: 5 行）を S3 に置きます。
% aws s3 cp orders_batch1.csv s3://cm-blog-tryit-autocopy/staging/
upload: ./orders_batch1.csv to s3://cm-blog-tryit-autocopy/staging/orders_batch1.csv
ファイル投入から 30 秒ほどで自動的にロードされました。
 スナップショットの作成と、スナップショット後のデータ追加この時点（5 行）で手動スナップショットを作成します。
% aws redshift-serverless create-snapshot \
  --namespace-name cm-blog-tryit-ns \
  --snapshot-name cm-blog-tryit-snap
{
    "snapshot": {
        "actualIncrementalBackupSizeInMegaBytes": 0.0,
        "adminUsername": "admin",
        "backupProgressInMegaBytes": 0.0,
        "currentBackupRateInMegaBytesPerSecond": 0.0,
        "elapsedTimeInSeconds": 0,
        "estimatedSecondsToCompletion": -1,
        "kmsKeyId": "AWS_OWNED_KMS_KEY",
        "namespaceArn": "arn:aws:redshift-serverless:ap-northeast-1:123456789012:namespace/564c110c-a06e-40c3-bdb7-36759985e4fd",
        "namespaceName": "cm-blog-tryit-ns",
        "ownerAccount": "123456789012",
        "snapshotArn": "arn:aws:redshift-serverless:ap-northeast-1:123456789012:snapshot/f53a60d8-634a-4e67-82d8-0c425cba4063",
        "snapshotCreateTime": "2026-07-19T06:48:07.359000+00:00",
        "snapshotName": "cm-blog-tryit-snap",
        "snapshotRemainingDays": 0,
        "snapshotRetentionPeriod": -1,
        "snapshotRetentionStartTime": "2026-07-19T06:48:07.359000+00:00",
        "status": "CREATING",
        "totalBackupSizeInMegaBytes": 0.0
    }
}
スナップショットが AVAILABLE になった後、2 つ目のファイル（orders_batch2.csv: 3 行）を S3 に置きます。
% aws s3 cp orders_batch2.csv s3://cm-blog-tryit-autocopy/staging/
upload: ./orders_batch2.csv to s3://cm-blog-tryit-autocopy/staging/orders_batch2.csv
稼働中の統合によって自動ロードされ、テーブルは 8 行になります。つまり「スナップショットには 5 行、S3 には 8 行分のファイル」という状態を意図的に作っています。
 同一ネームスペースへの復元同一ネームスペースに対してスナップショットから復元します。
% aws redshift-serverless restore-from-snapshot \
  --namespace-name cm-blog-tryit-ns \
  --workgroup-name cm-blog-tryit-wg \
  --snapshot-name cm-blog-tryit-snap
{
    "namespace": {
        "adminUsername": "admin",
        "creationDate": "2026-07-19T06:13:14.203000+00:00",
        "dbName": "dev",
        "defaultIamRoleArn": "arn:aws:iam::123456789012:role/service-role/AmazonRedshift-CommandsAccessRole-20260130T183403",
        "iamRoles": [
            "IamRole(applyStatus=in-sync, iamRoleArn=arn:aws:iam::123456789012:role/service-role/AmazonRedshift-CommandsAccessRole-20260130T183403)"
        ],
        "kmsKeyId": "AWS_OWNED_KMS_KEY",
        "lakehouseRegistrationStatus": "NOT_REGISTERED",
        "logExports": [],
        "namespaceArn": "arn:aws:redshift-serverless:ap-northeast-1:123456789012:namespace/564c110c-a06e-40c3-bdb7-36759985e4fd",
        "namespaceId": "564c110c-a06e-40c3-bdb7-36759985e4fd",
        "namespaceName": "cm-blog-tryit-ns",
        "status": "MODIFYING"
    },
    "ownerAccount": "123456789012",
    "snapshotName": "cm-blog-tryit-snap"
}
なお、restore-from-snapshot には統合維持を制御する --maintain-integration | --no-maintain-integration パラメータがあります（AWS CLI 2.36.2 ）。デフォルトは true（維持する）のため、パラメータを指定しない場合は統合が維持されます。
また、直前の auto-copy ロードの影響でネームスペースが MODIFYING 状態のときに実行したところ、以下のエラーが返されました。AVAILABLE を待ってから再実行しています。
An error occurred (ConflictException) when calling the RestoreFromSnapshot operation:
Redshift serverless is not in available state for this operation.
復元（第 1 フェーズ）は約 5 分半で完了し、ネームスペースとワークグループが AVAILABLE に戻りました。
 復元後の統合ステータス確認復元完了後の統合ステータスを確認します。
% aws redshift describe-integrations \
  --integration-arn "arn:aws:redshift:ap-northeast-1:123456789012:integration:2b946f12-6648-47c0-b8dc-392b763063da" \
  --query 'Integrations[0].{IntegrationName:IntegrationName,Status:Status,Errors:Errors}'
{
    "IntegrationName": "cm-blog-tryit-s3int",
    "Status": "active",
    "Errors": []
}
統合は FAILED になることなく active のまま維持されています。復元処理中（MODIFYING）に同じコマンドを実行した際も active のままでした。COPY JOB も確認します。
COPY JOB もそのまま残っており、手動での再作成は不要でした。
 スナップショット後に追加したファイルの自動再ロードを確認復元によってテーブルはスナップショット時点の 5 行に戻るはずですが、復元完了直後に確認するとすでに 8 行でした。ロード履歴を確認します。
3 行目に注目してください。復元処理の実行中（10:26 頃開始〜10:32 完了）である 10:29 に、スナップショット取得後に追加した batch2 の 3 行が同じ COPY JOB によって自動的に再ロードされています。公式ドキュメントに記載されているとおり、復元後はスナップショット取得時点で未ロードのファイルが自動的に取り込まれる（キャッチアップされる）ことが確認できました。復元によるデータ取り込みのギャップが自動で埋められるということです。
 復元後の新規ファイル自動ロード確認最後に、復元後に 3 つ目のファイル（batch3: 2 行）を S3 に置きます。
復元後も統合と COPY JOB は何もせずにそのまま動き続けており、新しいファイルが自動ロードされました。
 考察検証を通じて確認できたこと、注意点を整理します。
同一ネームスペースへのスナップショット復元では、S3 イベント統合と COPY JOB が自動的に維持され、復元中も統合ステータスは active のまま変化しませんでした
スナップショット取得後に S3 へ追加されたファイルは、復元処理中に自動的に再ロードされました。従来動作（統合が FAILED になり手動再作成）で課題だった、再構築中のデータ取り込みギャップが解消されています
復元完了後の新規ファイルも従来どおり自動ロードされ、運用上の追加作業は一切ありませんでした
利用にあたっての注意点は以下のとおりです。
本機能の対象は Amazon Redshift Serverless の同一ネームスペースへの復元のみです。別ネームスペースへの復元やプロビジョンドクラスターのスナップショット復元では統合は維持されません
Patch 202 以降でデフォルト有効です。統合を維持したくない場合は、コンソールの復元画面で「Maintain Integrations」のチェックを外すか、CLI で --no-maintain-integration を指定してオプトアウトできます（オプトアウト時は従来どおり統合が FAILED になります）。このパラメータは比較的新しく追加されたものなので（AWS CLI 2.36.2 で実装済みを確認、2.35.21 では未実装）、オプトアウトを CLI で行う場合は CLI のバージョンを確認してください
スナップショット取得後にアップロードされ、復元完了前に削除されたファイルは取り込まれません
スナップショット取得後に作成した統合は、復元後に NEEDS_ATTENTION 状態になります。より新しいスナップショットから復元し直すか、統合を削除して対処します
スナップショット取得後に削除した統合は復元されず、対応する COPY JOB は PENDING になります
エッジケースの詳細は公式ドキュメントの「Considerations when restoring an S3 event integration target」にまとまっています。
 最後にAmazon Redshift Serverless のスナップショット復元で、zero-ETL 統合と S3 イベント統合が自動保持されるようになりました。実際に試したところ、統合と COPY JOB の維持だけでなく、スナップショット取得後に S3 へ追加されたファイルの自動再ロードまで行われており、災害復旧やリストア検証の運用負荷を確実に下げてくれるアップデートだと感じました。
zero-ETL 統合や Auto-copy を利用している環境でスナップショット復元を運用に組み込んでいる方は、復元手順書から「統合の再作成」の工程をシンプルに見直せるはずです。この記事がどなたかのお役に立てば幸いです。