Amazon Redshift Serverless、snapshot restore で zero-ETL と S3 event integrations を保持

Amazon Redshift の behavior changes ページに、Patch 202 以降の Serverless snapshot restore に関する変更が掲載されました。同じ serverless namespace へ復元する場合、zero-ETL と S3 event 連携 が自動的に維持されます。

要点

• Amazon Redshift Serverless で、snapshot または recovery point を同じ namespace に復元する際の挙動が変わる
• zero-ETL と S3 event 連携 が自動的に維持される
• 従来は復元後に 連携 が failed になり、再作成が必要になる場合があった
• 別 namespace への復元や provisioned clusters の snapshot restore には適用されない
• opt out する場合は console または AWS CLI の --no-maintain-integration を使う

今回の変更で何が変わるのか

今回の behavior change は、Redshift Serverless の復旧手順に直接関係します。公式説明では、Patch 202 以降、snapshot または recovery point を同じ serverless namespace に復元すると、namespace と snapshot/recovery point に関連する zero-ETL 連携 と S3 event 連携 が自動的に維持されるとされています。

従来は、復元後に関連 連携 が FAILED 状態になり、復元後に手動で削除・再作成する必要があるケースがありました。これは復旧手順の中で見落としやすく、データ連携が止まったままになるリスクがあります。今回の変更により、同じ namespace への復元では 連携 が維持され、復元完了後に再開しやすくなります。

ただし、適用条件は限定されています。対象は Amazon Redshift Serverless で、同じ serverless namespace へ復元する場合です。別 namespace への復元では 連携 は維持されず、provisioned clusters の snapshot restores でも zero-ETL と S3 event 連携 は維持されません。DR 手順や検証環境復元では、この境界を明確にしておく必要があります。

対象になりそうなユーザー・チーム

• Redshift Serverless で zero-ETL 連携 を使っているデータ基盤チーム
• S3 event 連携 を使ってイベント駆動の取り込みや処理を行っているチーム
• snapshot restore / recovery point restore を運用手順や障害訓練に含めている管理者

実務でまず確認したいこと

1. 自社の Redshift Serverless namespace に zero-ETL または S3 event 連携 があるか確認する
2. 復元手順が同じ namespace への restore なのか、別 namespace への restore なのかを明記する
3. opt out が必要なケースでは console の Maintain 連携 または CLI の --no-maintain-integration を手順化する
4. 復元後の 連携 状態、データ到着、下流ジョブの再開を監視項目に入れる

どう読むべきか

この更新は、Redshift Serverless の復旧時に「復元できたが連携が止まる」リスクを下げる変更です。該当環境では、DR 手順と復旧テストの期待値を Patch 202 以降の挙動に合わせて更新したいところです。