ネイティブレプリケーション
対応する状態には、サービス固有のレプリケーション経路を使用します。例:新しい ECR イメージ、S3 オブジェクトレプリケーション、承認済みデータベースレプリカ。
パターンを見る →復旧戦略
イメージ、証明書、ネットワーク制御、シークレット、データ、インフラがどのように連携するかを確認できます。これらの図は Dockfield の復旧設計を示しており、各顧客への実装は個別に範囲を定めてテストします。
サービスと復旧目標から選択
ワークロードでは複数の戦略を組み合わせる場合があります。コンテナサービスには、イメージ、ネットワーク、ID、シークレット、データをまとめて用意する必要があります。構成の復旧とアプリケーションデータの復旧では、証跡と所要時間が異なります。
対応する状態には、サービス固有のレプリケーション経路を使用します。例:新しい ECR イメージ、S3 オブジェクトレプリケーション、承認済みデータベースレプリカ。
パターンを見る →変更イベントを記録し、現在の構成を確認して、対応するリソースを DR 側で照合します。SG と NACL には専用の照合処理が必要です。
パターンを見る →復旧ブループリントから、依存関係の順に対応インフラを再構築します。例: VPC、ロードバランサー、ECS、EKS。
パターンを見る →承認済みの復元ポイントから、サービス標準のバックアップ経路で状態を復旧します。例: RDS、Aurora、対応する AWS Backup リソース。
パターンを見る →有効な宛先リソースを作成し、新しい識別子を対応付けます。例: 対象アカウントとリージョンの ACM 証明書。
パターンを見る →保護環境全体のルーティング判断を調整します。ARC のルーティング制御は Route 53 ヘルスチェックに作用します。
パターンを見る →委任管理とサービス固有のリージョン設定を用いて、適用される制御を一元管理します。
パターンを見る →イメージ · 初回補充 + 継続的なネイティブレプリケーション
既存イメージと今後のプッシュでは経路が異なります。復旧したワークロードを ECS または EKS が起動する前に、宛先イメージを利用可能にする必要があります。
ネイティブレプリケーションルールと宛先レジストリの権限を設定します。既存コンテンツには別のコピー経路が必要です。宛先のダイジェストと承認済みリリースを確認してください。
暗号化、タグの不変性、権限、ライフサイクルルールには宛先側の設定または適切な作成テンプレートが必要です。ネイティブなイメージレプリケーションはソースの削除を伝播しません。
AWS リファレンス: ECR レプリケーション
証明書 · 再発行 / 再インポート
証明書の要件として、名前、種類、検証方法、ワークロードへの関連付けを記録します。宛先アカウントとリージョンで証明書を申請またはインポートし、ARN を復旧したリスナーに対応付けます。
ソースの ACM ARN は宛先証明書ではありません。復旧演習の前に発行と DNS 検証を準備し、宛先リスナーとの関連付けを確認してください。
検出に秘密鍵は不要です。インポートには承認済みの安全な鍵経路を使用します。CloudFront 証明書は、アプリケーションが別の場所にあっても us-east-1 を使用します。
AWS リファレンス: ACM のリージョンと用途 · 証明書をインポート
ネットワーク制御 · 差分を調整し、リスクのある変更を保留
これらのサービスには、アカウント間の SG/NACL ネイティブレプリケーションがありません。Dockfield の調整処理は変更イベントを合図として使用し、現在の構成を読み取り、参照先を対応付けて、承認済みの宛先ルールを適用します。定期調整で見逃したイベントや遅延イベントを補います。
| 制御項目 | セキュリティグループ | ネットワーク ACL |
|---|---|---|
| 配置 | リソース / ネットワークインターフェイス | サブネットの関連付け |
| トラフィック動作 | ステートフル; 許可した応答を追跡 | ステートレス; 必要な戻り経路を許可 |
| ルールモデル | 許可ルール; 参照される SG ID を対応付け | 順序付きの許可 / 拒否ルール; ルール番号を維持 |
| 宛先への対応付け | 対象 VPC、SG 参照、承認済み CIDR | 対象サブネットの関連付け、CIDR、インバウンド / アウトバウンドルール |
サポートされる CloudTrail 書き込みイベントと有効なトレイルを使用します。信頼できる構成を再読み込みし、再試行を冪等に処理し、調整の証跡を記録します。
ポリシー確認では、リソース全体の削除だけでなく、アクセスや関連付けの変更も確認します。変更の保留にはレビュー担当者の確認が必要です。アクセスを維持するのは意識的な一時判断です。
AWS リファレンス: CloudTrail 経由の EventBridge · ネットワーク ACL の動作
機密状態 · 検出とは別管理
検出では GetSecretValue を呼び出さずにシークレットのメタデータと依存関係を一覧化します。シークレットの運用保護は別途許可された経路で行い、暗号化値、KMS 権限、ローテーション、宛先エンドポイントを扱います。
ネイティブなリージョンレプリカはシークレットの更新とローテーションを伝播します。宛先リージョンに適した KMS キーを使い、接続設定が復旧対象のサービスを指していることを確認します。
ネイティブなリージョン間レプリケーションはアカウント間レプリケーションではありません。管理された同期経路か、許可された共有アクセスを選びます。共有アクセスだけでは分離コピーは作成されません。アカウント間アクセスにはリソース、ID、カスタマーマネージド KMS の権限が必要です。
AWS リファレンス: リージョンレプリカ · アカウント間アクセス
ステートフルデータの復旧 · レプリカ / バックアップ / PITR
インフラのブループリントとは別にデータ経路を選びます。RDS と Aurora はサービスに適した復元またはレプリケーション方式を使います。DynamoDB、EBS、EFS、FSx にはそれぞれ対応する保護経路が必要です。復旧ポイントの選択、宛先アクセス、保持期間を明示的にテストします。
インフラの取得間隔は、アプリケーションデータの RPO ではありません。復元時間、レプリケーション遅延、保持されている復元ポイント、テスト済みワークロードが実際の復旧証跡を決定します。
既存の S3 オブジェクトには、新しいオブジェクトのレプリケーションとは別に Batch Replication が必要な場合があります。EFS、FSx、ボリュームスナップショットでは、選択したサービス、アカウント、リージョンでサポートされる方式を使います。
AWS リファレンス: RDS のポイントインタイム復元 · S3 レプリケーション範囲
宣言的な復旧 · 依存関係の順序
ブループリントには対応する構成と宛先マッピングが記述されます。ネイティブな状態保護でイメージとデータを用意し、インフラ自動化で依存関係に沿って周辺サービスを再構築します。
ソースアカウント ID、リージョン、証明書 ARN、KMS キー、イメージの場所、エンドポイント参照には宛先マッピングが必要です。
Kubernetes では、一時的な Pod ID ではなく、ワークロード仕様と永続データを復旧します。制御プレーンが正常なだけでは不十分です。実際のアプリケーション確認も必要です。
Dockfield の設計パターン: 対応サービス範囲と依存関係のマッピングは評価時に定義します。
トラフィック · 準備 → 承認 → ルーティング操作
ルーティング制御は Route 53 ヘルスチェックと DNS トラフィックに影響します。Dockfield の人による承認と検証のゲートはアプリケーション制御であり、設定済みの ARC 安全ルールがそれを補完します。ルーティング操作の対象になる前に、復旧エンジンがワークロードを構築します。
UI が承認状態でも、ルーティング制御が変更された証拠にはなりません。制御操作を記録し、復旧したサービスと DNS の動作を確認してください。
適切な安全ルールを構成し、承認済みの切り替えとロールバックをリハーサルして、DNS キャッシュとクライアントの動作を考慮します。
AWS リファレンス: ARC ルーティング制御 · ARC 安全ルール
組織制御 · 一元構成
Control Tower、AWS Config、Security Hub、GuardDuty では組織およびリージョン構成のモデルがそれぞれ異なります。適切な一元管理パターンを使用し、各 DR アカウントとリージョンで対象範囲、集約、権限を確認してください。IAM 信頼と KMS アクセスは明示的な依存関係です。
中央管理者がいても、すべての宛先が自動的に対象になるわけではありません。必要な有効リージョン、メンバーアカウント、証跡ソースを記録してください。
各リソースについて、戦略、宛先マッピング、担当者、承認ルール、保護の証跡、最後に成功した復旧テストを記録します。