復旧戦略

適切な復旧経路。
AWS の各コンポーネントに。

イメージ、証明書、ネットワーク制御、シークレット、データ、インフラがどのように連携するかを確認できます。これらの図は Dockfield の復旧設計を示しており、各顧客への実装は個別に範囲を定めてテストします。

サービスと復旧目標から選択

7つのファミリー、1つの復旧ブループリント。

ワークロードでは複数の戦略を組み合わせる場合があります。コンテナサービスには、イメージ、ネットワーク、ID、シークレット、データをまとめて用意する必要があります。構成の復旧とアプリケーションデータの復旧では、証跡と所要時間が異なります。

01

ネイティブレプリケーション

対応する状態には、サービス固有のレプリケーション経路を使用します。例:新しい ECR イメージ、S3 オブジェクトレプリケーション、承認済みデータベースレプリカ。

パターンを見る →
02

イベント駆動ミラーリング

変更イベントを記録し、現在の構成を確認して、対応するリソースを DR 側で照合します。SG と NACL には専用の照合処理が必要です。

パターンを見る →
03

宣言的な再構築

復旧ブループリントから、依存関係の順に対応インフラを再構築します。例: VPC、ロードバランサー、ECS、EKS。

パターンを見る →
04

バックアップとポイントインタイム復元

承認済みの復元ポイントから、サービス標準のバックアップ経路で状態を復旧します。例: RDS、Aurora、対応する AWS Backup リソース。

パターンを見る →
05

再発行または再作成

有効な宛先リソースを作成し、新しい識別子を対応付けます。例: 対象アカウントとリージョンの ACM 証明書。

パターンを見る →
06

共有リカバリー制御プレーン

保護環境全体のルーティング判断を調整します。ARC のルーティング制御は Route 53 ヘルスチェックに作用します。

パターンを見る →
07

組織ガバナンス

委任管理とサービス固有のリージョン設定を用いて、適用される制御を一元管理します。

パターンを見る →

イメージ · 初回補充 + 継続的なネイティブレプリケーション

ECR: イメージを保護してからサービスを再構築します。

既存イメージと今後のプッシュでは経路が異なります。復旧したワークロードを ECS または EKS が起動する前に、宛先イメージを利用可能にする必要があります。

ECR の初回補充とレプリケーション既存イメージは承認済みの手順で一度だけ補充します。新規プッシュには設定済みのネイティブレプリケーションを使用します。どちらの経路でも宛先レジストリを補充し、復旧前にイメージダイジェストを検証します。既存のソースイメージレプリケーション開始前に作成1 回限りの初回コピー承認済みコピー + ダイジェスト検証宛先 ECR対応付け済みリポジトリ + ダイジェストECS / EKS の起動準備完了新しいイメージのプッシュルール有効化後ネイティブレプリケーション宛先リージョン / アカウント
既存イメージは承認済みの手順で一度だけ補充します。新規プッシュには設定済みのネイティブレプリケーションを使用します。どちらの経路でも宛先レジストリを補充し、復旧前にイメージダイジェストを検証します。
宛先を準備

ネイティブレプリケーションルールと宛先レジストリの権限を設定します。既存コンテンツには別のコピー経路が必要です。宛先のダイジェストと承認済みリリースを確認してください。

リポジトリ制御の確認が必要です

暗号化、タグの不変性、権限、ライフサイクルルールには宛先側の設定または適切な作成テンプレートが必要です。ネイティブなイメージレプリケーションはソースの削除を伝播しません。

AWS リファレンス: ECR レプリケーション

証明書 · 再発行 / 再インポート

ACM: 宛先で新しい証明書を発行し、ARN を対応付けます。

証明書の要件として、名前、種類、検証方法、ワークロードへの関連付けを記録します。宛先アカウントとリージョンで証明書を申請またはインポートし、ARN を復旧したリスナーに対応付けます。

宛先証明書の発行ソース証明書の要件から、申請して検証する経路と承認済みインポートの経路に分かれます。いずれも復旧したリスナーに関連付ける宛先証明書 ARN を生成します。証明書の要件名前 + 検証 + 関連付け宛先で申請ドメイン検証を完了承認済みインポート証明書 + 保護されたキー宛先証明書新しい対象 ARN対象リスナーに関連付け
ソース証明書の要件から、申請して検証する経路と承認済みインポートの経路に分かれます。いずれも復旧したリスナーに関連付ける宛先証明書 ARN を生成します。
リージョンごとに識別子が異なります

ソースの ACM ARN は宛先証明書ではありません。復旧演習の前に発行と DNS 検証を準備し、宛先リスナーとの関連付けを確認してください。

秘密情報は保護されたままです

検出に秘密鍵は不要です。インポートには承認済みの安全な鍵経路を使用します。CloudFront 証明書は、アプリケーションが別の場所にあっても us-east-1 を使用します。

AWS リファレンス: ACM のリージョンと用途 · 証明書をインポート

ネットワーク制御 · 差分を調整し、リスクのある変更を保留

セキュリティグループと NACL: 意図を安全に反映します。

これらのサービスには、アカウント間の SG/NACL ネイティブレプリケーションがありません。Dockfield の調整処理は変更イベントを合図として使用し、現在の構成を読み取り、参照先を対応付けて、承認済みの宛先ルールを適用します。定期調整で見逃したイベントや遅延イベントを補います。

ネットワーク変更の調整と隔離CloudTrail と EventBridge が調整を開始します。承認済みで対応付けられた変更は DR に反映されます。削除やリスクのある変更は隔離され、明示的に判断されるまで宛先リソースが保持されます。承認済み保留本番環境の変更SG / NACL API の操作CloudTrail + EventBridge現在の状態を読み取る確認して対応付けポリシー + ID + CIDR の対応付け承認済みの調整同等の宛先ルール収束を確認削除 / リスクのある変更隔離して DR 側を保持レビュー担当者の明示的な判断定期調整実際の状態を比較承認済みのずれを修正
CloudTrail と EventBridge が調整を開始します。承認済みで対応付けられた変更は DR に反映されます。削除やリスクのある変更は隔離され、明示的に判断されるまで宛先リソースが保持されます。
制御項目セキュリティグループネットワーク ACL
配置リソース / ネットワークインターフェイスサブネットの関連付け
トラフィック動作ステートフル; 許可した応答を追跡ステートレス; 必要な戻り経路を許可
ルールモデル許可ルール; 参照される SG ID を対応付け順序付きの許可 / 拒否ルール; ルール番号を維持
宛先への対応付け対象 VPC、SG 参照、承認済み CIDR対象サブネットの関連付け、CIDR、インバウンド / アウトバウンドルール
イベントは合図であり、状態そのものではありません

サポートされる CloudTrail 書き込みイベントと有効なトレイルを使用します。信頼できる構成を再読み込みし、再試行を冪等に処理し、調整の証跡を記録します。

権限の取り消しもリスクになる場合があります

ポリシー確認では、リソース全体の削除だけでなく、アクセスや関連付けの変更も確認します。変更の保留にはレビュー担当者の確認が必要です。アクセスを維持するのは意識的な一時判断です。

AWS リファレンス: CloudTrail 経由の EventBridge · ネットワーク ACL の動作

機密状態 · 検出とは別管理

Secrets Manager: 値をブループリントに含めないでください。

検出では GetSecretValue を呼び出さずにシークレットのメタデータと依存関係を一覧化します。シークレットの運用保護は別途許可された経路で行い、暗号化値、KMS 権限、ローテーション、宛先エンドポイントを扱います。

メタデータの検出とシークレット保護メタデータのみの検出結果をブループリントの対応付けに使用します。シークレット値は別の運用経路をたどります。同一アカウント内のネイティブなリージョン間レプリケーション、または許可されたアカウント間設計です。値を表示せずに宛先構成を検証します。メタデータの検出名前 + 依存関係のみ復旧ブループリントSecret / KMS 参照マップ宛先の準備状態権限 + 宛先エンドポイントローテーションとバージョンの確認シークレット保護ロール個別の認可承認済みの値の経路ネイティブレプリカまたはカスタム同期
メタデータのみの検出結果をブループリントの対応付けに使用します。シークレット値は別の運用経路をたどります。同一アカウント内のネイティブなリージョン間レプリケーション、または許可されたアカウント間設計です。値を表示せずに宛先構成を検証します。
同一アカウント、複数リージョン

ネイティブなリージョンレプリカはシークレットの更新とローテーションを伝播します。宛先リージョンに適した KMS キーを使い、接続設定が復旧対象のサービスを指していることを確認します。

別アカウントには別の設計が必要です

ネイティブなリージョン間レプリケーションはアカウント間レプリケーションではありません。管理された同期経路か、許可された共有アクセスを選びます。共有アクセスだけでは分離コピーは作成されません。アカウント間アクセスにはリソース、ID、カスタマーマネージド KMS の権限が必要です。

AWS リファレンス: リージョンレプリカ · アカウント間アクセス

ステートフルデータの復旧 · レプリカ / バックアップ / PITR

信頼できる時点までデータを復旧します。

インフラのブループリントとは別にデータ経路を選びます。RDS と Aurora はサービスに適した復元またはレプリケーション方式を使います。DynamoDB、EBS、EFS、FSx にはそれぞれ対応する保護経路が必要です。復旧ポイントの選択、宛先アクセス、保持期間を明示的にテストします。

インフラとデータの復旧が合流承認済みブループリントがインフラを再構築し、承認済みのレプリカまたは復元ポイントがデータを提供します。トラフィックを承認する前に、両方の経路がアプリケーションとデータの検証で合流します。承認済みブループリント構成 + 依存関係再構築されたインフラネットワーク + コンピューティング + ID保護されたアプリケーションデータレプリカ / バックアップ / PITR信頼できるデータ時点復元 + 宛先アクセスアプリケーション検証動作 + データ整合性承認可能
承認済みブループリントがインフラを再構築し、承認済みのレプリカまたは復元ポイントがデータを提供します。トラフィックを承認する前に、両方の経路がアプリケーションとデータの検証で合流します。
RTO と RPO を測定

インフラの取得間隔は、アプリケーションデータの RPO ではありません。復元時間、レプリケーション遅延、保持されている復元ポイント、テスト済みワークロードが実際の復旧証跡を決定します。

その他のステートフルサービス

既存の S3 オブジェクトには、新しいオブジェクトのレプリケーションとは別に Batch Replication が必要な場合があります。EFS、FSx、ボリュームスナップショットでは、選択したサービス、アカウント、リージョンでサポートされる方式を使います。

AWS リファレンス: RDS のポイントインタイム復元 · S3 レプリケーション範囲

宣言的な復旧 · 依存関係の順序

連携したサービスを再構築します。

ブループリントには対応する構成と宛先マッピングが記述されます。ネイティブな状態保護でイメージとデータを用意し、インフラ自動化で依存関係に沿って周辺サービスを再構築します。

依存関係に沿った再構築宛先のネットワークと ID の基盤を先に整え、その後にコンピューティングとエントリポイントを構築します。復旧ワークロードでは承認済みイメージ、シークレット、データを使います。昇格前に検証を完了します。依存関係の準備完了ネットワーク + IDVPC、サブネット、ロール、キーコンピューティング + エントリポイントECS / EKS、ALB、ログアプリケーション検証正常性 + 動作 + データ保護された依存関係イメージ + シークレット + データ対応付け済みの宛先 ID
宛先のネットワークと ID の基盤を先に整え、その後にコンピューティングとエントリポイントを構築します。復旧ワークロードでは承認済みイメージ、シークレット、データを使います。昇格前に検証を完了します。
宛先 ID を解決

ソースアカウント ID、リージョン、証明書 ARN、KMS キー、イメージの場所、エンドポイント参照には宛先マッピングが必要です。

プラットフォームの望ましい状態が重要です

Kubernetes では、一時的な Pod ID ではなく、ワークロード仕様と永続データを復旧します。制御プレーンが正常なだけでは不十分です。実際のアプリケーション確認も必要です。

Dockfield の設計パターン: 対応サービス範囲と依存関係のマッピングは評価時に定義します。

トラフィック · 準備 → 承認 → ルーティング操作

復旧準備が整った後に ARC がトラフィックを制御します。

ルーティング制御は Route 53 ヘルスチェックと DNS トラフィックに影響します。Dockfield の人による承認と検証のゲートはアプリケーション制御であり、設定済みの ARC 安全ルールがそれを補完します。ルーティング操作の対象になる前に、復旧エンジンがワークロードを構築します。

承認済みルーティングと復旧準備検証と人による承認でオーケストレーションのゲートが開きます。その後、設定済み ARC ルーティング制御と安全ルールが Route 53 のトラフィックを変更できます。制御を構成していない場合、UI には準備状況だけが表示されます。復旧 + 検証インフラとアプリケーション人による承認Dockfield の昇格ゲートARC ルーティング操作設定済み制御 + 安全性Route 53 トラフィックヘルスチェックに基づくレコード復旧したサービスを監視ライブ切り替えの前に構成が必要です録画デモの UI には実行可能状態が表示されますARC の警告にはルーティング制御が未構成と表示されています
検証と人による承認でオーケストレーションのゲートが開きます。その後、設定済み ARC ルーティング制御と安全ルールが Route 53 のトラフィックを変更できます。制御を構成していない場合、UI には準備状況だけが表示されます。
実行可能状態はライブフェイルオーバーではありません

UI が承認状態でも、ルーティング制御が変更された証拠にはなりません。制御操作を記録し、復旧したサービスと DNS の動作を確認してください。

安全性とロールバック

適切な安全ルールを構成し、承認済みの切り替えとロールバックをリハーサルして、DNS キャッシュとクライアントの動作を考慮します。

AWS リファレンス: ARC ルーティング制御 · ARC 安全ルール

組織制御 · 一元構成

統制は一度。復旧境界ごとに確認。

Control Tower、AWS Config、Security Hub、GuardDuty では組織およびリージョン構成のモデルがそれぞれ異なります。適切な一元管理パターンを使用し、各 DR アカウントとリージョンで対象範囲、集約、権限を確認してください。IAM 信頼と KMS アクセスは明示的な依存関係です。

サービス固有の対象範囲

中央管理者がいても、すべての宛先が自動的に対象になるわけではありません。必要な有効リージョン、メンバーアカウント、証跡ソースを記録してください。

ブループリントは復旧契約です

各リソースについて、戦略、宛先マッピング、担当者、承認ルール、保護の証跡、最後に成功した復旧テストを記録します。

復旧ブループリントには何を記録しますか?
  • ソースサービスと依存関係
  • 対象アカウントとリージョン、対応付け済み ID とエンドポイント
  • 保護戦略、前提条件、最後の調整
  • 復旧ポイントの方針、測定した RTO / RPO、検証証跡
  • 破壊的変更の処理、承認担当者、ロールバック経路

初回無料相談会

AWS 環境に適した復旧経路は?

重要なワークロードを 1 つ選び、その依存関係と測定可能な復旧目標から始めます。