AWS Backup Cross-Region DR Aurora Global Route53 ARC 本番

1. この記事について — 復旧・運用編シリーズ Vol1 起ち上げ巻

本記事は復旧・運用編シリーズ第 1 巻（起ち上げ巻）として、Lambda 3 部作・EKS 3 部作・観測性 3 部作・セキュリティ 3 部作の計 12 巻 AWS 本番運用シリーズ完結後の延長線上に位置付けられる、Multi-Region 災害復旧 (DR) の本番実装記事です。リージョン障害という最大級の本番運用論点に対し、AWS Backup Cross-Region/Cross-Account・Aurora Global Database・Route53 Application Recovery Controller (ARC)・S3 Cross-Region Replication の 4 サービスを Terraform で end-to-end 統合実装する手順を提供します。

12 巻完結シリーズで構築した GuardDuty 検知層・IAM Identity Center 統制層・AWS Config 準拠層という 3 層セキュリティを、Multi-Region 構成へ拡張展開するシリーズ起ち上げ巻として、Vault Lock・Cross-Account Backup・Organizations 委任管理を Cross-Region コピーへ適用する実装パターンも本巻で確立します。観測性 3 部作の CloudWatch Logs Insights・X-Ray・Application Signals SLO は DR 訓練時の RTO/RPO 実測 + Burn Rate 監視で再活用します。

Aurora DR 完全ガイド (単一リージョン DR 演習 / slug: aurora-backup-restore-dr) §8-3 で「次回予告」として記載した Aurora Global Database による Multi-Region DR を、本 Vol1 §5 で完全回収します。Aurora DR 編の単一 Region 復元 Runbook と本 Vol1 の Cross-Region 構成を組み合わせると、AZ 障害 → Region 障害という障害規模スケールに応じた DR 戦略を体系的に実装できます。

1-1. 本記事のゴール

本記事を読み終えると、以下の状態を Terraform で構築・運用できるようになります。復旧・運用編シリーズ起ち上げ巻として、Multi-Region DR の本番運用基盤を IaC + Terraform で確立します。

• DR 戦略 4 タイプの意思決定マトリクス: Backup & Restore / Pilot Light / Warm Standby / Multi-Site の 4 戦略を RTO・RPO・月額コスト (USD)・運用複雑度の 4 軸で定量比較し、システムごとに最適戦略を選定できる意思決定フレームワークを §3 QG-1 マトリクスで提供します。
• AWS Backup Cross-Region/Cross-Account の Terraform 本番構築: aws_backup_plan・aws_backup_vault・aws_backup_vault_lock_configuration・aws_backup_selection リソースで Cross-Region コピー + Cross-Account コピー + Vault Lock (Compliance Mode) を Terraform 管理し、Organizations Backup Policy で組織全体に一括適用するガバナンス体制を IaC 化します。
• Aurora Global Database 本番運用 (Aurora DR 完全ガイドの発展実装): aws_rds_global_cluster + Secondary Region aws_rds_cluster で Aurora Global Database を構築し、計画的 Switchover (RPO=0 / <30s) と計画外 Failover (RPO=秒) の選定マトリクスを QG-3 で整理します。Writer 昇格後の Route53 自動切替を aws_route53_record failover routing で Terraform 実装します。
• Route53 ARC + S3 CRR 統合 DR の Terraform 実装: aws_route53recoverycontrol_* (Routing Control) + ARC Zonal Shift で AZ 障害 / Region 障害に対応し、aws_s3_bucket_replication_configuration の Replication Time Control (15min SLA) で S3 オブジェクトの Cross-Region DR を実装します。AZ → Region → Object の 3 層 DR を 1 本の記事で完結させます。
• DR 訓練 Runbook + RTO/RPO 実測スクリプト: 年次フル DR 訓練・四半期 Switchover 訓練・月次 Backup 復元訓練の 3 段階訓練マトリクスを QG-5 で定義し、boto3 Python スクリプトで RTO (秒) / RPO (秒) を実測する自動化を §7 で提供します。Vol2 Chaos Engineering (AWS FIS) への自然な接続点を準備します。
• 復旧・運用編シリーズ Vol1 起ち上げ + 12 巻完結後の延長: Lambda3 + EKS3 + 観測性3 + セキュリティ3 = 12 巻 AWS 本番運用シリーズ完結巻 (セキュリティ Vol3) で確立した本番運用基盤を、Multi-Region DR へ拡張する起ち上げ巻として位置付けます。Vol2-4 への展開ロードマップを §8 で予告します。

本記事の構成早見表

既存 12 巻 + Aurora DR 完全ガイドとの連携ポイント

• Aurora DR + AWS Backup 完全ガイド (単一 Region DR / slug: aurora-backup-restore-dr): §1 + §5 で「単一 Region (Aurora DR 編) → Multi-Region (本 Vol1)」の発展形として双方向クロスリンク
• 観測性 Vol1 CloudWatch Logs Insights: §7 で「Backup ジョブログ × Logs Insights クエリ」で RTO 内訳分析
• 観測性 Vol2 X-Ray + ADOT: §7 で「Cross-Region 分散トレーシングで Failover 経路分析」
• 観測性 Vol3 Application Signals + SLO: §7 で「DR 訓練後の SLO Burn Rate 監視」
• セキュリティ Vol1 GuardDuty: §4 で「Backup Vault への異常アクセス検知」
• セキュリティ Vol2 IAM Identity Center: §4 で「Cross-Account Backup の Permission Sets 設計」
• セキュリティ Vol3 AWS Config: §4 で「Backup Vault Lock の継続準拠確認 + Conformance Pack 適用」

12 巻完結後の延長線として読むと、観測性 → 計測、セキュリティ → 統制、DR → 復旧という運用ライフサイクルが完成します。

推定読了時間・難易度

1-2. 読者像

本記事は以下の読者を想定しています。

• 本番 AWS 環境の DR 設計を担う SRE/インフラエンジニア: 単一 Region 構成から Multi-Region DR 構成への移行を検討しており、AWS Backup Cross-Region コピー・Aurora Global Database・Route53 ARC を Terraform で IaC 化したい方。RTO/RPO 要件と月額コストのトレードオフを定量比較で意思決定したい方。
• PCI DSS / SOC2 / HIPAA 準拠で Multi-Region DR が必須要件の方: Vault Lock Compliance Mode による Backup の不可逆保護、Cross-Account コピーによる権限分離、Organizations Backup Policy による組織横断ガバナンスを Terraform で構築したい方。
• Aurora 単一 Region DR を実装済みで Multi-Region へ拡張したい方: Aurora Global Database による Region 障害対応、計画的 Switchover と計画外 Failover の選定基準、Writer 昇格後の Route53 自動切替の本番実装を学びたい方。
• 既存 12 巻 AWS 本番運用シリーズを通読し、復旧・運用編へ進みたい方: Lambda・EKS・観測性・セキュリティの 12 巻を経て、本番運用ライフサイクルの最終ピースである DR を学びたい方。
• DR 訓練を年次イベントとして終わらせず継続運用化したい方: RTO/RPO 実測スクリプトにより訓練結果を定量化し、Vol2 Chaos Engineering (AWS FIS) へ接続したい方。

Terraform の基本的な HCL 記述 (resource / variable / output / module) と AWS の Region/AZ 概念、Aurora の基本構成 (Cluster / Instance / Endpoint) を把握していることを前提とします。AWS Organizations + Service Control Policy の基礎知識があると §4 Cross-Account Backup と Organizations Backup Policy の設計がよりスムーズに理解できます。

Aurora DR 完全ガイド (Aurora × AWS Backup DR 単一 Region) の通読を強く推奨しますが、本記事 §5 で要点を再掲するため未読でも本 Vol1 から読み始められる構成です。Aurora 完全初学者の方は Aurora DR 完全ガイドから読み進めると Multi-Region への拡張がスムーズです。

1-3. なぜ今これを書くか

競合記事 50 件 (5 キーワード × 10 件) を Tavily で調査した結果、以下の空白地帯を確認しました。

• AWS Backup Cross-Region/Cross-Account + Aurora Global Database + Route53 ARC + S3 CRR の 4 サービスを 1 本で end-to-end 統合実装した日本語 Terraform 記事が競合 50 件中 0 件。AWS Storage Blog は per-service の解説が中心、DevelopersIO は Aurora 単体の Failover 実演が中心、tutorialsdojo は DR 戦略の概念解説のみ。
• DR 戦略 4 タイプ (Backup & Restore / Pilot Light / Warm Standby / Multi-Site) を RTO・RPO・月額コスト (USD)・運用複雑度の 4 軸で定量比較したマトリクスが 0 件。AWS 公式 Disaster Recovery whitepaper は概念分類のみでコスト試算なし。
• Aurora Global Database の計画的 Switchover (RPO=0 / <30s) と計画外 Failover (RPO=秒) の選定マトリクスを Terraform 完全実装と共に提示した記事が 0 件 (DevelopersIO は実演のみで選定基準なし)。
• Route53 ARC Zonal Shift + Routing Control + S3 CRR Replication Time Control を「AZ → Region → Object」の 3 層 DR としてアーキテクチャ統合した記事が 0 件 (AWS docs は単独機能のみ)。
• AWS Backup Vault Lock の Compliance Mode 不可逆性と Cooling Off Period (検証期間) を Terraform aws_backup_vault_lock_configuration 完全実装と共に解説した日本語記事が 0 件。
• DR 訓練の年次/四半期/月次マトリクスを RTO/RPO boto3 実測スクリプトと共に体系化した記事が 0 件。AWS Architecture Blog は概念的な best practices のみ。

復旧・運用編シリーズ Vol1 起ち上げ巻としての位置付け: 12 巻 AWS 本番運用シリーズ完結 (セキュリティ Vol3) を踏まえ、本番運用ライフサイクルの最終領域である「復旧」を起ち上げる巻です。Vol1 で DR 設計の基盤を確立し、Vol2 (Chaos Engineering / FIS) で障害注入による検証、Vol3 (Incident Response Runbook / SSM Automation) で運用フェーズの体系化、Vol4 (Active/Active vs Active/Passive) で究極の DR 構成を扱う 4 巻構成です。

12 巻完結後の延長線としての価値: Lambda3 (起動) + EKS3 (オーケストレーション) + 観測性3 (計測) + セキュリティ3 (統制) で構築した本番基盤を、Multi-Region 構成へスケールアップする延長線上に位置付けます。観測性 3 部作で確立した CloudWatch Logs Insights / X-Ray / Application Signals は本 Vol1 §7 の RTO/RPO 実測で再活用し、セキュリティ 3 部作で確立した Vault Lock / IAM Identity Center / AWS Config Conformance Pack は本 Vol1 §4 の Cross-Region/Cross-Account Backup でフル活用します。

復旧・運用編シリーズ ロードマップ

1-4. 読み進め方ガイド

本記事は通読を基本としますが、目的に応じて以下の読み進め方を推奨します。

§3・§4 は「DR 戦略選定と Backup 基盤構築」を扱う設計層で、Multi-Region DR の意思決定に最適です。§5〜§7 は「Terraform でどう実装するか」と「訓練でどう検証するか」の実践層で、コードと Runbook をそのまま活用できます。Aurora 単一 Region DR 未読の方は §5 冒頭で要点を再掲するため本記事から読み始めることも可能です。

前提シリーズ: 12 巻完結巻 セキュリティVol3 AWS Config+Conformance Pack+Auto Remediationを読む

2. 前提・環境・準備

本章では、本記事を実際に手を動かして進めるために必要な前提条件・AWS アカウント構成・使用サービス一覧・Terraform 環境・IAM 権限の 5 項目を整理します。

2-1. 前提条件

本記事の実装を進めるにあたり、以下の前提条件を満たしていることを確認してください。

AWS 環境

Terraform 環境

Aurora × AWS Backup 単一リージョン DR を実装済みの方は、本記事 §2-4 の差分概要を確認することで §5 Aurora Global Database から直接着手できます。

2-2. リージョン構成

本記事のコード例は以下のリージョン構成を前提とします。実際の環境に合わせて variables.tf の primary_region / secondary_region を変更してください。

リージョン選定の注意点

• Aurora Global Database は全リージョンペアで利用可能ではありません。AWS Aurora 対応リージョン一覧で事前確認が必要です。
• Route53 ARC の Control Plane は us-east-1 を使用します。Recovery Groups / Routing Controls / Readiness Checks は DR リージョンを問わず us-east-1 にデプロイします。
• S3 Cross-Region Replication の転送コストは東京→シンガポール間で約 $0.09/GB (2024 年時点) です。大容量バケットでは §3 コストバランスの試算を先に行うことを推奨します。

variables.tf (共通設定)

variable "primary_region" {
  description = "Primary AWS region (Tokyo)"
  type  = string
  default  = "ap-northeast-1"
}

variable "secondary_region" {
  description = "Secondary (DR) AWS region (Singapore)"
  type  = string
  default  = "ap-southeast-1"
}

variable "primary_account_id" {
  description = "AWS Account ID for primary workload account"
  type  = string
}

variable "dr_account_id" {
  description = "AWS Account ID for DR account (Cross-Account Backup target)"
  type  = string
}

variable "project_name" {
  description = "Project name used as resource prefix"
  type  = string
  default  = "dr-prod"
}

variable "backup_retention_days" {
  description = "Backup retention period in days"
  type  = number
  default  = 35
}

variable "dr_retention_days" {
  description = "Cross-Region / Cross-Account backup retention in days"
  type  = number
  default  = 90
}

2-3. 必要な IAM 権限

本番環境では管理アカウントと DR アカウントでそれぞれ必要な権限を最小化します。

管理アカウント (Primary) に必要なサービス権限

AWS Backup サービスロール: backup.amazonaws.com を Trusted Principal とする IAM ロールに AWSBackupServiceRolePolicyForBackup + AWSBackupServiceRolePolicyForRestores をアタッチします。Terraform の完全実装は §4-2 に含まれています。

2-4. 使用 AWS サービス一覧

2-5. Aurora DR 完全ガイド既読者向け差分ガイド

Aurora DR 完全ガイド (Aurora × AWS Backup 単一リージョン DR) を実装済みの方向けに、本 Vol1 で追加・変更となるポイントを整理します。

Aurora DR 完全ガイドで作成済みの aws_backup_vault · aws_backup_plan · aws_backup_selection は本 Vol1 の Terraform コードにそのまま取り込めます。copy_action ブロックを追加するだけで Cross-Region コピーが有効になるため、既存の Backup 設定からの移行コストは最小限です。

前提記事: Aurora DR + AWS Backup 完全ガイド を読む

3. DR 戦略設計 (RTO/RPO + 4 タイプ比較 + コストバランス)

3-1. RTO / RPO の定義とビジネス要件への落とし込み

RTO (Recovery Time Objective) は「障害発生からシステムが復旧するまでの最大許容時間」を指します。RTO=30 分であれば、障害発生から 30 分以内にサービスを再開しなければ SLA 違反となります。RTO の計測ポイントは「障害検知 → インシデント確認 → フェイルオーバー実行 → ヘルスチェック PASS」の合計時間です。

RPO (Recovery Point Objective) は「障害時点から遡ってどの時点のデータを許容するか」を示す最大許容データ損失量です。RPO=1 時間の場合、最大 1 時間分のトランザクションデータが失われても許容範囲内となります。RPO の計測は「最後のバックアップ/レプリケーション完了時刻 〜 障害発生時刻」の差分です。

ビジネス要件への落とし込みは「業務影響試算」から始めます。1 時間停止時の売上損失・SLA 違反ペナルティ・顧客信頼損失を CFO と合意し、その金額と DR コストを比較して最適戦略を選定します。金融・医療など規制業種では HIPAA/PCI-DSS が RTO/RPO の上限を法令で規定するため、コストに関わらず規制要件を優先します。

RTO/RPO の実測は DR 訓練時にのみ可能です。本記事 §7 では CloudWatch Synthetics + Lambda で自動ヘルスチェックを実装し、訓練ごとに RTO を秒単位で記録するスクリプトを提供します。「RTO=5 分と設計したが実測 12 分だった」という乖離を早期発見するためにも定期訓練 (§7) が不可欠です。

3-2. DR 戦略 4 タイプの全体像

AWS は DR 戦略を RTO/RPO と投資対効果の観点で 4 段階に体系化しています。RTO/RPO の短縮とコスト・複雑度の増加にはトレードオフ関係があり、ビジネス要件を満たす最小コストの戦略を選択することが設計の原則です。

コスト・複雑度
高 ┤  ┌──────────────────────────┐
│  │ Multi-Site Active/Active │
│  │ RTO=秒 / RPO=0 / $$$$│
│┌───────────────────┤  │
││ Warm Standby└──────────────────────────┘
││ RTO=数分 / RPO=秒 / $$$
│┌───────────┘
││ Pilot Light
││ RTO=10-30分 / RPO=分 / $$
│└──────────────── Backup & Restore: RTO=数時間 / RPO=時間 / $
低 ┤
└─────────────────────────────────────────────────────────▶ RTO の短さ

3-3. 各戦略の詳細解説

Backup & Restore (RTO=数時間〜1 日 / RPO=時間単位)

仕組み: プライマリリージョンで定期的にスナップショット・バックアップを取得し、DR リージョンへ自動コピーします。障害時は DR リージョンで AMI/RDS スナップショットから新規インスタンスを起動します。待機インスタンスは存在しないため起動に時間がかかりますが、コストは 4 戦略中最小です。

ユースケース: 開発/ステージング環境、週次バッチ処理基盤、RTO が 1 日以上許容される内部ツール・管理画面系。本番への適用は限定的ですが、バックアップ層として他戦略と組み合わせて活用されます。

AWS 実装パターン:
– AWS Backup + Cross-Region Copy → DR リージョンの Backup Vault に自動コピー (本記事 §4 で実装)
– EC2 AMI クロスリージョンコピー: aws ec2 copy-image --source-region ap-northeast-1 --region us-east-1
– RDS スナップショット復元: aws rds restore-db-instance-from-db-snapshot --db-snapshot-identifier <snap-id>

コスト試算: EC2 m5.xlarge + RDS db.r6g.large 構成でバックアップストレージのみ $50〜100/月。待機インスタンスゼロのため最小コスト。

Pilot Light (RTO=10〜30 分 / RPO=分単位)

仕組み: DR リージョンに最小限のコアコンポーネント (DB レプリカ・最小サイズのコンテナ 1 台) のみ常時稼働させます。障害時にアプリケーション層を自動スケールアウトして全負荷を引き受けます。「pilot light (種火)」の名前は、常時点灯した最小の火から本番規模へ燃え上がるイメージから来ています。

ユースケース: データ整合性が重要な EC サイト・SaaS、RTO=30 分以内が求められるが常時 Multi-Site では予算超過する中堅企業。Warm Standby への移行前の中間フェーズとしても採用されます。

AWS 実装パターン:
– RDS Multi-Region Read Replica (リアルタイムレプリケーション、フェイルオーバー時に Promote)
– Auto Scaling Group (min=0, max=10) → 障害時に desired_count を本番規模へ変更
– Route53 フェイルオーバールーティング + ヘルスチェック (TTL=30 秒推奨)

コスト試算: RDS Read Replica + EC2 最小 1 台で $200〜400/月追加。Backup & Restore 比 4〜8 倍ですが RTO を 10〜30 分に圧縮。

Warm Standby (RTO=数分 / RPO=秒〜分) ← 本記事採用

仕組み: DR リージョンに本番の縮小版 (1/4〜1/2 スペック) を常時稼働させ、本番と同等の処理能力まで即座にスケールアウト可能な状態を維持します。Pilot Light と異なりアプリケーション層も常時起動しているため、フェイルオーバー時のスケールアウトだけで DR 完了します。

ユースケース: 金融・医療・SaaS プラットフォームなど RTO=5 分以内・99.95% SLA を要求する本番システム。月額コスト $$$ (中程度) でエンタープライズグレードの DR を実現。本記事の実装対象。

AWS 実装パターン:
– Aurora Global Database (DR リージョンに Read Replica を常時稼働、フェイルオーバー時に Writer 昇格)
– ECS Fargate (DR リージョンで 1 タスク常時稼働 → フェイルオーバー時に desired_count を本番規模に増加)
– Route53 ARC Routing Control (§6 で実装) で自動フェイルオーバー制御

コスト試算: Aurora GDB + ECS 縮小版 + ALB で $600〜1,200/月追加。RPO=1 秒以下・RTO=5 分以内を実現。

Multi-Site Active/Active (RTO=秒 / RPO=0)

仕組み: 複数リージョンでフル本番トラフィックを同時処理します。障害時は即座に残存リージョンへ全トラフィックを移行し、RTO=秒を実現します。データは常時同期されるため RPO=0 を達成します。すべてのリージョンが能動的に本番負荷を処理する点が「Active/Active」の由来です。

ユースケース: グローバル展開の金融取引プラットフォーム・ゲームプラットフォーム・電子決済インフラ。年間売上が数百億円規模で、ダウンタイム 1 秒のコストが DR 月額コストを上回るケース。

AWS 実装パターン:
– DynamoDB Global Tables (マルチリージョン書き込み、自動双方向レプリケーション)
– Aurora Global Database + 双方向レプリケーション (Write Forwarding 機能)
– AWS Global Accelerator (Anycast IP) + Route53 ARC Zonal Shift で秒単位フェイルオーバー

コスト試算: フル本番環境を 2 リージョン分稼働させるため $1,800〜3,000/月追加。ROI が合うのは 1 時間停止損失が $3,000 以上の大規模ビジネスのみ。

3-4. コスト試算 (USD/月・参考値)

以下は ap-northeast-1 (プライマリ) + us-east-1 (DR) の参考コスト試算です。想定規模: Web アプリ (EC2 m5.xlarge×2 + Aurora db.r6g.large×2 + ALB + S3 100 GB)。オンデマンド価格基準。Savings Plans・Reserved Instance 適用で 30〜60% 削減可能。

Aurora Global Database の DR リージョンインスタンスは Primary の Read Replica として機能するため追加 Aurora ライセンス費用はありません。フェイルオーバー時の Writer 昇格 (Promote) も Aurora 標準機能で追加料金なしです。ただし DR リージョンの EC2/ECS インスタンス稼働費用・クロスリージョンデータ転送費用 ($0.02/GB) は別途発生します。

3-5. 本記事の実装方針: Warm Standby + Aurora Global Database

本記事では Warm Standby を基本 DR 戦略として採用します。採用理由は以下の 3 点です。

• RTO 目標: 5 分以内 — Route53 ARC Routing Control + ECS Fargate の自動スケールアウトにより、フェイルオーバー開始から 5 分以内に DR リージョンへトラフィックを完全移行
• RPO 目標: 1 秒以下 — Aurora Global Database のレプリケーションラグは通常 1 秒未満。Multi-Site と同等の RPO を Warm Standby コスト ($$$) で実現
• コスト最適化 — Multi-Site Active/Active ($$$$) と比較して月額 $1,000〜2,000 の節約。DR リージョンの ECS は縮小スペック (1 タスク) で待機し、フェイルオーバー時のみ本番規模へスケールアウト

Aurora Global Database を採用することで、DR リージョンの Read Replica が通常時も読み取り負荷分散に活用でき、コスト効率がさらに向上します。フェイルオーバー時は Aurora の Managed Planned Failover (Switchover) を使用し、Writer 昇格を 30 秒以内に完了させます (§5 詳解)。

3-6. Terraform: DR 変数定義

§4〜§6 の Terraform 実装全体で参照する DR 戦略変数を variables.tf に定義します。

variable "rto_minutes" {
  description = "Recovery Time Objective in minutes (target: <=5)"
  type  = number
  default  = 5
  validation {
 condition  = var.rto_minutes >= 1 && var.rto_minutes <= 1440
 error_message = "rto_minutes must be between 1 and 1440 (24 hours)."
  }
}

variable "rpo_minutes" {
  description = "Recovery Point Objective in minutes (target: <=1)"
  type  = number
  default  = 1
  validation {
 condition  = var.rpo_minutes >= 0 && var.rpo_minutes <= 1440
 error_message = "rpo_minutes must be between 0 and 1440 (24 hours)."
  }
}

variable "dr_strategy" {
  description = "DR strategy: backup_restore / pilot_light / warm_standby / multi_site"
  type  = string
  default  = "warm_standby"
  validation {
 condition  = contains(["backup_restore", "pilot_light", "warm_standby", "multi_site"], var.dr_strategy)
 error_message = "dr_strategy must be one of: backup_restore, pilot_light, warm_standby, multi_site."
  }
}

variable "primary_region" {
  description = "Primary AWS region (e.g. ap-northeast-1)"
  type  = string
  default  = "ap-northeast-1"
}

variable "dr_region" {
  description = "DR AWS region (e.g. us-east-1)"
  type  = string
  default  = "us-east-1"
}

3-7. fig02: DR 戦略 4 タイプ意思決定フロー

flowchart TD
 A[DR設計開始] --> B{RTO要件は?}
 B -->|1時間以上許容| C[Backup & Restore]
 B -->|10-60分| D{RPO要件は?}
 B -->|数分| E{コスト許容は?}
 B -->|秒単位| F[Multi-Site Active/Active]
 D -->|時間単位許容| G[Pilot Light]
 D -->|分単位| E
 E -->|中程度| H[Warm Standby]
 E -->|限定的| G
 C --> I[月額コスト: 最小]
 G --> J[月額コスト: 小]
 H --> K[月額コスト: 中]
 F --> L[月額コスト: 最大]

4. AWS Backup 完全実装 (Cross-Region / Cross-Account / Vault Lock)

AWS Backup は EC2・RDS・EFS・DynamoDB・S3 など 14 サービスのバックアップを一元管理するマネージドサービスです。本章では Backup Plan / Vault / Selection / Job の 4 コンポーネントを Terraform で実装し、Cross-Region コピー・Cross-Account コピー・Vault Lock (Compliance Mode) まで段階的に完全実装します。

4-1. AWS Backup 全体設計

AWS Backup の 4 コンポーネントは次の関係で動作します。Backup Plan が「いつ・何を・どこへ・どの保持期間で」を定義し、Backup Vault がバックアップデータの格納先 (KMS CMK 暗号化) を担い、Backup Selection が「どのリソースをバックアップ対象にするか」をタグまたは ARN で指定し、Backup Job が実行時に生成されるジョブエンティティです。

Backup Plan (Rule: schedule / retention / lifecycle)
 └─ copy_action → DR Region Vault
Backup Selection (tag: backup=true / ARN 指定)
 └─ targets → EC2 / RDS / EFS / DynamoDB / S3
Backup Vault (KMS CMK / Access Policy / Vault Lock)
 └─ Recovery Points (バックアップデータ本体)
Backup Job (実行記録 / status: COMPLETED / FAILED / ABORTED)

Multi-Region DR の基本方針は「プライマリリージョン (ap-northeast-1) の Backup Vault に作成した Recovery Point を、copy_action で DR リージョン (us-east-1) の Vault へ自動コピー」です。Cross-Account Copy はさらに DR Account の Vault へコピーし、Organizations Backup Policy で組織横断適用します。

4-2. Backup Vault + Backup Plan (Cross-Region copy_action) Terraform 実装

Backup Vault (KMS CMK 暗号化)

resource "aws_kms_key" "backup_primary" {
  description = "AWS Backup primary region KMS key"
  deletion_window_in_days = 30
  enable_key_rotation  = true
  tags = { Environment = var.environment, ManagedBy = "terraform" }
}

resource "aws_backup_vault" "primary" {
  name  = "backup-vault-primary-${var.environment}"
  kms_key_arn = aws_kms_key.backup_primary.arn
  tags = { Environment = var.environment, Purpose = "primary-backup" }
}

resource "aws_backup_vault" "dr_region" {
  provider = aws.dr
  name  = "backup-vault-dr-${var.environment}"
  kms_key_arn = aws_kms_key.backup_dr.arn
  tags = { Environment = var.environment, Purpose = "dr-backup" }
}

Backup Plan (daily + weekly / copy_action 付き)

resource "aws_backup_plan" "main" {
  name = "backup-plan-${var.environment}"

  rule {
 rule_name= "daily-backup-90d"
 target_vault_name = aws_backup_vault.primary.name
 schedule = "cron(0 18 * * ? *)"  # UTC 18:00 = JST 03:00

 lifecycle {
cold_storage_after = 30
delete_after = 90
 }

 copy_action {
destination_vault_arn = aws_backup_vault.dr_region.arn
lifecycle {
  cold_storage_after = 30
  delete_after = 90
}
 }
  }

  # weekly: schedule="cron(0 18 ? * 1 *)", cold_storage_after=90, delete_after=365 (同パターン)

  tags = { Environment = var.environment, ManagedBy = "terraform" }
}

Backup Selection (タグ: backup=true)

resource "aws_iam_role" "backup_service" {
  name = "aws-backup-service-role-${var.environment}"
  assume_role_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = { Service = "backup.amazonaws.com" }
 }]
  })
}

resource "aws_iam_role_policy_attachment" "backup_policy" {
  role = aws_iam_role.backup_service.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForBackup"
}

resource "aws_iam_role_policy_attachment" "restore_policy" {
  role = aws_iam_role.backup_service.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForRestores"
}

resource "aws_backup_selection" "tagged_resources" {
  name= "backup-selection-tagged-${var.environment}"
  plan_id= aws_backup_plan.main.id
  iam_role_arn = aws_iam_role.backup_service.arn

  selection_tag {
 type  = "STRINGEQUALS"
 key= "backup"
 value = "true"
  }
}

タグ backup=true を付与したリソース (EC2 インスタンス・RDS クラスター・EFS ファイルシステム・DynamoDB テーブル) が自動的にバックアップ対象となります。環境ごとに保持期間を変えたい場合は selection_tag を { key = "Environment", value = "prod" } 等に変更し、複数の Backup Plan で管理します。

AWS CLI (手動 Cross-Region コピー)

aws backup start-copy-job \
  --recovery-point-arn arn:aws:backup:ap-northeast-1:123456789012:recovery-point:EXAMPLE \
  --source-backup-vault-name backup-vault-primary-prod \
  --destination-backup-vault-arn arn:aws:backup:us-east-1:123456789012:backup-vault:backup-vault-dr-prod \
  --iam-role-arn arn:aws:iam::123456789012:role/aws-backup-service-role-prod \
  --region ap-northeast-1

コンソール操作: AWS Backup → Backup plans → 対象プラン → Edit → Add copy → Destination Region (例: us-east-1) と Vault を選択 → Save plan。

4-3. Cross-Account Copy 実装

Cross-Account Copy には Source Account で Backup Global Settings を有効化し、DR Account の Vault に Access Policy で Source Account からのコピーを許可する 2 ステップが必要です。

Terraform: aws_backup_global_settings + Vault Access Policy

resource "aws_backup_global_settings" "this" {
  global_settings = {
 "isCrossAccountBackupEnabled" = "true"
  }
}

resource "aws_backup_vault_policy" "dr_account_vault" {
  provider = aws.dr_account
  backup_vault_name = aws_backup_vault.dr_account.name

  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Effect = "Allow"
Principal = { AWS = "arn:aws:iam::${var.source_account_id}:root" }
Action = ["backup:CopyIntoBackupVault"]
Resource  = "*"
 }]
  })
}

AWS CLI (DR Account Vault へのアクセスポリシー設定)

POLICY='{
  "Version": "2012-10-17",
  "Statement": [{
 "Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::SOURCE_ACCOUNT_ID:root"},
 "Action": "backup:CopyIntoBackupVault",
 "Resource": "*"
  }]
}'
aws backup put-backup-vault-access-policy \
  --backup-vault-name backup-vault-dr-prod \
  --policy "$POLICY" \
  --region us-east-1

コンソール操作: AWS Backup (DR Account) → Backup vaults → 対象 Vault → Access policy → Edit → Principal に Source Account ARN を追加 → Save。

Organizations Backup Policy は管理アカウントで aws organizations create-policy --type BACKUP_POLICY + aws organizations attach-policy で OU/Member Account に適用し、Delegated Admin は aws organizations register-delegated-administrator --service-principal backup.amazonaws.com で委任します。

4-4. Vault Lock (Compliance Mode) 実装

Terraform: aws_backup_vault_lock_configuration

resource "aws_backup_vault_lock_configuration" "primary" {
  backup_vault_name= aws_backup_vault.primary.name
  changeable_for_days = 3 # Cooling Off Period (最小値: 3日 = 72時間)
  min_retention_days  = 7
  max_retention_days  = 365
}

changeable_for_days=3 は Cooling Off Period (72 時間) です。この期間内は terraform destroy で設定を削除できますが、経過後は Compliance Mode が恒久適用されます。min_retention_days=7 を設定すると 7 日未満の保持期間を持つ Recovery Point は自動削除から保護されます。本番環境では Governance Mode (changeable_for_days 省略) で挙動確認後に Compliance Mode へ移行してください。

AWS CLI

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name backup-vault-primary-prod \
  --min-retention-days 7 \
  --max-retention-days 365 \
  --changeable-for-days 3 \
  --region ap-northeast-1

コンソール操作: AWS Backup → Backup vaults → 対象 Vault → Edit → Enable Vault Lock → Compliance mode を選択 → Min/Max 保持期間を入力 → 確認テキスト入力 → Enable Vault Lock。

4-5. IAM 権限設計

Cross-Account Copy では Source Account の Backup Service Role に backup:CopyFromBackupVault 権限と、DR Account の backup:CopyIntoBackupVault 権限を追加します。Organizations Backup Policy を使用する際は Delegated Admin Account で iam:PassRole を付与し、Member Account の Backup Service Role へのロール委任を許可します。

4-6. 監視 (EventBridge + SNS + CloudWatch)

Terraform: EventBridge Rule + SNS + CloudWatch Alarm

resource "aws_cloudwatch_event_rule" "backup_job_failed" {
  name  = "backup-job-failed-${var.environment}"
  description = "Detect AWS Backup Job FAILED/ABORTED/EXPIRED"

  event_pattern = jsonencode({
 source= ["aws.backup"]
 detail-type = ["Backup Job State Change"]
 detail= { state = ["FAILED", "ABORTED", "EXPIRED"] }
  })
}

resource "aws_cloudwatch_event_target" "backup_alert" {
  rule= aws_cloudwatch_event_rule.backup_job_failed.name
  target_id = "BackupJobFailedSNS"
  arn = aws_sns_topic.backup_alerts.arn
}

resource "aws_cloudwatch_metric_alarm" "backup_failed" {
  alarm_name = "backup-job-failed-${var.environment}"
  comparison_operator = "GreaterThanOrEqualToThreshold"
  evaluation_periods  = 1
  metric_name= "NumberOfBackupJobsFailed"
  namespace  = "AWS/Backup"
  period  = 3600
  statistic  = "Sum"
  threshold  = 1
  alarm_description= "AWS Backup Job failure detected"
  alarm_actions = [aws_sns_topic.backup_alerts.arn]

  dimensions = {
 BackupVaultName = aws_backup_vault.primary.name
  }
}

Backup Job 失敗は EventBridge detail.state = ["FAILED", "ABORTED", "EXPIRED"] でキャッチし、SNS 経由で Chatbot (Slack) または PagerDuty へ通知します。CloudWatch Metric NumberOfBackupJobsFailed のアラームを二重監視とすることで、EventBridge ルールのサイレント障害を防ぎます。

5. Aurora Global Database 本番運用 (Aurora DR 完全ガイドの発展実装)

5-1. Aurora Global Database とは — Aurora DR 完全ガイド (単一 Region DR) との対比

Aurora DR 完全ガイド (Aurora × AWS Backup 単一 Region DR) では、プライマリとリードレプリカが同一 AWS リージョン内に存在する構成で、AZ 障害には対応できますがリージョン障害には対応できません。本章では Aurora Global Database を用いてセカンダリリージョンへのリアルタイムレプリケーションを構築し、リージョン障害時の切替 (Failover) と計画的切替 (Switchover) を Terraform で end-to-end 実装します。

Aurora Global Database は専用物理レプリケーション経路で 1 秒未満の lag を実現します。セカンダリクラスターは平常時 Reader Endpoint のみを提供し、リージョン障害時に Writer へ昇格します。

5-2. Terraform: Aurora Global Database 構築

Primary Region (ap-northeast-1) にグローバルクラスターを作成し、Secondary Region (us-east-1) のセカンダリクラスターをアタッチします。

# ── グローバルクラスター定義 ──
resource "aws_rds_global_cluster" "main" {
  global_cluster_identifier = "myapp-global-cluster"
  engine  = "aurora-mysql"
  engine_version= "8.0.mysql_aurora.3.05.2"
  database_name = "myapp"
  storage_encrypted= true
}

# ── Primary Cluster (ap-northeast-1) ──
resource "aws_rds_cluster" "primary" {
  provider= aws.ap_northeast_1
  cluster_identifier  = "myapp-primary"
  global_cluster_identifier = aws_rds_global_cluster.main.id
  engine  = aws_rds_global_cluster.main.engine
  engine_version= aws_rds_global_cluster.main.engine_version
  database_name = "myapp"
  master_username  = var.db_username
  master_password  = var.db_password
  db_subnet_group_name= aws_db_subnet_group.primary.name
  vpc_security_group_ids = [aws_security_group.rds_primary.id]
  backup_retention_period= 7
  skip_final_snapshot = false
  final_snapshot_identifier = "myapp-primary-final-snapshot"
}

resource "aws_rds_cluster_instance" "primary" {
  provider  = aws.ap_northeast_1
  count  = 2
  identifier= "myapp-primary-${count.index}"
  cluster_identifier = aws_rds_cluster.primary.id
  instance_class  = "db.r6g.large"
  engine = aws_rds_cluster.primary.engine
  engine_version  = aws_rds_cluster.primary.engine_version
}

# ── Secondary Cluster (us-east-1) ──
resource "aws_rds_cluster" "secondary" {
  provider= aws.us_east_1
  cluster_identifier  = "myapp-secondary"
  global_cluster_identifier = aws_rds_global_cluster.main.id
  engine  = aws_rds_global_cluster.main.engine
  engine_version= aws_rds_global_cluster.main.engine_version
  db_subnet_group_name= aws_db_subnet_group.secondary.name
  vpc_security_group_ids = [aws_security_group.rds_secondary.id]
  skip_final_snapshot = true

  lifecycle {
 ignore_changes = [replication_source_identifier]
  }

  depends_on = [aws_rds_cluster_instance.primary]
}

resource "aws_rds_cluster_instance" "secondary" {
  provider  = aws.us_east_1
  count  = 1
  identifier= "myapp-secondary-0"
  cluster_identifier = aws_rds_cluster.secondary.id
  instance_class  = "db.r6g.large"
  engine = aws_rds_cluster.secondary.engine
  engine_version  = aws_rds_cluster.secondary.engine_version
}

落とし穴①: Secondary Cluster 作成直後は replication_source_identifier が AWS 側で自動設定されます。lifecycle { ignore_changes = [replication_source_identifier] } を追加しないと terraform plan のたびに差分として検出され続けます。

5-3. Switchover (計画的切替・RPO=0 / <30 秒)

Switchover はデータロスなし (RPO=0) でプライマリリージョンを切り替える計画的操作です。メンテナンス・DR 訓練・リージョン移行に使用します。AWS は切替前に Secondary がプライマリへ完全追従していることを確認してから切替を実行するため、データロスが発生しません。

AWS CLI による Switchover:

# 計画的 Switchover: ap-northeast-1 → us-east-1
aws rds switchover-global-cluster \
  --global-cluster-identifier myapp-global-cluster \
  --target-db-cluster-arn arn:aws:rds:us-east-1:123456789012:cluster:myapp-secondary \
  --region ap-northeast-1

# 進捗確認 (Status: switching-over → available で完了)
aws rds describe-global-clusters \
  --global-cluster-identifier myapp-global-cluster \
  --query 'GlobalClusters[0].{Status:Status,Members:GlobalClusterMembers[].{ARN:DBClusterArn,Writer:IsWriter}}' \
  --output json

コンソール操作:
1. RDS コンソール (ap-northeast-1) → Global databases → myapp-global-cluster を選択
2. Actions → Switch over or fail over global database をクリック
3. Switch over を選択 → ターゲットリージョンに us-east-1 を指定
4. Switch over ボタンをクリック (完了まで約 10〜30 秒)

落とし穴②: Switchover 完了後、旧 Primary (ap-northeast-1) は自動的に Secondary に降格します。アプリケーションの DB 接続先を新 Writer Endpoint (us-east-1) に切り替える必要があります。Route53 Failover Routing による自動切替 (5-5 節) で対応します。

5-4. Failover (計画外切替・RPO=秒・緊急時)

リージョン障害 (ap-northeast-1 全滅) 発生時は Failover で Secondary (us-east-1) を新 Writer に昇格させます。RPO はレプリケーション lag 分 (通常 1 秒未満) 発生します。Primary Region の API が応答しない場合は Secondary Region から実行します。

AWS CLI による Failover:

# 緊急 Failover: Primary 障害時 (Secondary Region から実行)
aws rds failover-global-cluster \
  --global-cluster-identifier myapp-global-cluster \
  --target-db-cluster-arn arn:aws:rds:us-east-1:123456789012:cluster:myapp-secondary \
  --region us-east-1

# Writer 昇格確認
aws rds describe-db-clusters \
  --db-cluster-identifier myapp-secondary \
  --region us-east-1 \
  --query 'DBClusters[0].{Status:Status,MultiAZ:MultiAZ}' \
  --output json

コンソール操作:
1. RDS コンソール (us-east-1 で操作) → Global databases → myapp-global-cluster
2. Actions → Switch over or fail over global database
3. Fail over を選択 → ターゲットに us-east-1 を指定
4. Fail over をクリック (Writer 昇格: 数分)

Switchback (旧 Primary 復旧後の元構成への切戻し):

# Step1: 旧 Primary を Global Cluster から Detach
aws rds remove-from-global-cluster \
  --global-cluster-identifier myapp-global-cluster \
  --db-cluster-identifier arn:aws:rds:ap-northeast-1:123456789012:cluster:myapp-primary \
  --region us-east-1

# Step2: Detach 後に Switchover で ap-northeast-1 を新 Primary に戻す
aws rds switchover-global-cluster \
  --global-cluster-identifier myapp-global-cluster \
  --target-db-cluster-arn arn:aws:rds:ap-northeast-1:123456789012:cluster:myapp-primary \
  --region us-east-1

落とし穴③: Failover 後、旧 Primary (ap-northeast-1) が復旧しても自動的にグローバルクラスターへ再参加しません。上記 Detach → Switchover の 2 ステップ Switchback 手順を Runbook に明記しておかないと、障害対応中に手順が抜ける原因になります。

5-5. Route53 自動切替 Terraform (Failover Routing + Health Check)

アプリケーションが db.myapp.internal に接続し、プライマリ障害時に Route53 が Secondary Writer Endpoint へ自動ルーティングを切り替えます。TTL=30 秒で切替遅延を最小化します。

# Primary Writer Endpoint の TCP Health Check
resource "aws_route53_health_check" "primary_rds" {
  fqdn  = aws_rds_cluster.primary.endpoint
  port  = 3306
  type  = "TCP"
  request_interval  = 10
  failure_threshold = 3

  tags = { Name = "myapp-primary-rds-hc" }
}

# Primary DNS レコード (Failover PRIMARY)
resource "aws_route53_record" "db_primary" {
  zone_id = aws_route53_zone.private.zone_id
  name = "db.myapp.internal"
  type = "CNAME"
  ttl  = 30

  failover_routing_policy {
 type = "PRIMARY"
  }
  set_identifier  = "primary"
  health_check_id = aws_route53_health_check.primary_rds.id
  records= [aws_rds_cluster.primary.endpoint]
}

# Secondary DNS レコード (Failover SECONDARY)
resource "aws_route53_record" "db_secondary" {
  zone_id = aws_route53_zone.private.zone_id
  name = "db.myapp.internal"
  type = "CNAME"
  ttl  = 30

  failover_routing_policy {
 type = "SECONDARY"
  }
  set_identifier = "secondary"
  records  = [aws_rds_cluster.secondary.endpoint]
}

Health Check が failure_threshold=3 回連続失敗 (30 秒) を検知すると Secondary レコードへ自動切替します。アプリケーションは DNS キャッシュ (TTL=30 秒) 失効後に Secondary Writer Endpoint へ再接続します。アプリの DB 接続タイムアウトも 30 秒以上に設定し、切替中の接続エラーを吸収する設計にすることを推奨します。

5-6. Aurora Global Database フェイルオーバーフロー (fig04)

sequenceDiagram
 participant App as アプリ (Primary)
 participant EventBridge as EventBridge
 participant Primary as Aurora Primary (東京)
 participant Secondary as Aurora Secondary (シンガポール)
 participant R53 as Route53

 EventBridge->>App: リージョン障害検知
 App->>EventBridge: Failoverトリガー
 EventBridge->>Secondary: failover-global-cluster 実行
 Secondary->>Secondary: Writer昇格
 Secondary->>Primary: Replication停止
 Secondary->>R53: Endpoint 切替 (CNAME更新)
 R53->>App: 新Endpoint通知
 App->>Secondary: 再接続 (新Writer)

Aurora 単一リージョン DR (AWS Backup + スナップショット) の詳細は Aurora DR + AWS Backup 完全ガイド を参照してください。AZ 障害 (Aurora DR 編) → リージョン障害 (本 Vol1) の障害規模スケールに応じた DR 戦略を組み合わせることで、完全な Multi-Layer DR が実現できます。

6. Route53 ARC + S3 CRR (3 層 DR 構成)

6-1. Route53 ARC 概要 — 3 層 DR の制御層

Route53 Application Recovery Controller (ARC) は AZ 障害 と Region 障害 の 2 スコープを独立した機能で制御する。Zonal Shift は ELB リソースの特定 AZ へのトラフィックを秒単位で排除し、Routing Control は Recovery Group の on/off 状態で Route53 Failover レコードの切替をトリガーする。S3 Cross-Region Replication (CRR) の Replication Time Control (RTC) を組み合わせると「AZ 障害 → Region 障害 → オブジェクト損失」の 3 層 DR を単一の Terraform 構成で完結させられる。

ARC は AWS Organizations 不要でシングルアカウントから利用可能。Routing Control の ARC Cluster は 5 リージョンに分散した専用エンドポイントを持ち、Primary Region 完全停止時でも 2/5 クォーラムで操作継続が保証される。

6-2. ARC Zonal Shift — AZ 障害への即時対応

Zonal Shift は ALB / NLB を対象に特定 AZ からトラフィックを切り離す機能だ。AWS Managed Resource として登録するだけで使用可能になり、HealthCheck の失敗をトリガーに EventBridge → Lambda で自動実行するパターンが本番推奨となる。

Terraform: aws_arc_zonal_shift_managed_resource

# ── ARC Zonal Shift — ALB を Managed Resource として登録 ──────────────
resource "aws_arc_zonal_shift_managed_resource" "primary_alb" {
  resource_identifier = aws_lb.primary.arn
}

自動化は EventBridge Rule (ALB HealthCheck 失敗) → Lambda (start-zonal-shift 呼び出し) で構成する。

AWS CLI — 手動 Zonal Shift 実行

# AZ-a に障害発生 → トラフィックを即時切替
aws arc-zonal-shift start-zonal-shift \
  --resource-identifier arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/primary-alb/abc123 \
  --away-from ap-northeast-1a \
  --expires-in 1H \
  --comment "AZ-a hardware failure — shifting traffic to AZ-b and AZ-c"

# Zonal Shift の現在状態確認
aws arc-zonal-shift list-zonal-shifts \
  --status ACTIVE \
  --region ap-northeast-1

コンソール操作: Route53 → Application Recovery Controller → Zonal shift → リソース選択 → Start zonal shift → Away from AZ 指定 → Duration 設定 → Start。

Zonal Shift 運用上の注意点

Zonal Shift は有効期間 (expires-in) が必須で、最大 3 日間まで設定可能だ。期間終了後は自動的に解除されるため、恒久的な切替には Routing Control を使用する。また、3 AZ 構成の場合、1 AZ を切り離すと残り 2 AZ でトラフィックを処理するため、事前に各 AZ のキャパシティが 50% 増しで処理できることを確認する。

6-3. ARC Routing Control — Region 障害対応

Routing Control は Cluster → Control Panel → Routing Control → Safety Rule の 4 階層で構成する。Recovery Group と Readiness Check を組み合わせることで、フェイルオーバー前に Secondary Region の準備状態を継続的に確認できる。

Terraform: Cluster + Control Panel + Routing Control

# ── ARC Cluster (5 リージョン分散エンドポイント) ──────────────────────
resource "aws_route53recoverycontrol_cluster" "production" {
  name = "production-dr-cluster"
}

# ── Control Panel (論理グループ) ──────────────────────────────────────
resource "aws_route53recoverycontrol_control_panel" "production" {
  name  = "production-control-panel"
  cluster_arn = aws_route53recoverycontrol_cluster.production.arn
}

# ── Routing Control × 2 (Primary / Secondary) ────────────────────────
resource "aws_route53recoverycontrol_routing_control" "primary" {
  name  = "primary-region-ap-northeast-1"
  cluster_arn = aws_route53recoverycontrol_cluster.production.arn
  control_panel_arn = aws_route53recoverycontrol_control_panel.production.arn
}

resource "aws_route53recoverycontrol_routing_control" "secondary" {
  name  = "secondary-region-us-east-1"
  cluster_arn = aws_route53recoverycontrol_cluster.production.arn
  control_panel_arn = aws_route53recoverycontrol_control_panel.production.arn
}

# ── Safety Rule: 必ず 1 リージョンが Active であることを保証 ─────────
resource "aws_route53recoverycontrol_safety_rule" "atleast_one_active" {
  name  = "assert-one-region-always-active"
  control_panel_arn = aws_route53recoverycontrol_control_panel.production.arn
  wait_period_ms = 5000

  asserted_controls = [aws_route53recoverycontrol_routing_control.primary.arn]

  rule_config {
 inverted  = false
 threshold = 1
 type= "ATLEAST"
  }
}

# ── Route53 Health Check (Routing Control 連動) ───────────────────────
resource "aws_route53_health_check" "primary_arc" {
  type  = "RECOVERY_CONTROL"
  routing_control_arn  = aws_route53recoverycontrol_routing_control.primary.arn
  tags = { Name = "arc-primary-health-check" }
}

# ── Route53 Failover Record ───────────────────────────────────────────
resource "aws_route53_record" "primary_failover" {
  zone_id = aws_route53_zone.production.zone_id
  name = "api.example.com"
  type = "A"
  set_identifier = "primary"

  failover_routing_policy {
 type = "PRIMARY"
  }

  alias {
 name = aws_lb.primary.dns_name
 zone_id = aws_lb.primary.zone_id
 evaluate_target_health = true
  }

  health_check_id = aws_route53_health_check.primary_arc.id
}

Terraform: Recovery Group + Readiness Check

resource "aws_route53recoveryreadiness_recovery_group" "production" {
  recovery_group_name = "production-recovery-group"
  cells = [
 aws_route53recoveryreadiness_cell.primary.arn,
 aws_route53recoveryreadiness_cell.secondary.arn,
  ]
}

resource "aws_route53recoveryreadiness_readiness_check" "aurora" {
  readiness_check_name = "aurora-global-db-readiness"
  resource_set_name = aws_route53recoveryreadiness_resource_set.aurora.resource_set_name
}

AWS CLI — Routing Control 切替 (Region Failover 実行)

# Primary → Secondary へのフェイルオーバー
# ARC Cluster の 5 エンドポイントのいずれかを使用
CLUSTER_ENDPOINT="$(aws route53-recovery-control-config list-clusters \
  --query 'Clusters[0].ClusterEndpoints[0].Endpoint' --output text)"

aws route53-recovery-cluster update-routing-control-state \
  --routing-control-arn arn:aws:route53-recovery-control::123456789012:controlpanel/abc123/routingcontrol/primary456 \
  --routing-control-state Off \
  --endpoint-url "https://${CLUSTER_ENDPOINT}"

aws route53-recovery-cluster update-routing-control-state \
  --routing-control-arn arn:aws:route53-recovery-control::123456789012:controlpanel/abc123/routingcontrol/secondary789 \
  --routing-control-state On \
  --endpoint-url "https://${CLUSTER_ENDPOINT}"

コンソール操作: Route53 → Application Recovery Controller → Recovery groups → Control Panel 選択 → Routing controls → Primary を Off / Secondary を On に切替。Safety Rule の確認ダイアログが表示されるため承認して実行。

6-4. S3 Cross-Region Replication 実装

S3 CRR は Primary Region のオブジェクトを Secondary Region に非同期複製する。バージョニング有効化が必須条件で、暗号化オブジェクトは KMS キーのクロスアカウント/クロスリージョン設定が別途必要になる。

Terraform: S3 バージョニング + CRR 構成

# ── バージョニング (Primary / Secondary 両バケットで必須) ─────────────
resource "aws_s3_bucket_versioning" "primary" {
  bucket = aws_s3_bucket.primary.id
  versioning_configuration { status = "Enabled" }
}

resource "aws_s3_bucket_versioning" "secondary" {
  provider = aws.secondary
  bucket= aws_s3_bucket.secondary.id
  versioning_configuration { status = "Enabled" }
}

# IAM ロール/ポリシーは aws_iam_role + aws_iam_role_policy で
# s3.amazonaws.com Assume + GetObjectVersion*/ReplicateObject 権限を付与する。

# ── CRR 設定 (RTC 有効) ──────────────────────────────────────────────
resource "aws_s3_bucket_replication_configuration" "primary_to_secondary" {
  bucket = aws_s3_bucket.primary.id
  role= aws_iam_role.s3_replication.arn

  rule {
 id  = "crr-all-objects-with-rtc"
 status = "Enabled"

 filter {}

 destination {
bucket  = aws_s3_bucket.secondary.arn
storage_class = "STANDARD_IA"

replication_time {
  status = "Enabled"
  time { minutes = 15 }
}

metrics {
  status = "Enabled"
  event_threshold { minutes = 15 }
}

encryption_configuration {
  replica_kms_key_id = aws_kms_key.secondary.arn
}
 }

 delete_marker_replication { status = "Enabled" }
  }

  depends_on = [
 aws_s3_bucket_versioning.primary,
 aws_s3_bucket_versioning.secondary,
  ]
}

AWS CLI — CRR 設定確認と手動検証

# CRR 設定確認
aws s3api get-bucket-replication \
  --bucket production-primary-bucket \
  --region ap-northeast-1

# テストオブジェクトを PUT して複製遅延を確認
aws s3 cp test-object.txt s3://production-primary-bucket/replication-test/ \
  --region ap-northeast-1

# Secondary で複製確認 (15 分以内に出現するはず)
aws s3 ls s3://production-secondary-bucket/replication-test/ \
  --region us-east-1

コンソール操作: S3 → バケット選択 → Management タブ → Replication rules → Create replication rule → Replication Time Control を有効化 → Destination bucket / IAM role 指定 → Save。

6-5. S3 Replication Time Control (RTC) — 15 分 SLA

RTC (Replication Time Control) は replication_time.status = "Enabled" と metrics.status = "Enabled" の両方を同時に設定することで有効化される。SLA 保証の対象はルール作成後に PUT されたオブジェクトであり、既存オブジェクトは対象外 (Batch Replication で別途対応)。

CloudWatch Metrics — RTC 監視

RTC 有効化後は以下の CloudWatch Metrics が自動出力される。これらを用いてアラームを設定し、SLA 超過を早期検知する。

resource "aws_cloudwatch_metric_alarm" "replication_latency" {
  alarm_name = "s3-crr-replication-latency-high"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 2
  metric_name= "ReplicationLatency"
  namespace  = "AWS/S3"
  period  = 300
  statistic  = "Maximum"
  threshold  = 600
  alarm_description= "S3 CRR replication latency > 10 min — SLA breach risk"
  alarm_actions = [aws_sns_topic.ops_alert.arn]

  dimensions = {
 SourceBucket= aws_s3_bucket.primary.id
 DestinationBucket = aws_s3_bucket.secondary.id
 RuleId= "crr-all-objects-with-rtc"
  }
}

6-6. 3 層 DR 統合設計

3 つのレイヤーは障害スコープに応じて独立して機能するが、Region 障害時は全レイヤーが連動する。

本番運用ガイドライン

Zonal Shift の自動化には EventBridge + Lambda が有効だが、Safety Rule により誤発動による全リージョン停止を防ぐ。Routing Control の切替は必ず 2 エンドポイント (Primary Off → Secondary On) をアトミックに実行し、update-routing-control-states (複数) で 1 API コールにまとめることを推奨する。S3 RTC は新規バケット作成直後の初期オブジェクト群には SLA 適用外のため、移行時は Batch Replication で事前複製した上で RTC を有効化する。

7. DR 訓練・検証 (Runbook + フェイルオーバーテスト + RTO/RPO 実測)

DR設計は「作って終わり」ではない。定期的な訓練と RTO/RPO 実測で達成可能性を継続検証し、改善サイクルを回すことが本番運用の本質だ。

7-1. DR 訓練の3段階マトリクス

7-2. DR Runbook 設計

Runbook は「誰でも深夜3時に実行できる」レベルの具体性が必須だ。

Runbook: リージョン障害対応 (年次訓練用)

Step 1: 障害確認 (目標 5分以内)
  □ CloudWatch Alarms 確認 (ap-northeast-1 の RDS/EC2/ALB ヘルスチェック)
  □ AWS Health Dashboard でリージョン障害公式ステータス確認
  □ Route53 ARC Zonal Shift / Routing Control 状態確認

Step 2: 影響範囲特定 (目標 5分以内)
  □ Aurora Global Database Primary/Secondary ステータス確認
  □ S3 Bucket アクセス可否 (セカンダリリージョン)
  □ アプリ層接続断確認 (ALB Target Health)

Step 3: フェイルオーバー実行 (目標 10分以内)
  □ Aurora Global Database Failover 実行
  □ Route53 ARC Routing Control 更新
  □ AWS Backup からの重要データ復元確認 (必要に応じて)

Step 4: 疎通確認・RTO/RPO 実測 (目標 10分以内)
  □ アプリ接続確認 (セカンダリリージョン)
  □ RTO 実測値記録 (Step 1 開始 → アプリ正常応答まで)
  □ Aurora データ整合性確認 (RPO 実測値記録)

Step 5: ポストモーテム (訓練後 24時間以内)
  □ RTO/RPO 実測値 vs 目標値の差分分析
  □ Runbook 改善点洗い出し
  □ CloudWatch Dashboard への記録

7-3. Terraform: CloudWatch Dashboard (RTO/RPO 実測用)

resource "aws_cloudwatch_dashboard" "dr_metrics" {
  dashboard_name = "DR-Training-Metrics"
  dashboard_body = jsonencode({
 widgets = [
{
  type = "metric"
  properties = {
 title= "Aurora Global DB Replication Lag (ms)"
 metrics = [["AWS/RDS", "AuroraGlobalDBReplicationLag",
"DBClusterIdentifier", var.aurora_global_cluster_id]]
 period  = 60
 stat = "Average"
  }
},
{
  type = "metric"
  properties = {
 title= "S3 CRR Replication Latency (s)"
 metrics = [["AWS/S3", "ReplicationLatency",
"SourceBucket", var.primary_bucket,
"DestinationBucket", var.secondary_bucket,
"RuleId", "CRRRule"]]
 period  = 60
 stat = "Maximum"
  }
},
{
  type = "metric"
  properties = {
 title= "AWS Backup Jobs Completed"
 metrics = [["AWS/Backup", "NumberOfBackupJobsCompleted",
"BackupVaultName", var.backup_vault_name]]
 period  = 86400
 stat = "Sum"
  }
}
 ]
  })
}

7-4. RTO/RPO 自動実測スクリプト (boto3 Python)

import boto3, time, datetime

def measure_failover_rto(global_cluster_id: str, secondary_region: str) -> dict:
 rds = boto3.client("rds", region_name=secondary_region)
 cw  = boto3.client("cloudwatch", region_name="ap-northeast-1")

 resp = cw.get_metric_statistics(
  Namespace="AWS/RDS",
  MetricName="AuroraGlobalDBReplicationLag",
  Dimensions=[{"Name": "DBClusterIdentifier", "Value": global_cluster_id}],
  StartTime=datetime.datetime.utcnow() - datetime.timedelta(minutes=5),
  EndTime=datetime.datetime.utcnow(),
  Period=60,
  Statistics=["Average"],
 )
 rpo_ms = resp["Datapoints"][-1]["Average"] if resp["Datapoints"] else 0.0

 t0 = time.time()
 rds.failover_global_cluster(
  GlobalClusterIdentifier=global_cluster_id,
  TargetDbClusterIdentifier=f"arn:aws:rds:{secondary_region}:123456789012:cluster:secondary",
 )
 while True:
  clusters = rds.describe_db_clusters()["DBClusters"]
  if any(c.get("IsClusterWriter") for c in clusters):
rto_sec = round(time.time() - t0, 1)
return {"rto_seconds": rto_sec, "rpo_ms": round(rpo_ms), "passed": rto_sec <= 1800}
  time.sleep(10)

7-5. AWS CLI: DR 訓練コマンド集

# 四半期 Switchover 訓練 (計画的・RPO=0)
aws rds switchover-global-cluster \
  --global-cluster-identifier my-global-cluster \
  --target-db-cluster-identifier \
 arn:aws:rds:ap-southeast-1:123456789012:cluster:secondary \
  --region ap-northeast-1

# Switchover 完了確認
aws rds describe-global-clusters \
  --global-cluster-identifier my-global-cluster \
  --query 'GlobalClusters[0].GlobalClusterMembers[*].{Cluster:DBClusterArn,IsWriter:IsWriter}'

# 月次 Backup 復元訓練: 最新 Recovery Point 確認
aws backup list-recovery-points-by-backup-vault \
  --backup-vault-name primary-backup-vault \
  --by-resource-type RDS \
  --query 'RecoveryPoints[0].{ID:RecoveryPointArn,Date:CreationDate,Status:Status}'

# Backup Restore Job 開始 (RTO 計測)
aws backup start-restore-job \
  --recovery-point-arn "<recovery-point-arn>" \
  --iam-role-arn arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole \
  --resource-type RDS \
  --metadata '{"DBInstanceIdentifier":"dr-restore-test","DBSubnetGroupName":"default"}'

7-6. コンソール: DR 訓練チェックポイント

AWS Backup コンソール (訓練前確認):
  1. [Backup jobs] → 最新ジョブが「Completed」であること
  2. [Protected resources] → 対象 RDS/S3 が保護対象に含まれること
  3. [Backup vaults] → Vault Lock が「Locked (Compliance)」であること

RDS コンソール (Switchover/Failover 実行):
  1. [Databases] → グローバルデータベース選択
  2. [Actions] → [Switch over or fail over global database]
  3. 操作種別選択 → 確認ダイアログ入力 → 実行

Route53 ARC コンソール (フェイルオーバー時):
  1. [Application Recovery Controller] → [Routing controls]
  2. Recovery Group 選択 → [Edit routing control states]
  3. セカンダリの Routing Control を [On] に変更 → 確認

7-7. 観測性3部作との連携

• CloudWatch Logs Insights: Backup ジョブログ・Aurora フェイルオーバーイベント分析 (観測性 Vol1)
• X-Ray + ADOT: フェイルオーバー時の分散トレーシング確認 (観測性 Vol2)
• Application Signals SLO: DR 後の SLO Burn Rate 監視 (観測性 Vol3)

7-8. Vol2 Chaos Engineering への接続点

# Vol2 プレビュー: AWS FIS 実験テンプレート
resource "aws_fis_experiment_template" "aurora_failover_chaos" {
  description = "Aurora Global DB Failover Chaos Experiment"
  role_arn = aws_iam_role.fis_role.arn
  stop_conditions {
 source = "aws:cloudwatch:alarm"
 value  = aws_cloudwatch_metric_alarm.error_rate_high.arn
  }
  actions = {
 "failover-aurora" = {
action_id = "aws:rds:failover-db-cluster"
parameters = {}
targets = { Clusters = "target-aurora" }
 }
  }
  tags = var.common_tags
}

8. まとめ + 復旧・運用編 Vol2 予告 + 落とし穴 10 選

本記事では Multi-Region×Multi-AZ DR 設計から AWS Backup Cross-Region/Cross-Account 実装、Aurora Global Database 本番運用、Route53 ARC + S3 CRR 3層 DR、DR 訓練・RTO/RPO 実測まで、リージョン障害対応の全工程を網羅した。§2 で設定した RTO ≤ 30分・RPO ≤ 秒単位の設計目標を、§3〜§7 の実装で達成する具体的な経路を示した。

8-0. DR アーキテクチャ設計 3原則

本記事全体を通じて一貫した3つの設計原則を適用した。

原則1: 多層防衛 (Defense in Depth)
AZ障害 → Zonal Shift で即時対応 (秒単位)、リージョン障害 → Aurora GDB Failover + Routing Control で分単位対応、データ損失 → S3 CRR RTC で15分SLA保証という3層の障害対応ラインを構築する。単一の対策ではカバーできない障害シナリオを多層で補完する。

原則2: RPO/RTO の明示的 SLA 管理
DR設計はビジネス要件 (サービス停止が許容される時間・データ損失が許容される量) から逆算する。Aurora GDB のレプリケーション lag を常時 CloudWatch で監視し、実測値が SLA を超過する前に対策を講じる。RPO/RTO は設計値ではなく「訓練での実測値」で管理する。

原則3: Runbook First (コードと運用手順の同期)
Terraform でインフラをコード化するだけでなく、§7 の Runbook と boto3 実測スクリプトをリポジトリで管理し、インフラ変更時に必ず Runbook を更新する。設計と運用手順の乖離が DR失敗の最大の原因である。

8-1. チートシート: DR 設計判断早見表

8-2. 落とし穴 10 選 + 対策

1. Vault Lock Compliance Mode は不可逆: 設定後 72時間の Cooling Off 中のみ解除可能。必ず Governance Mode でテスト後に適用。

2. 対策: changeable_for_days = 3 で 72時間ウィンドウを確保。本番適用前に DR リージョンの Vault で動作確認を完了させること。

3. Aurora GDB Failover は RPO ≠ 0: 計画外 Failover では replication lag 分のデータロスが発生。RPO=0 が必要な場合は Switchover を使うこと。

4. 対策: CloudWatch メトリクス AuroraGlobalDBReplicationLag を常時監視し、lag が 1秒超過でアラートを設定。RPO SLA に応じて Failover 許容 lag を明文化。

5. ARC Zonal Shift は期限切れに注意: expires-in 最大 3日間。期限切れで自動解除。恒久切替には Routing Control を使用。

6. 対策: aws arc-zonal-shift list-zonal-shifts で定期的に有効期限を確認。EventBridge で期限切れアラートを自動通知。

7. S3 CRR は既存オブジェクトを複製しない: ルール設定後の新規アップロードのみ対象。既存データは aws s3 sync で手動コピーが必要。

8. 対策: CRR 設定後すぐに aws s3 sync s3://source-bucket s3://dest-bucket --metadata-directive COPY で既存オブジェクトを手動同期。完了を S3 Inventory で検証。

9. Cross-Account Backup は RAM 共有が必要: ソース Vault が DR アカウントから見えるよう Resource Access Manager で共有設定を行うこと。

10. 対策: Organizations で RAM 共有を有効化 (aws ram enable-sharing-with-aws-organization) し、Backup Vault ポリシーで DR アカウントの ARN を明示的に許可。

11. Aurora GDB Failover 後は旧 Primary の手動再追加が必要: 自動的にセカンダリとして復帰しない。グローバルクラスターへの手動再追加が必要。

12. 対策: DR Runbook に aws rds modify-global-cluster での旧 Primary 再追加手順を明記。Failover 後 RTO 計算に再追加時間 (通常 5〜10分) を含めること。

13. Route53 ARC Cluster エンドポイントは 5 リージョン分散: Routing Control の更新は ARC クラスターのエンドポイントに対して行う。通常の Route53 エンドポイントでは不可。

14. 対策: aws route53-recovery-cluster list-routing-controls で正しいエンドポイントを取得。Runbook に ARC クラスターエンドポイントを静的に記載しておく。

15. S3 RTC はバージョニング必須: Replication Time Control 有効化前に送信元/送信先双方でバージョニングを有効化する。

16. 対策: Terraform で aws_s3_bucket_versioning を aws_s3_bucket_replication_configuration より先に depends_on で定義。バージョニング未有効状態で RTC 設定を試みても API エラーになる。

17. S3 Object Lock は Cross-Region Copy でも引き継がれる: DR リージョンの Vault ポリシーとの整合性を確認する。

18. 対策: DR バケットでも Object Lock を有効化し、保持期間を統一。Compliance Mode でロックされたオブジェクトは DR 側でも削除不可のため、コスト計画に含める。

19. DR 訓練未実施の設計は紙の上のフィクション: 本番フェイルオーバー速度は訓練なしで保証不可能。年次フル DR 訓練を必ず実施し Runbook を実地検証すること。

    • 対策: §7 の boto3 実測スクリプトを CI/CD パイプラインに組み込み、四半期ごとに自動で RTO/RPO 実測値を記録。SLA 超過時はアラートで即時通知。

8-3. DR コスト試算ガイド

Multi-Region DR の主なコスト要因と試算目安を示す。

コスト削減の優先度: ①セカンダリ Aurora を Serverless v2 (min ACU=0.5) に変更 → ②Backup の Cold Storage 移行ルール設定 → ③S3 Intelligent-Tiering で RTC 対象外オブジェクトを自動最適化。

DR コスト正当化の考え方: 月額 $250〜$900 の DR 維持コストに対し、リージョン障害1時間あたりの売上損失と比較する。売上損失が月額 DR コストを上回れば投資対効果はプラスになる。また AWS Backup の Vault Lock や Cross-Account Copy は内部コンプライアンス・金融規制対応のコストとしても算定でき、保険料と同等の視点で経営層に提示するとよい。

SLA 別コスト設計の指針:
– RTO ≤ 1時間 / RPO ≤ 1時間: Backup & Restore のみ → 月額 $20〜$50 程度 (最低コスト)
– RTO ≤ 30分 / RPO ≤ 秒単位: 本記事の Warm Standby + Aurora GDB 構成 → 月額 $250〜$900
– RTO ≤ 数分 / RPO ≈ 0: Multi-Site Active/Active → 月額 $1,000+ (Vol4 で解説予定)

8-4. 12巻 AWS 本番運用シリーズ全体マップ

8-5. 関連記事クロスリンク

• Aurora DR + AWS Backup 完全ガイド (単一 Region DR) — 本記事の発展元。§5 で Aurora Global Database として回収。
• CloudWatch Logs Insights + Metrics Filter (観測性 Vol1) — §7 Backup ジョブログ分析
• X-Ray + ADOT 本番運用 (観測性 Vol2) — §7 DR 後の分散トレーシング
• Application Signals + SLO (観測性 Vol3) — §7 SLO Burn Rate 監視
• GuardDuty + Security Hub (セキュリティ Vol1) — §4 Backup Vault 異常アクセス検知
• IAM Identity Center + ABAC (セキュリティ Vol2) — §4 Cross-Account Permission Sets
• AWS Config + Conformance Pack (セキュリティ Vol3) — §4 Backup Vault Lock 継続準拠

本記事が Multi-Region DR の設計・実装・運用サイクルを確立する一助となれば幸いだ。DR は「障害が起きたときに機能する」ことが全てである。本記事の Terraform コード・AWS CLI コマンド・Runbook を実環境で試し、§7 の boto3 スクリプトで RTO/RPO を実測することを強く推奨する。訓練で積み上げた実績だけが、本番障害時の信頼を生む。

← 前を読む: Aurora × AWS Backup DR 演習完全ガイド (単一 Region 編)