Redshift Serverless のスナップショットを別アカウントに共有して冗長バックアップを作る

弊社では、保険者データベースの運用に Amazon Redshift Serverless を使用しています。貴重なデータを扱う上で、バックアップは必須であり、大規模災害やアカウント侵害といったリスクへの備えも欠かせません。

Redshift Serverlessには、データを定期的に保護する自動バックアップ機能が備わっています。また、Redshift Managed Storage (RMS)は、複数のアベイラビリティーゾーンにまたがってデータが分散されるため、99.99%の高い可用性を誇り、自然災害のリスクもある程度軽減されます。さらに、クロスリージョンへのバックアップも利用でき、遠隔地にデータを保存することで災害リスクを一層低減できます。（ただし、2025年9月現在、国内では東京リージョンのみが対応しており、退避先は海外リージョンに限定されます。）

しかし、アカウントが侵害された場合、バックアップ自体が削除されてしまう可能性があります。AWS Backupを利用したバックアップボールトでバックアップを保護することも可能ですが、アカウント自体が削除されるとバックアップボールトも同様に消失するため、元アカウントに依存したバックアップだけでは十分な対策とは言えません。そこで本記事では、アカウント侵害に備え、バックアップを別アカウントに複製し、元アカウントから独立させて保護する仕組みをご紹介します。

処理の流れと構成イメージ

アカウントAでスナップショットを取得
取得したスナップショットをアカウントBに共有
アカウントBでスナップショットからデータベースを復元
アカウントBで再度スナップショットを取得し、冗長バックアップとする

ポイントは再スナップショットは元アカウントから操作できないため、アカウント侵害時でも保全できることです。

主な実装フロー

実装の核となるステップは以下の4つです。アカウントA（本番環境）からアカウントB（バックアップ環境）へ、スナップショットを安全に連携させます。

1. スナップショット作成

まず、Lambdaなどから create_snapshot APIを呼び出し、バックアップ対象のデータベースのスナップショットを取得します。このスナップショットはアカウントBへ連携するための一時的なものなので、保持期間 (retentionPeriod) を短く設定するのがポイントです。これにより、不要なコストの発生を抑えます。

response = redshift_client.create_snapshot(
    namespaceName=namespaceName,
    retentionPeriod=[アカウントAで保持する期間（一時的なバックアップ）],
    snapshotName=snapshotName
)

2. スナップショット共有

アカウントAから put_resource_policy を実行して、アカウントBに対して権限を付与します。これにより、アカウントBはアカウントAで作成したスナップショットを利用できるようになります。

response = redshift_client.put_resource_policy(
    policy="""
    {
        "Version": "2012-10-17",
        "Statement": [{
            "Sid": "AllowUserRestoreFromSnapshot",
            "Principal": {"AWS": ["[アカウントBのアカウントID]"]},
            "Action": ["redshift-serverless:RestoreFromSnapshot"],
            "Effect": "Allow"
        }]
    }
    """,
    resourceArn=snapshot_arn
)

3. 別アカウントでリストア

共有されたスナップショットの ARN を指定して、アカウントBで restore_from_snapshot を実行し、リストアを行います。

restore_response = client.restore_from_snapshot(
    namespaceName=namespace_name,
    snapshotArn=snapshot_arn,
    workgroupName=workgroup_name
)

4. 再スナップショット作成

リストア後、別アカウントで再スナップショットを取得します。これにより、最終的なバックアップはアカウントAから操作できない状態となります。また、retentionPeriod に設定する保持期間や取得タイミングを適切に調整することで、任意の世代管理が可能です。

manual_snapshot_response = client.create_snapshot(
    namespaceName=namespace_name,
    snapshotName=f"{snapshot_name}-[識別子]",
    retentionPeriod=[アカウントBで保持する期間（最終的なバックアップ）]
)

注意ポイント

フロー制御の必要性

API 呼び出し後すぐに次の処理を実行すると失敗することがあります。Step funtionsなどでフロー制御を行い、状態確認を挟むことが必要です。

自動バックアップとの競合

フロー制御をした上でもRedshift Serverless の内部処理にはブラックボックスな部分があり、スナップショット作成時に自動バックアップと競合すると、エラーが発生することがあります。そのため、ポーリングで余裕をもった時間を設けると安定して実行できます。

KMS 暗号化キーの共有

アカウントAの Redshift が KMS で暗号化されている場合、アカウントB で復元する際にも KMS キーが必要となります。

本構成のメリットとデメリット

メリット

シンプル実装、高速復旧

バックアップをファイルのエクスポートやインポートして退避する場合と比較すると、WORKGROUPを丸ごと取得・復元しますので、データのエクスポート&インポートと比較すると、Step Functions と Lambda を組み合わせることで、フローを比較的容易に仕組みを構築することができます。また、スナップショットから直接データベースを復元できるため、システムの復旧を迅速に実施できます。（データ量にもよりますが、10TB程度のファイルインポート&エクスポートだと数時間～数十時間かかるところ、1時間以内での復旧が可能です。）

アカウント侵害時の保全性

取得したバックアップは元のアカウントから操作することができないため、万が一アカウントが侵害された場合でも高い保全性が確保できます。

デメリット

S3 での保管に比べてコスト高

Redshift のスナップショットは Redshift Managed Storage（RMS）として S3 上に保管されます。課金は S3 標準料金に基づきますが、低頻度アクセス（S3 IA）や Glacier などのより安価な S3 ストレージに比べると、保持コストは割高になります。

保存先	単価（GB/月）	月額コスト（概算）	備考
Redshiftスナップショット	約 $0.024 ／GB-月	約 $24／月（＝1,024 GB × $0.024）	Redshift管理下のスナップショット※管理オーバーヘッドを考慮
S3 Standard	約 $0.023 ／GB-月	約 $23.5／月（＝1,024 GB × $0.023）	一般的なオブジェクト保管料金
S3 低頻度アクセス（IA）	約 $0.0125 ／GB-月	約 $12.8／月（＝1,024 GB × $0.0125）	アクセス頻度が低いデータ向け
S3 Glacier	約 $0.004 ／GB-月	約 $4.1／月（＝1,024 GB × $0.004）	長期保存向きの非常に低コストなアーカイブ層