AWS Multi-Region Active-Active Active-Passive Route53 ARC 完結

1. この記事について — 復旧・運用編シリーズ Vol4 完結巻

1-1. Multi-Region 設計の北極星 — 「DR 階層 4 段階踏破」を完成させる

AWS が定義する DR 戦略には 4 つのアーキタイプがあります。コストが低い順に Backup・Restore、Pilot Light、Warm Standby、そして Multi-Site の 4 段階です。それぞれの RTO・RPO・コスト特性を整理すると次の表になります。

復旧・運用編シリーズは、この 4 段階のロードマップを実装レベルで踏破することを目的として設計されました。

Vol1 — Warm Standby から Multi-Site への橋渡しを実装

Vol1 では Aurora Global Database と AWS Backup Cross-Region Replication を使い、Warm Standby クラスから Multi-Site への移行をリードする構成を本番環境で実装しました。Aurora Global Database の Secondary Cluster を別リージョンに常時起動し、Route53 Failover Routing で切替えるまでの全工程を Terraform で IaC 化しました。RTO の目標値を実測で確認するまでの一連の手順と、発生した落とし穴の対処もすべて記録しています。

Vol2 — 障害シナリオを機械化し「壊して直す」サイクルを CI に組み込む

Vol2 では AWS Fault Injection Service (FIS) を使い、Vol1 で構築した DR 構成を機械的に壊して検証しました。人手で実施していた障害訓練を FIS Experiment Template で自動化し、Terraform で管理することで「壊して直す」サイクルを CI パイプラインに組み込める状態にしました。同じ FIS テンプレートを本 Vol4 の §7 で Active-Active・Active-Passive の両構成に流用します。

Vol3 — インシデント全工程を SSM Automation Runbook で自動化

Vol3 では Systems Manager Automation Document を Terraform で IaC 化し、インシデント発生から ARC Routing Control の切替・Aurora Global Database の Switchover・通知送信までの全工程を自動 Runbook に落とし込みました。この Runbook は本 Vol4 の §7 で Multi-Region 構成の自動切替に直接拡張します。

Vol4 (本記事) — DR 階層 4 段階踏破の完成

本 Vol4 はその集大成です。Vol1 で構築した Aurora Global Database をそのまま Active-Passive 設計の中核に継承し、Route53 Application Recovery Controller (ARC) の Routing Control を追加することで完全自動フェイルオーバーを実現します。さらに Active-Active 設計では Global Accelerator と DynamoDB Global Tables を組み合わせ、2 つのリージョンが同時に稼働するトラフィック分散構成を Terraform で実装します。Vol2 の FIS テンプレートで両構成を実機検証し、Vol3 の SSM Automation Runbook で自動切替まで統合します。

「Backup から始まり Multi-Site Active-Active に到達する」という DR 階層 4 段階踏破が、本 Vol4 の公開によって完成します。

1-2. 読者像と前提条件

本記事は次の 3 つの読者層を主な対象として想定しています。

復旧・運用編シリーズ既読のエンジニア

Vol1 で Aurora Global Database と AWS Backup を構築済み、Vol3 で SSM Automation Runbook を IaC 化済みの方が最も多くを活用できます。§4 の Active-Passive 設計では Vol1 の構成をそのまま継承して ARC と接続します。§7 では Vol2 の FIS Experiment Template と Vol3 の SSM Automation Document を本記事の Multi-Region 構成と統合する end-to-end シナリオを実装します。

Multi-Region 移行を検討中のアーキテクト

現在 Single-Region で運用中のシステムを Multi-Region 化する際に「Active-Active と Active-Passive のどちらから始めるか」の判断基準を持ちたい方。§2 の 5 次元定量比較マトリクスは、RTO・RPO・月額コスト・運用負荷・データ整合性の 5 軸で自社の条件に合ったパターンを選べる意思決定ツールとして設計しています。

リージョン障害を経験したエンジニア

過去に AWS リージョン障害やアベイラビリティゾーン障害を経験し、次回は自動切替できる構成にしたいと考えている方。§3 の Route53 ARC Routing Control と §7 の統合検証が最もすぐに使える実装例です。Safety Rules による誤切替防止と Readiness Check による切替可否の自動判定が、本番環境での安全な自動フェイルオーバーを実現します。

本記事を読み進めるにあたり、以下の前提知識と環境を想定しています。

• Terraform v1.5 以上の基本操作 (state 管理および workspace の使い方)
• AWS CLI v2 の設定済み環境 (ap-northeast-1 と us-east-1 の 2 リージョンへの操作権限)
• Route53 ホストゾーンの管理経験
• Aurora PostgreSQL または Aurora MySQL の基本的な運用知識
• DynamoDB の基本的なテーブル設計知識 (§5 で一から解説するため任意)

DynamoDB Global Tables や Global Accelerator の経験がなくても、§5 と §3 の Terraform コードと AWS CLI コマンドを順番に実行することで構築できるよう設計しています。

Route53 ARC は比較的新しいサービス (2021 年リリース) であり、ARC コンソールの操作を行った経験がない方がほとんどです。§3 では初回利用者を前提に Cluster 作成から Routing Control の状態更新まで丁寧に解説しています。

Global Accelerator は anycast IP を使ってリクエストを最近傍のリージョンへルーティングします。Route53 の Latency-Based Routing との使い分けについては §5 冒頭で比較表を示します。

1-3. 12 巻完結シリーズと復旧・運用編 4 巻の集大成

本シリーズ全体は Lambda・EKS・観測性・セキュリティ・復旧運用の 5 テーマ・全 14 リソースで構成されています。

これら 14 リソースは本記事と以下の形で連携します。

• §3 では「ARC 操作の IAM 最小権限設計」としてセキュリティ Vol2 (IAM Identity Center) との連携を扱います。ARC の Routing Control 更新や Readiness Check 参照に必要な IAM ポリシーを Identity Center の Permission Set として管理する方法を実装します。
• §5 では「Cross-Region 分散トレーシングで Active-Active の latency を最適化する」として観測性 Vol2 (X-Ray と ADOT) との連携を扱います。2 リージョンにまたがるリクエストのトレースを X-Ray で可視化し、Global Accelerator の Endpoint Group を調整する判断根拠にします。
• §6 では「DynamoDB Streams と Lambda による Conflict Resolution 後処理」として Lambda シリーズとの連携を扱います。LWW で解決できない複合キー更新などの後処理を Lambda Function で実装する構成を Terraform で示します。
• §7 では Vol2 の FIS Experiment Template と Vol3 の SSM Automation Document を本記事の Multi-Region 構成と直接統合します。

これらの連携により、本記事は復旧・運用編の完結巻として機能すると同時に、シリーズ 14 リソース全体の統合ポイントとなります。

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

本記事の §2 から §8 は独立して参照できる構成にしています。目的別の推奨読了順を以下に示します。

A-A か A-P かを今すぐ決めたい方 → §2 → §8

§2 の 5 次元定量比較マトリクスで自社の条件を評価し、§8 の選定フローチャートで結論を確認する流れです。実装は後回しにして意思決定だけ先に済ませたい場合に適しています。

Active-Passive から始めたい方 → §3 → §4

§3 で Route53 ARC のコンポーネントを理解してから §4 の Active-Passive 設計実装に入る流れです。Vol1 で Aurora Global Database を構築済みの方はそのまま §4 の Terraform コードに進めます。

Active-Active から始めたい方 → §3 → §5 → §6

§3 で ARC を理解してから §5 の Global Accelerator・DynamoDB Global Tables の設計に入り、§6 でデータ整合性層を確認する流れです。§6 では Aurora write forwarding・DynamoDB LWW・S3 CRR の 3 データストアを比較します。

シリーズ全体の統合検証をしたい方 → §7 → §3 → §4 または §5

§7 から逆引きして Vol2 FIS と Vol3 SSM Automation の統合シナリオ全体を把握してから、個別の実装節を参照する方法です。end-to-end の全体像を先に把握したい方に適しています。

コストを抑えて動作確認をする場合は、Aurora Global Database (月額数十ドル規模) の代わりに ARC 単体の動作確認から始める方法があります。ARC Cluster・Control Panel・Routing Control の月額は Cluster あたり約 2.5 ドル、Routing Control あたり約 1 ドルと比較的低コストです。本番移行前の検証環境として §3 の構成だけを先に構築し、§4 または §5 へ段階的に拡張する方針が最もコスト効率の高い進め方です。

なお、本記事全体を通じて使用する Terraform コードは ap-northeast-1 をプライマリリージョン、us-east-1 をセカンダリリージョンとして記述しています。別リージョンを使用する場合はリージョン名を置き換えてください。Aurora Global Database の作成は ap-northeast-1、Global Accelerator のエンドポイントグループは両リージョンに配置する構成を採用しています。

2. A-A vs A-P 5 次元定量比較マトリクス

2-1. 5 次元の定義と測定方法

Multi-Region 設計を選定する際、技術的可否だけでなく「5 つの次元でどの数値を受け入れられるか」を事前に定義することが判断の出発点です。

RTO (Recovery Time Objective)

障害発生から業務再開までの目標時間です。「サービスが停止してから何分以内に再開できれば合格か」を SLA として定義します。Route53 ARC Routing Control の切替時間 (30 秒〜2 分) と Aurora Global Database Switchover 時間 (1〜5 分) の合計が Active-Passive の現実的な RTO フロアです。

RPO (Recovery Point Objective)

障害発生時に許容できるデータ損失の目標時間です。Aurora Global Database の Managed Planned Switchover は同期レプリケーション完了後に切替えるため RPO ≈ 0 を保証します。DynamoDB Global Tables は LWW (Last Writer Wins) による非同期レプリケーションのため、数秒の書き込み競合が発生しえます。

月額コスト

スタンバイリージョンの常時稼働費・Cross-Region データ転送料・ARC および Global Accelerator の固定費が主な追加コストです。セカンダリリージョンを最小構成で維持する Warm Standby 方式と、全トラフィックを受け付ける Active-Active では 1.5〜3 倍のコスト差が生じます。

運用負荷

フェイルオーバー手順の整備・定期訓練・監視設定・スキル習得のコストです。Active-Active は Conflict Resolution の運用ルールと LWW 監視が追加で必要になります。Active-Passive は Runbook 整備と定期的な切替訓練が中心です。

データ整合性

フェイルオーバー後にデータが一貫しているかの保証レベルです。Strong consistency (RPO = 0) が必要なワークロードは Aurora Global Database を中核とした Active-Passive が唯一の選択肢です。

2-2. 4 アーキタイプと A-A vs A-P の 5 次元定量比較

2-3. Active-Active 構成の 5 次元評価

Active-Active 構成は 2 リージョンが同時に本番トラフィックを受け付けるため、RTO は事実上ゼロです。片方のリージョン障害でも残りのリージョンが全トラフィックを処理するため「フェイルオーバー」という概念がなくなります。

RTO・RPO の強み

Global Accelerator の BGP anycast は障害リージョンへのルーティングを約 30 秒以内に切替えます。アプリケーション層は常時稼働しているため起動待ちが発生しません。DynamoDB Global Tables の典型的なレプリケーションラグは 1 秒未満であり、実用上 RPO ≈ 0 に近い値を実現します。

データ整合性の課題

Active-Active が最も複雑なのはデータ整合性です。2 リージョンが同じレコードをほぼ同時に更新した場合、LWW ではタイムスタンプが古い側の更新が上書き消去されます (サイレントロスト・ライト)。この問題を防ぐにはアプリケーション層での競合検知か、DynamoDB Streams と Lambda を組み合わせた後処理 Conflict Resolution が必要です (§6 参照)。

Aurora Global Database write forwarding は DML のみ対応で DDL は Secondary リージョンから直接実行できません。また replica_read_consistency のデフォルト値 eventual では Secondary からの読み取りが Primary に反映される前の古い値を返す可能性があります。session または global への変更が必要かを §6 で確認してください。

採用基準

Active-Active が適するのは「任意のリージョン障害でも SLA を維持する必要があり、結果整合性をアプリ層で許容できる設計になっている場合」です。読み取りが書き込みの 10 倍以上のワークロード、EC サイト、コンテンツ配信、SNS のようなユースケースで効果を最大化します。

2-4. 選定指針 — SLA・予算・データ整合性要件別

RTO 5 分以内を要求される場合

Multi-Site (A-P か A-A) の 2 択です。A-P は月額 +$360〜1,010 で RTO 1〜5 分、A-A は月額 +$470〜1,620 でフェイルオーバー不要です。まず §3 の ARC を構築して実測 RTO を確認し、SLA を満たすかを判断した上で A-P を選択するか A-A に進むかを決定することを推奨します。

月額追加コスト $500 以内の場合

Pilot Light か Warm Standby が現実的です。RTO 15 分以内を許容できるなら Warm Standby + Aurora Global Database (Secondary を最小インスタンス) で $400〜600 に収まります。RTO 1 時間以内でよければ Pilot Light で $100〜300 に抑えられます。

RPO = 0 が絶対要件の場合

Active-Passive + Aurora Global Database Managed Planned Switchover の組み合わせが唯一の選択肢です。DynamoDB Global Tables の LWW は数秒の損失リスクを排除できないため、金融トランザクションや医療記録のような「1 件も失えない」データには不適です。Aurora GD を中核に設計し、高速読み取り専用データを DynamoDB で補完する構成を選択してください。

3. Route53 Application Recovery Controller の 5 要素

3-1. ARC アーキテクチャ全体像と Multi-Region 統制原則

Route53 Application Recovery Controller (ARC) は 2021 年にリリースされた AWS のフェイルオーバー制御サービスです。従来の Route53 Failover Routing が「ヘルスチェック不合格 → DNS TTL 経過後に自動切替」という受動的な動作だったのに対し、ARC は「Routing Control の状態を明示的に On・Off することで DNS を能動的に制御する」設計になっています。

ARC は 5 つのコンポーネントで構成されます。

Cluster

ARC のコントロールプレーンそのものです。5 つの AWS リージョンにまたがる高可用性クラスタとして自動構成され、1 つのリージョンが障害でも残り 4 つで Routing Control の更新を受け付けます。Cluster を作成すると 5 つのエンドポイント URL が払い出され、フェイルオーバー時はそのうちの任意の 1 つに対して update-routing-control-state を実行します。

Control Panel

Routing Control をグループ化する論理コンテナです。1 Cluster に複数の Control Panel を作成でき、サービス単位・環境単位 (本番とステージング) に分離管理できます。デフォルトで作成される Default Control Panel は変更・削除できません。

Routing Control

Route53 Health Check と紐付けられたトグルスイッチです。状態が On のとき Route53 Health Check が Healthy を返し、Off のとき Unhealthy を返します。この Health Check を Route53 Failover Routing または Weighted Routing のエイリアスレコードに設定することで、Routing Control の状態が DNS 解決結果に直結します。

Readiness Check

フェイルオーバー先のリージョンが本番トラフィックを受け入れられる状態か否かをリアルタイムに監視します。Aurora Global Database の Secondary Cluster キャパシティ、ALB Target Group のヘルシーホスト数、AutoScaling Group の希望容量などを監視対象として登録できます。

Safety Rules

Routing Control の状態変更に対するガードレールです。「Primary と Secondary のどちらか必ず 1 つは On でなければならない (Asserted Control ルール)」「同時に両方を Off にすることは禁止」といった条件を Terraform で設定します。Safety Rules が設定されていると、違反する Routing Control 操作は ARC API 側で拒否されます。

月額コスト: Cluster $2.5・Routing Control $1/本です。4 本 (Primary On・Off・Secondary On・Off) で月額約 $6.5 が ARC の最小構成コストです。

3-2. Cluster と Control Panel の Terraform 実装

# ARC Cluster 作成 (us-west-2 がホームリージョン)
resource "aws_route53recoverycontrol_cluster" "main" {
  provider = aws.us-west-2
  name  = "multi-region-failover-cluster"
}

# Control Panel 作成
resource "aws_route53recoverycontrol_control_panel" "main" {
  provider = aws.us-west-2
  name  = "production-control-panel"
  cluster_arn = aws_route53recoverycontrol_cluster.main.arn
}

# Primary リージョン (ap-northeast-1) 用 Routing Control
resource "aws_route53recoverycontrol_routing_control" "primary" {
  provider = aws.us-west-2
  name  = "primary-routing-control"
  cluster_arn = aws_route53recoverycontrol_cluster.main.arn
  control_panel_arn = aws_route53recoverycontrol_control_panel.main.arn
}

# Secondary リージョン (us-east-1) 用 Routing Control
resource "aws_route53recoverycontrol_routing_control" "secondary" {
  provider = aws.us-west-2
  name  = "secondary-routing-control"
  cluster_arn = aws_route53recoverycontrol_cluster.main.arn
  control_panel_arn = aws_route53recoverycontrol_control_panel.main.arn
}

# Routing Control と紐付ける Route53 Health Check (Primary)
resource "aws_route53_health_check" "primary_arc" {
  routing_control_arn = aws_route53recoverycontrol_routing_control.primary.arn
  type = "RECOVERY_CONTROL"
}

# Routing Control と紐付ける Route53 Health Check (Secondary)
resource "aws_route53_health_check" "secondary_arc" {
  routing_control_arn = aws_route53recoverycontrol_routing_control.secondary.arn
  type = "RECOVERY_CONTROL"
}

ARC リソースは us-west-2 (オレゴン) に作成する必要があります。Cluster のエンドポイントは Cluster 作成後に aws_route53recoverycontrol_cluster.main.cluster_endpoints で取得できます。

3-3. Routing Control と Safety Rules

Safety Rules を設定しない場合、誤操作で Primary と Secondary を同時に Off にしてサービス全断を引き起こす可能性があります。ASSERTION ルール (最低 N 個は On) と GATING ルール (Gate Control が On のときのみ変更許可) の 2 種類があります。

# ASSERTION ルール: Primary と Secondary の少なくとも 1 つは常に On
resource "aws_route53recoverycontrol_safety_rule" "min_one_on" {
  provider = aws.us-west-2
  name  = "min-one-routing-control-on"
  control_panel_arn = aws_route53recoverycontrol_control_panel.main.arn

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

  asserted_controls = [
 aws_route53recoverycontrol_routing_control.primary.arn,
 aws_route53recoverycontrol_routing_control.secondary.arn,
  ]

  wait_period_ms = 5000
}

# GATING ルール: メンテナンスフラグが Off のときのみ切替許可
resource "aws_route53recoverycontrol_routing_control" "maintenance_gate" {
  provider = aws.us-west-2
  name  = "maintenance-gate-control"
  cluster_arn = aws_route53recoverycontrol_cluster.main.arn
  control_panel_arn = aws_route53recoverycontrol_control_panel.main.arn
}

resource "aws_route53recoverycontrol_safety_rule" "gating_rule" {
  provider = aws.us-west-2
  name  = "maintenance-gating-rule"
  control_panel_arn = aws_route53recoverycontrol_control_panel.main.arn

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

  gating_controls = [
 aws_route53recoverycontrol_routing_control.maintenance_gate.arn,
  ]

  target_controls = [
 aws_route53recoverycontrol_routing_control.primary.arn,
 aws_route53recoverycontrol_routing_control.secondary.arn,
  ]

  wait_period_ms = 0
}

wait_period_ms は Safety Rule 評価後の待機時間です。5000 (5 秒) を設定すると、状態変更リクエストが受理されてから 5 秒後に Route53 Health Check に反映されます。本番では誤切替防止のため 5,000〜30,000 ms を推奨します。

Routing Control の状態更新は Cluster エンドポイント経由で行います。通常の Route53 API エンドポイントとは別のエンドポイントを使用する点に注意してください。

3-4. Readiness Check と Recovery Group

Readiness Check は「フェイルオーバー先が本当に準備できているか」を継続的に監視し、NOT_READY な状態でのフェイルオーバーを防止します。Aurora Global Database の Secondary Cluster キャパシティ、ALB Target Group のヘルシーホスト数、AutoScaling Group の希望容量などを監視対象に登録できます。

# Recovery Group (複数の Cell を束ねる最上位グループ)
resource "aws_route53recoveryreadiness_recovery_group" "main" {
  recovery_group_name = "multi-region-recovery-group"
  cells = [
 aws_route53recoveryreadiness_cell.primary.arn,
 aws_route53recoveryreadiness_cell.secondary.arn,
  ]
}

# Primary リージョンの Cell
resource "aws_route53recoveryreadiness_cell" "primary" {
  cell_name = "primary-cell-ap-northeast-1"
}

# Secondary リージョンの Cell
resource "aws_route53recoveryreadiness_cell" "secondary" {
  cell_name = "secondary-cell-us-east-1"
}

# Aurora Global Database Secondary Cluster の Readiness 監視
resource "aws_route53recoveryreadiness_resource_set" "aurora" {
  resource_set_name = "aurora-global-db-resource-set"
  resource_set_type = "AWS::RDS::DBCluster"

  resources {
 resource_arn = "arn:aws:rds:us-east-1:${var.account_id}:cluster:${var.secondary_cluster_id}"
 readiness_scopes= [aws_route53recoveryreadiness_cell.secondary.arn]
  }
}

# Readiness Check (resource_set を実際に監視するリソース)
resource "aws_route53recoveryreadiness_readiness_check" "aurora" {
  readiness_check_name = "aurora-secondary-readiness"
  resource_set_name = aws_route53recoveryreadiness_resource_set.aurora.resource_set_name
}

# ALB の Readiness 監視
resource "aws_route53recoveryreadiness_resource_set" "alb" {
  resource_set_name = "alb-target-group-resource-set"
  resource_set_type = "AWS::ElasticLoadBalancingV2::LoadBalancer"

  resources {
 resource_arn  = aws_lb.secondary.arn
 readiness_scopes = [aws_route53recoveryreadiness_cell.secondary.arn]
  }
}

resource "aws_route53recoveryreadiness_readiness_check" "alb" {
  readiness_check_name = "alb-secondary-readiness"
  resource_set_name = aws_route53recoveryreadiness_resource_set.alb.resource_set_name
}

Readiness Check は約 30 秒ごとに対象リソースのステータスを評価します。READY は「フェイルオーバーしても問題ない」、NOT_READY は「切替先のリソースが不足している」を意味します。フェイルオーバー前に get-readiness-check-status で NOT_READY のリソースを確認する運用フローを §7 の SSM Automation Document に組み込んでいます。

3-5. ARC 操作 IAM 設計と Identity Center 連携

ARC の Routing Control 操作は通常の AWS API 操作とは独立した権限体系を持ちます。Cluster エンドポイントへの操作に必要なアクションは route53-recovery-cluster:* で、コントロールプレーン操作は route53-recovery-control-config:* です。

フェイルオーバー権限を持つ IAM ロールは最小権限で設計し、IAM Identity Center の Permission Set として管理することを推奨します。オンコール担当者が「ARC Routing Control の更新のみ」を実行できる最小権限 Permission Set を作成し、AWS Config Conformance Pack でその設定ドリフトを継続検知する構成が本番環境のベストプラクティスです。

# ARC 操作用 IAM ポリシー (最小権限)
resource "aws_iam_policy" "arc_operator" {
  name = "arc-routing-control-operator-policy"

  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [
{
  Sid = "ARCRoutingControlUpdate"
  Effect = "Allow"
  Action = [
 "route53-recovery-cluster:GetRoutingControlState",
 "route53-recovery-cluster:UpdateRoutingControlState",
 "route53-recovery-cluster:UpdateRoutingControlStates",
 "route53-recovery-cluster:ListRoutingControls"
  ]
  Resource = "*"
},
{
  Sid = "ARCReadinessRead"
  Effect = "Allow"
  Action = [
 "route53-recovery-readiness:GetReadinessCheckStatus",
 "route53-recovery-readiness:GetRecoveryGroupReadinessSummary",
 "route53-recovery-readiness:ListReadinessChecks"
  ]
  Resource = "*"
},
{
  Sid = "ARCControlConfigRead"
  Effect = "Allow"
  Action = [
 "route53-recovery-control-config:DescribeCluster",
 "route53-recovery-control-config:DescribeControlPanel",
 "route53-recovery-control-config:DescribeRoutingControl",
 "route53-recovery-control-config:ListRoutingControls"
  ]
  Resource = "*"
}
 ]
  })
}

UpdateRoutingControlState (単体更新) と UpdateRoutingControlStates (複数一括更新) は別々のアクションです。後者は Primary Off と Secondary On を原子的に更新してトランザクション欠落を防ぐ場合に必要です。SSM Automation Document から ARC を操作する §7 の Runbook でも、この原子的更新 API を使用しています。

3-6. 3 点セット — Terraform、AWS CLI、コンソール

Terraform — 主要リソース対応表

AWS CLI — ARC 操作コマンド

# Cluster エンドポイント確認
CLUSTER_ENDPOINT=$(aws route53-recovery-control-config describe-cluster \
  --cluster-arn "$CLUSTER_ARN" \
  --query "Cluster.ClusterEndpoints[0].Endpoint" --output text)

# Routing Control 状態確認 (Cluster エンドポイント経由)
aws route53-recovery-cluster get-routing-control-state \
  --routing-control-arn "$PRIMARY_RC_ARN" \
  --endpoint-url "https://${CLUSTER_ENDPOINT}"

# Primary → Secondary フェイルオーバー (原子的更新)
aws route53-recovery-cluster update-routing-control-states \
  --endpoint-url "https://${CLUSTER_ENDPOINT}" \
  --update-routing-control-state-entries \
 "[{\"RoutingControlArn\":\"$PRIMARY_RC_ARN\",\"RoutingControlState\":\"Off\"},{\"RoutingControlArn\":\"$SECONDARY_RC_ARN\",\"RoutingControlState\":\"On\"}]"

# Readiness Check ステータス確認
aws route53-recovery-readiness get-readiness-check-status \
  --readiness-check-name "aurora-secondary-readiness" \
  --query "Summary.{Readiness:Readiness}"

# Recovery Group 全体の準備完了確認
aws route53-recovery-readiness get-recovery-group-readiness-summary \
  --recovery-group-name "multi-region-recovery-group"

コンソール操作手順 — フェイルオーバー実行

1. AWS マネジメントコンソール → [Route53] → [Application Recovery Controller] を開く
2. 左メニュー [Routing controls] → 対象の Control Panel を選択
3. Primary の Routing Control を選択 → [Change routing control states]
4. Primary を Off、Secondary を On に設定し [Confirm] → Safety Rules の確認画面が表示される
5. Safety Rules が全て PASS であることを確認し [Submit] で状態変更を確定
6. [Readiness checks] → Recovery Group の全 Cell が READY になっていることをフェイルオーバー前後で確認

コンソールからの操作は Safety Rules の PASS・FAIL をリアルタイムに表示するため、初回フェイルオーバー訓練時はコンソールから実施し、その後 §7 の SSM Automation に移行する手順を推奨します。

4. Active-Passive 設計実装 (Vol1 DR 発展型 + Aurora Global Database Switchover)

Active-Passive 設計は、プライマリリージョンが障害を検知した瞬間にセカンダリリージョンへトラフィックを切り替え、RPO=0・RTO 数十秒を実現するアーキテクチャです。この節では、Vol1 (Multi-Region Backup と DR 本番実践) で構築した Aurora Global Database 構成を中核として継承しつつ、Route53 ARC の Routing Control と Readiness Check を組み合わせた完全自動フェイルオーバーを Terraform で実装します。

4-1. Vol1 構成を A-P 中核として継承する設計

Vol1 では Aurora Global Database の Secondary Cluster を ap-northeast-1 (東京)・us-east-1 (バージニア) の 2 リージョンに展開し、Route53 Failover Routing で切り替えるまでの基本構成を Terraform で IaC 化しました。本 Vol4 の §4 はこの構成をそのまま受け継ぎ、3 点の拡張を加えることで「完全自動フェイルオーバー」に昇格させます。

拡張点 1 — ARC Routing Control によるフェイルオーバー制御の一元化

Vol1 では Route53 Health Check の自動 DNS 切替に頼っていましたが、ARC の Routing Control を経由することで「Safety Rules に反する不正な切替を防止」しつつ「複数の Route53 レコードをアトミックに切替」できるようになります。プライマリリージョンの ALB と Aurora の両方が健全に移行完了するまでセカンダリ側への切替を保留する Safety Rule を HCL で定義できます。

拡張点 2 — Readiness Check による切替可否の常時検証

Readiness Check は Aurora Global Database の Replication Lag、Route53 Health Check の状態、ALB の Target Health を定期的に収集し、「セカンダリが切替を受け入れられる状態か」を 100% OK・NG で返します。これを CloudWatch メトリクスとして取り込み、SLO Burn Rate Alarm と連携させることで手動判断を排したフェイルオーバーが可能になります。

拡張点 3 — Aurora Global Database Switchover (RPO=0)

Vol1 の Failover は Secondary が Writer に昇格するまで数十秒の書き込み中断が生じる可能性がありましたが、Switchover は Primary から Secondary への役割交換を在線のまま実行するため RPO=0 を保証します。aws rds switchover-global-cluster で開始し、全ノードの Writer 昇格が完了してから Route53 フェイルオーバーレコードが切り替わるシーケンスを Terraform と ARC で制御します。また、Aurora 単一 Region DR 演習 (aurora-backup-restore-dr) で確立した Backup・Restore 手順は、Global Database Switchover 後の旧 Primary 復旧フェーズでそのまま活用できます。

4-2. Aurora Global Database Switchover の Terraform 実装

Aurora Global Database の Terraform リソースは aws_rds_global_cluster と aws_rds_cluster の 2 層構造です。Global Cluster が 2 リージョンをまたぐ論理コンテナとして機能し、各リージョンの aws_rds_cluster が global_cluster_identifier を介して参加します。Secondary Cluster には source_db_cluster_identifier で Primary ARN を指定することでレプリケーションが確立します。

# Global Cluster (論理コンテナ — リージョン非依存)
resource "aws_rds_global_cluster" "main" {
  global_cluster_identifier = "prod-global-cluster"
  engine  = "aurora-postgresql"
  engine_version= "15.4"
  database_name = "appdb"
  deletion_protection = true
}

# Primary Cluster (ap-northeast-1)
resource "aws_rds_cluster" "primary" {
  provider  = aws.primary
  cluster_identifier = "prod-primary"
  engine = aws_rds_global_cluster.main.engine
  engine_version  = aws_rds_global_cluster.main.engine_version
  global_cluster_identifier= aws_rds_global_cluster.main.id
  database_name= "appdb"
  master_username = var.db_master_username
  manage_master_user_password = true
  db_subnet_group_name  = aws_db_subnet_group.primary.name
  vpc_security_group_ids= [aws_security_group.aurora_primary.id]
  backup_retention_period  = 7
  deletion_protection= true
  skip_final_snapshot= false
  final_snapshot_identifier= "prod-primary-final"
}

# Secondary Cluster (us-east-1) — source_db_cluster_identifier で Primary ARN を指定
resource "aws_rds_cluster" "secondary" {
  provider= aws.secondary
  cluster_identifier  = "prod-secondary"
  engine  = aws_rds_global_cluster.main.engine
  engine_version= aws_rds_global_cluster.main.engine_version
  global_cluster_identifier = aws_rds_global_cluster.main.id
  source_db_cluster_identifier = aws_rds_cluster.primary.arn
  db_subnet_group_name= aws_db_subnet_group.secondary.name
  vpc_security_group_ids = [aws_security_group.aurora_secondary.id]
  depends_on = [aws_rds_cluster_instance.primary]
}

4-3. Route53 Failover Routing と ARC 連携

Route53 Failover Routing は Health Check と連携して Primary が不健全になった瞬間に Secondary エンドポイントへ DNS を自動切替します。ARC の Routing Control を組み合わせることで、Safety Rules による誤切替防止と複数レコードのアトミック切替を両立します。type = "RECOVERY_CONTROL" の Health Check を使うと、Routing Control の ON・OFF が直接 DNS フェイルオーバーを制御します。

# Route53 Health Check — Primary ALB の死活監視
resource "aws_route53_health_check" "primary_alb" {
  fqdn  = aws_lb.primary.dns_name
  port  = 443
  type  = "HTTPS"
  resource_path  = "/health"
  failure_threshold = 3
  request_interval  = 10
  tags  = { Name = "primary-alb-health-check" }
}

# Primary フェイルオーバーレコード
resource "aws_route53_record" "primary" {
  zone_id = var.route53_zone_id
  name = "api.example.com"
  type = "A"

  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_alb.id
  set_identifier  = "primary"
}

# Secondary フェイルオーバーレコード
resource "aws_route53_record" "secondary" {
  zone_id = var.route53_zone_id
  name = "api.example.com"
  type = "A"

  failover_routing_policy {
 type = "SECONDARY"
  }

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

  set_identifier = "secondary"
}

# ARC Routing Control と Route53 Health Check を連動
# type=RECOVERY_CONTROL にすることで Routing Control の ON/OFF が DNS フェイルオーバーを制御する
resource "aws_route53_health_check" "arc_primary" {
  type = "RECOVERY_CONTROL"
  routing_control_arn = aws_route53recoverycontrol_routing_control.primary.arn
}

Switchover のシーケンスは次の順序で進行します。まず ARC Readiness Check が Secondary の準備完了 (100% Ready) を確認します。次に Routing Control を Primary=Off・Secondary=On へ切替えると、Route53 Health Check が変化を検知し Primary の Failover レコードを不健全として扱います。その結果 Secondary の DNS レコードが有効になり、同時に Aurora の Switchover で Secondary Cluster が Writer に昇格します。Safety Rules が「Primary・Secondary のうち少なくとも 1 つが ON」を要求するため、切替中に両方 Off になる状態は自動で拒否されます。

4-4. ARC Readiness Check で常時可用性検証

Readiness Check は「セカンダリリージョンが今すぐフェイルオーバーを受け入れられるか」を継続的に評価する仕組みです。Aurora Global Database の Replication Lag が閾値以内か、Secondary ALB の Target Health が 100% か、Routing Control の初期状態が正しいかを 1 分ごとにチェックし、結果を CloudWatch メトリクスへ送信します。

# Recovery Group — 複数リージョンの Readiness を統括
resource "aws_route53recoveryreadiness_recovery_group" "main" {
  recovery_group_name = "prod-recovery-group"
  cells = [
 aws_route53recoveryreadiness_cell.primary.arn,
 aws_route53recoveryreadiness_cell.secondary.arn,
  ]
}

# Cell — リージョン単位の可用性単位
resource "aws_route53recoveryreadiness_cell" "primary" {
  cell_name = "prod-primary-cell"
}

resource "aws_route53recoveryreadiness_cell" "secondary" {
  cell_name = "prod-secondary-cell"
}

# Resource Set — Aurora Global Cluster を Readiness Check 対象に登録
resource "aws_route53recoveryreadiness_resource_set" "aurora_global" {
  resource_set_name = "aurora-global-resource-set"
  resource_set_type = "AWS::RDS::DBCluster"

  resources {
 resource_arn  = aws_rds_cluster.primary.arn
 readiness_scopes = [aws_route53recoveryreadiness_cell.primary.arn]
  }

  resources {
 resource_arn  = aws_rds_cluster.secondary.arn
 readiness_scopes = [aws_route53recoveryreadiness_cell.secondary.arn]
  }
}

# Readiness Check — Resource Set と Recovery Group を紐付け
resource "aws_route53recoveryreadiness_readiness_check" "aurora_global" {
  readiness_check_name = "aurora-global-readiness-check"
  resource_set_name = aws_route53recoveryreadiness_resource_set.aurora_global.resource_set_name
}

Readiness Check の評価結果は CloudWatch メトリクス AWS/Route53RecoveryReadiness/ReadinessCheck/ReadinessStatus で確認できます。Secondary が 100% Ready でない場合はアラームを発報し、フェイルオーバーを自動保留する運用フローと組み合わせることで切替失敗を事前に防止します。Readiness Check は resource_set_type に大文字小文字を厳密に要求します。AWS::RDS::DBCluster の誤記は永続的に 0% を返す原因となるため、aws route53-recovery-readiness get-readiness-check-status で初回デプロイ直後に確認してください。

4-5. RTO・RPO 自動実測と SLO Burn Rate 連携

フェイルオーバーの品質は実測値で継続的に管理します。Aurora Global Database Switchover の完了時間は aws rds describe-global-clusters の GlobalClusterMembers[].IsWriter が Secondary=true に変わるまでの秒数を Lambda で計測し、CloudWatch カスタムメトリクス MultiRegion/AuroraSwitchoverLatency として記録します。Route53 の DNS 伝播時間は Routing Control 切替前後で dig を実行し、Secondary レコードの応答が返るまでの秒数を MultiRegion/DNSSwitchLatency として追加計測します。合計 RTO の目標値は 60 秒以内 (Readiness Check PASS から Routing Control 切替・DNS 伝播・Aurora Writer 昇格完了まで) です。この 60 秒 SLO を aws cloudwatch put-metric-alarm で Burn Rate Alarm に変換し、28 日ウィンドウ内の 99.9% 可用性目標と連動させます。SLO Burn Rate Alarm が発報した場合は Vol3 の SSM Automation Document がエスカレーションフローを自動開始します。

4-6. 落とし穴と運用ノウハウ

落とし穴 1 — Switchover 後に Terraform state と実態がずれる

switchover-global-cluster 完了後、旧 Primary は Secondary として Global Cluster に残りますが、state と実態がずれる場合があります。terraform state rm と terraform import で state を修正し、source_db_cluster_identifier が新 Secondary を指すよう HCL を更新してください。

落とし穴 2 — Readiness Check が永続的に 0% を返す

原因の多くは resource_set_type の大文字小文字ミスか、Resource ARN の Provider エイリアス誤りです。aws route53-recovery-readiness get-readiness-check-status --readiness-check-name <name> でエラーメッセージを確認してください。

落とし穴 3 — ARC Cluster 作成に数分かかり他リソースがタイムアウトする

aws_route53recoverycontrol_cluster は作成完了まで 2〜5 分を要します。初回デプロイ時は terraform apply -parallelism=1 で他リソースとの競合を避けてください。

落とし穴 4 — Safety Rules の AND 条件でフェイルオーバーが永久停止する

Safety Rules の ATLEAST 条件を複数設定すると AND 評価になります。Aurora Lag と ALB Health の両方が OK であることを必須条件にした場合、どちらか一方が Unknown 状態でもフェイルオーバーが停止します。本番前に aws route53-recovery-control-config describe-safety-rule で評価状態を確認してください。

運用ノウハウ — 月次フェイルオーバー演習の自動化

Readiness Check を活用していても、実際の切替を演習しなければ手順が形骸化します。毎月第 3 水曜日のメンテナンスウィンドウに Switchover を実行し、SLO 実測値を更新する月次演習を Vol2 (Chaos Engineering) の FIS Experiment Template と組み合わせて自動化することを推奨します。FIS と ARC Routing Control を連携させることで、障害注入からフェイルオーバーまでの全シーケンスを無人で実行できます。

4-7. 3 点セット — Terraform・AWS CLI・コンソール

Terraform — インフラ定義の管理方針

# Routing Control の ON/OFF は Terraform で直接変更せず ARC API 経由で操作する
# Terraform は Infrastructure 定義 (Cluster、Control Panel、Routing Control リソース) のみ管理する
output "routing_control_arn_primary" {
  value = aws_route53recoverycontrol_routing_control.primary.arn
  description = "Primary Routing Control ARN — ARC CLI での切替に使用"
}

output "arc_cluster_endpoints" {
  value = aws_route53recoverycontrol_cluster.main.cluster_endpoints
  description = "ARC Cluster エンドポイント — update-routing-control-states に指定"
}

AWS CLI — Aurora Switchover とフェイルオーバー操作

# Switchover 開始 (計画切替・RPO=0) — Secondary Cluster ARN を target に指定
aws rds switchover-global-cluster \
  --global-cluster-identifier prod-global-cluster \
  --target-db-cluster-identifier arn:aws:rds:us-east-1:123456789012:cluster:prod-secondary \
  --region ap-northeast-1

# Switchover の進捗確認 — IsWriter=true になるまで繰り返し実行
aws rds describe-global-clusters \
  --global-cluster-identifier prod-global-cluster \
  --query "GlobalClusters[0].GlobalClusterMembers[*].{ARN:DBClusterArn,Writer:IsWriter}"

# 緊急フェイルオーバー (非計画・RPO=数秒) — Primary 障害時の強制切替
aws rds failover-global-cluster \
  --global-cluster-identifier prod-global-cluster \
  --target-db-cluster-identifier arn:aws:rds:us-east-1:123456789012:cluster:prod-secondary

# ARC Routing Control 切替 — ARC Cluster エンドポイントを指定して実行
aws route53-recovery-cluster update-routing-control-states \
  --endpoint-url https://CLUSTER_ENDPOINT \
  --update-routing-control-state-entries \
 "RoutingControlArn=arn:aws:route53-recovery-control::123456789012:controlpanel/xxx/routingcontrol/primary,RoutingControlState=Off" \
 "RoutingControlArn=arn:aws:route53-recovery-control::123456789012:controlpanel/xxx/routingcontrol/secondary,RoutingControlState=On"

# Route53 Failover レコードの状態確認
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{"Name":"api.example.com","Type":"A","SetIdentifier":"primary","Failover":"PRIMARY","HealthCheckId":"<hc-id>","AliasTarget":{"HostedZoneId":"<alb-zone>","DNSName":"<alb-dns>","EvaluateTargetHealth":true}}}]}'

コンソール — RDS Global Cluster と Route53 Failover Routing の設定確認

1. RDS コンソール → 「データベース」→「グローバルデータベース」で Global Cluster の状態を確認。Writer Cluster が想定リージョンにあることを確認してから Switchover を実行する。
2. Route53 コンソール → ホストゾーン → フェイルオーバーレコードの Health Check 状態を確認。PRIMARY レコードが Healthy、SECONDARY レコードが Healthy の両方が表示される状態が正常な待機状態。
3. ARC コンソール → 「Route53 ARC」→「クラスター」→「コントロールパネル」から Routing Control を操作。Safety Rules が青色 (ALLOWED) 表示であることを確認してからフェイルオーバーを実行する。切替後は Safety Rule 条件を再確認し、ロールバック可能な状態かを検証する。
4. CloudWatch コンソール → カスタムメトリクス MultiRegion/AuroraSwitchoverLatency と MultiRegion/DNSSwitchLatency を確認。SLO Burn Rate Alarm の状態が OK であることを確認したうえで切替完了を宣言する。

5. Active-Active 設計実装

5-1. Global Accelerator BGP anycast 設計

Active-Active 構成のトラフィック分散には Global Accelerator の BGP anycast を採用し、最近傍リージョンへリクエストを自動ルーティングします。Route53 Latency-Based Routing との主な違いを整理します。

BGP anycast により世界中のエッジロケーションでリクエストを受け取り、AWS バックボーン経由でリージョンへ転送します。公共インターネット経由のパケットロスや遅延変動を削減でき、RTO < 30 秒が要件の場合は Global Accelerator を選択します。静的 anycast IP により、クライアント側の IP ホワイトリストやファイアウォール設定を変更せずにフェイルオーバーを実現できる点も重要なメリットです。

Health Check 仕様 (2026-05 現行版)

Endpoint Group の Health Check は TCP または HTTP/HTTPS プロトコルで設定します。デフォルト間隔は 30 秒、threshold_count = 3 で 3 回連続失敗時にエンドポイントを切り離します。本番では threshold_count = 3 かつ health_check_interval_seconds = 30 の組み合わせが推奨です。threshold_count = 2 に下げると誤切替リスクが上昇するため、段階的トラフィック移行時のみ使用してください。

resource "aws_globalaccelerator_accelerator" "main" {
  name= "app-global-accelerator"
  ip_address_type = "IPV4"
  enabled= true

  attributes {
 flow_logs_enabled= true
 flow_logs_s3_bucket = aws_s3_bucket.ga_logs.bucket
 flow_logs_s3_prefix = "ga-flow-logs/"
  }
}

resource "aws_globalaccelerator_listener" "main" {
  accelerator_arn = aws_globalaccelerator_accelerator.main.id
  client_affinity = "SOURCE_IP"
  protocol  = "TCP"

  port_range {
 from_port = 443
 to_port= 443
  }
}

resource "aws_globalaccelerator_endpoint_group" "primary" {
  listener_arn= aws_globalaccelerator_listener.main.id
  endpoint_group_region= "ap-northeast-1"
  traffic_dial_percentage = 50
  health_check_path = "/health"
  health_check_port = 443
  health_check_protocol= "HTTPS"
  health_check_interval_seconds = 30
  threshold_count= 3

  endpoint_configuration {
 endpoint_id  = aws_lb.primary.arn
 weight = 128
 client_ip_preservation_enabled = true
  }
}

resource "aws_globalaccelerator_endpoint_group" "secondary" {
  listener_arn= aws_globalaccelerator_listener.main.id
  endpoint_group_region= "us-east-1"
  traffic_dial_percentage = 50
  health_check_path = "/health"
  health_check_port = 443
  health_check_protocol= "HTTPS"
  health_check_interval_seconds = 30
  threshold_count= 3

  endpoint_configuration {
 endpoint_id  = aws_lb.secondary.arn
 weight = 128
 client_ip_preservation_enabled = true
  }
}

traffic_dial_percentage で Endpoint Group へのトラフィック割合を調整できます。Active-Active では 50:50 が基本ですが、カナリアリリースや段階的移行時は 10:90 などの重みづけを活用します。client_ip_preservation_enabled = true を設定すると ALB のアクセスログに実クライアント IP が記録され、セキュリティ Vol1 の GuardDuty 脅威検出と連携して Cross-Region の異常トラフィックを検知できます。

5-2. DynamoDB Global Tables (multi-active) と LWW Conflict Resolution

DynamoDB Global Tables は複数リージョン間でテーブルを multi-active 構成で同期します。どのリージョンへの書き込みも他のリージョンへ非同期レプリケートされ、リージョン障害時にもデータ損失なしで読み書きを継続できます。

Global Tables v2 (2019 年版) では aws_dynamodb_table リソース内に replica ブロックを配置するだけで有効化できます。旧 aws_dynamodb_global_table リソースとは管理方式が異なるため、新規実装では v2 方式を採用してください。

resource "aws_dynamodb_table" "sessions" {
  name = "user-sessions"
  billing_mode  = "PAY_PER_REQUEST"
  hash_key= "session_id"
  stream_enabled= true
  stream_view_type = "NEW_AND_OLD_IMAGES"

  attribute {
 name = "session_id"
 type = "S"
  }

  attribute {
 name = "user_id"
 type = "S"
  }

  global_secondary_index {
 name= "UserIdIndex"
 hash_key  = "user_id"
 projection_type = "ALL"
  }

  replica {
 region_name= "ap-northeast-1"
 point_in_time_recovery = true
  }

  replica {
 region_name= "us-east-1"
 point_in_time_recovery = true
  }

  point_in_time_recovery {
 enabled = true
  }

  tags = { MultiRegion = "true" }
}

LWW Conflict Resolution とタイムスタンプ衝突回避

Global Tables の Conflict Resolution は LWW (Last Writer Wins) です。同一アイテムへの競合書き込みが 2 リージョンで同時に発生した場合、タイムスタンプが新しい書き込みが全リージョンに伝播します。リージョン間の時刻ずれ (通常数ミリ秒以内) が衝突判定に影響するため、アプリ側で下表の対策を実装します。

観測性 Vol2 の X-Ray と ADOT で Cross-Region 分散トレーシングを導入すると、2 リージョンにまたがる DynamoDB 書き込みパスのレプリケーション遅延を可視化でき、Endpoint Group の重みづけ調整の判断根拠にできます。

5-3. Aurora Global Database write forwarding と Read Replica 配置

Active-Active 構成では、セッションデータは DynamoDB Global Tables で管理し、トランザクション性の高い業務データは Aurora Global Database に集約します。§6 で詳述する Aurora write forwarding を Active-Active 設計に組み込むことで、Secondary リージョンへの書き込みを Primary へ自動転送できます。

Active-Active におけるデータストア役割分担

Aurora write forwarding の Secondary リージョン接続では aurora_replica_read_consistency = session を設定することで、同一セッション内の読み取りが強整合性になります。金融系ワークロードでは global に変更して全リージョンでの強整合性読み取りが可能ですが、Primary 往復レイテンシ (通常 100〜300 ms) が発生します。

resource "aws_rds_cluster" "secondary_aa" {
  provider= aws.secondary
  cluster_identifier  = "app-secondary-aa"
  engine  = "aurora-mysql"
  engine_version= "8.0.mysql_aurora.3.04.1"
  global_cluster_identifier = aws_rds_global_cluster.main.id

  enable_global_write_forwarding  = true
  db_cluster_parameter_group_name = aws_rds_cluster_parameter_group.secondary.name

  skip_final_snapshot = false
  final_snapshot_identifier = "app-secondary-aa-final"
}

resource "aws_rds_cluster_instance" "secondary_aa_reader" {
  provider= aws.secondary
  count= 2
  identifier = "app-secondary-aa-reader-${count.index}"
  cluster_identifier  = aws_rds_cluster.secondary_aa.id
  instance_class= "db.r6g.large"
  engine  = "aurora-mysql"
  publicly_accessible = false
}

Secondary の Read Replica 数はトラフィック量に応じて調整します。Aurora Auto Scaling が必要な場合は aws_appautoscaling_target と aws_appautoscaling_policy を組み合わせて設定します。write forwarding は DML のみ対応で DDL は Primary リージョンで直接実行する必要があります。スキーマ変更はメンテナンスウィンドウ内に Primary リージョンで実施してください。

5-4. EKS Multi-Region Cluster と ALB Latency-Based Routing

Active-Active 構成のコンピュートレイヤーは、2 リージョンそれぞれに独立した EKS クラスターを配置し、Global Accelerator の Endpoint Group に接続します。各クラスターは同一のアプリコンテナをデプロイし、Global Accelerator が最近傍クラスターへトラフィックを振り分けます。

EKS Vol2 の IRSA (IAM Roles for Service Accounts) をリージョンごとの EKS クラスターに適用することで、DynamoDB Global Tables や Aurora へのアクセス権をクラスター単位で最小権限管理できます。各リージョンの IRSA Role ARN はリージョン固有の OIDC プロバイダーを使用するため、Terraform の aws_iam_openid_connect_provider をリージョン別プロバイダーで定義します。

EKS Vol3 の ArgoCD GitOps を Multi-Region Cluster に適用します。ApplicationSet の clusterDecisionResource ジェネレーターで 1 つの Git リポジトリ変更を両リージョンのクラスターに自動デプロイします。リージョン固有の ConfigMap (データベースエンドポイント、DynamoDB テーブル名) は Kustomize の overlay で管理します。

各リージョンの ALB は EKS の AWS Load Balancer Controller が Kubernetes Ingress リソースから自動作成し、Global Accelerator の Endpoint Group エンドポイントとして登録します。client_ip_preservation_enabled = true により実クライアント IP が ALB から EKS Pod まで伝播し、WAF ルールやアクセスログで正確な送信元を把握できます。

5-5. 落とし穴 — 結果整合性ウィンドウとアプリ層対応

Active-Active 構成では DynamoDB Global Tables のレプリケーション遅延 (通常数ミリ秒〜数秒) による結果整合性ウィンドウへの対応がアプリ層に求められます。

落とし穴 1: 書き込み直後の別リージョン読み取り

ap-northeast-1 へ書き込んだデータを us-east-1 から即時読み取ると、レプリケーション完了前に古いデータを返す場合があります。Global Accelerator の client_affinity = "SOURCE_IP" で同一クライアントを常に同じリージョンへ誘導し、書き込みと読み取りを同一リージョンで完結させます。

落とし穴 2: Conditional Write の競合率上昇

両リージョンへの書き込みが増加すると ConditionExpression でのリジェクト率が上昇します。指数バックオフ付きリトライ (最大 3 回、1 秒・2 秒・4 秒間隔) を実装し、ConditionalCheckFailedException を補足してリトライします。

落とし穴 3: BGP 伝播遅延中のリクエスト到達

Global Accelerator のフェイルオーバー中 (最大 30 秒) は障害エンドポイントへリクエストが届く可能性があります。アプリ層にコネクションタイムアウト 5 秒と HTTP 5xx に対するリトライ 2 回を設定して対処します。

落とし穴 4: Aurora write forwarding 中の Primary 障害

write forwarding 経由の書き込みは Primary リージョンへ転送されるため、Primary 障害時に write forwarding も停止します。この期間の書き込みはエラーとして返すか、DynamoDB など代替ストアへバッファリングする設計を事前に検討してください。

5-6. 3 点セット — Terraform、AWS CLI、コンソール

前掲の Terraform リソース (aws_globalaccelerator_accelerator、aws_globalaccelerator_listener、aws_globalaccelerator_endpoint_group、aws_dynamodb_table with replica ブロック) を同一 state で管理することで、Active-Active 層のドリフト検知が容易になります。

AWS CLI 手順

# Global Accelerator 作成
aws globalaccelerator create-accelerator \
  --name "app-global-accelerator" \
  --ip-address-type IPV4 \
  --enabled \
  --region us-west-2

# アクセラレーター ARN を取得してリスナーを作成
ACCELERATOR_ARN=$(aws globalaccelerator list-accelerators \
  --query "Accelerators[?Name=='app-global-accelerator'].AcceleratorArn" \
  --output text --region us-west-2)

aws globalaccelerator create-listener \
  --accelerator-arn "$ACCELERATOR_ARN" \
  --protocol TCP \
  --port-ranges "FromPort=443,ToPort=443" \
  --client-affinity SOURCE_IP \
  --region us-west-2

# DynamoDB Global Tables テーブル作成 (ap-northeast-1 で作成後 us-east-1 にレプリカ追加)
aws dynamodb create-table \
  --table-name user-sessions \
  --attribute-definitions AttributeName=session_id,AttributeType=S \
  --key-schema AttributeName=session_id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
  --region ap-northeast-1

aws dynamodb update-table \
  --table-name user-sessions \
  --replica-updates "Create={RegionName=us-east-1}" \
  --region ap-northeast-1

# レプリカの状態確認
aws dynamodb describe-table \
  --table-name user-sessions \
  --query "Table.Replicas" \
  --region ap-northeast-1

コンソール手順

Global Accelerator のコンソール設定: Global Accelerator コンソール → [アクセラレーターを作成] → 名前・IP アドレスタイプを設定 → リスナー (TCP ポート 443・送信元 IP アフィニティ) を追加 → エンドポイントグループをプライマリ・セカンダリリージョンにそれぞれ追加 → 各 ALB ARN をエンドポイントとして登録し、ヘルスチェックを HTTPS・30 秒間隔・threshold 3 に設定して作成します。

DynamoDB Global Tables のコンソール設定: DynamoDB コンソール → 対象テーブル → [グローバルテーブル] タブ → [レプリカを追加] → レプリカを追加するリージョンを選択 → [レプリカを作成] します。既存テーブルへのレプリカ追加は PAY_PER_REQUEST と Provisioned どちらでも可能ですが、Provisioned の場合は各リージョンで読み書きキャパシティを個別に設定してください。

6. データ整合性層

Multi-Region 構成で最も難しいのがデータ整合性の管理です。Active-Active では複数リージョンが同時に書き込みを受け付けるため、競合書き込みが発生します。本節では Aurora Global Database write forwarding・DynamoDB Global Tables Last Writer Wins (LWW)・S3 Cross-Region Replication (CRR) の 3 データストアごとに整合性モデルを解説し、Terraform で一括 IaC 化する手順を示します。

6-1. 3 データストア整合性モデル比較

3 種類のデータストアは整合性モデルと Conflict Resolution 方式が大きく異なります。下表で比較した上で各ストアの実装方針を決定してください。

整合性要件が高いトランザクションデータは Aurora Global Database に集約し、セッション情報やカートデータは DynamoDB Global Tables で管理するアーキテクチャが一般的です。静的アセットやログは S3 CRR で十分対応できます。

各ストアの Conflict Resolution 方針はシステム起動前に確定させてください。後から変更するとダウンタイムを伴う場合があります。アプリ層でのべき等性設計と組み合わせることで、障害時の重複実行にも安全に対応できます。

CloudWatch Logs Insights を使ったクロスリージョン整合性ログの分析手法は観測性 Vol1 で詳しく解説しています。Multi-Region 全体の書き込み数とレプリケーション遅延を Logs Insights で集計することで、整合性問題の初期発見を迅速化できます。

6-2. Aurora Global Database write forwarding の Terraform 実装

Aurora Global Database の write forwarding は、secondary リージョンの Read Replica に書き込みクエリが到達した場合、自動的に primary リージョンへ転送する機能です。アプリ層が複数エンドポイントを管理する必要がなくなり、Active-Active 構成でのコード複雑性を大幅に削減できます。

write forwarding の制約一覧

• DML (INSERT・UPDATE・DELETE) のみ対応。DDL (CREATE TABLE・ALTER TABLE) は非対応。
• DDL はメンテナンスウィンドウ内に primary リージョンで直接実行してください。
• write forwarding 中は secondary リージョンの接続が primary に転送されるため、primary リージョン障害時は write forwarding も停止します。
• 接続あたりのオーバーヘッドは primary までのラウンドトリップ (通常 100〜300 ms)。レイテンシ要件が厳しいワークロードは primary リージョンを優先させるルーティング設計と組み合わせてください。

replica_read_consistency の 3 段階設定

resource "aws_rds_global_cluster" "main" {
  global_cluster_identifier = "app-global"
  engine  = "aurora-mysql"
  engine_version= "8.0.mysql_aurora.3.04.1"
  database_name = "appdb"
  storage_encrypted= true
}

resource "aws_rds_cluster_parameter_group" "secondary" {
  provider = aws.secondary
  name  = "app-secondary-params"
  family= "aurora-mysql8.0"
  description = "write forwarding parameter group"

  parameter {
 name  = "aurora_replica_read_consistency"
 value = "session"
  }
}

resource "aws_rds_cluster" "secondary" {
  provider= aws.secondary
  cluster_identifier  = "app-secondary"
  engine  = "aurora-mysql"
  engine_version= "8.0.mysql_aurora.3.04.1"
  global_cluster_identifier = aws_rds_global_cluster.main.id

  enable_global_write_forwarding  = true
  db_cluster_parameter_group_name = aws_rds_cluster_parameter_group.secondary.name

  skip_final_snapshot = false
  final_snapshot_identifier = "app-secondary-final"
}

6-3. DynamoDB Global Tables LWW と Conflict Resolution

DynamoDB Global Tables の Conflict Resolution は LWW (Last Writer Wins) です。同一アイテムへの競合書き込みが発生した場合、タイムスタンプが最も新しい書き込みが全リージョンに伝播します。

タイムスタンプ衝突回避策

LWW はシステム時刻に依存するため、リージョン間の時刻ずれ (通常数ミリ秒以内) が衝突を誤判定する可能性があります。回避策として、書き込み時刻ではなくアプリ側で生成したバージョン番号 (単調増加する UUID v7 や論理クロック) を属性として付与し、ConditionExpression で古い書き込みを拒否する実装が有効です。

Conflict Resolution パターン比較

resource "aws_dynamodb_table" "cart" {
  name= "cart"
  billing_mode = "PAY_PER_REQUEST"
  hash_key  = "user_id"
  range_key = "item_id"

  stream_enabled= true
  stream_view_type = "NEW_AND_OLD_IMAGES"

  attribute {
 name = "user_id"
 type = "S"
  }

  attribute {
 name = "item_id"
 type = "S"
  }

  replica {
 region_name = "ap-northeast-1"
  }

  replica {
 region_name = "us-east-1"
  }

  point_in_time_recovery {
 enabled = true
  }
}

DynamoDB Streams + Lambda による後処理パターンでは、Lambda Powertools の Idempotency 機能と組み合わせることで重複書き込みを安全に排除できます。衝突検知後にビジネスロジックで最終値を決定するアーキテクチャは、金融系や在庫管理など「最後の書き込みが常に正しいとは限らない」ワークロードで特に有効です。Lambda Layers とコンテナ を活用した Conflict Resolution ライブラリの共有化も検討してください。

6-4. S3 Cross-Region Replication と RTC

S3 CRR は結果整合性モデルであり、通常 1〜15 分以内にオブジェクトがレプリケートされます。RTC (Replication Time Control) を有効化すると、99.99% の確率で 15 分以内のレプリケーション完了を SLA として保証します。

resource "aws_s3_bucket_replication_configuration" "main" {
  bucket = aws_s3_bucket.source.id
  role= aws_iam_role.replication.arn

  rule {
 id  = "replicate-all"
 status = "Enabled"

 delete_marker_replication {
status = "Enabled"
 }

 destination {
bucket  = aws_s3_bucket.destination.arn
storage_class = "STANDARD"

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

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

 filter {
prefix = ""
 }
  }
}

運用上の注意点

S3 CRR は PUT・COPY 操作を自動レプリケートしますが、削除操作はデフォルトでレプリケートされません。delete_marker_replication を明示的に Enabled にしないと、ソースバケットで削除したオブジェクトがデスティネーションに残り続けます。この設定漏れはストレージコスト超過や意図しないデータ残存につながるため必ず設定してください。

また、バージョニングが無効なバケットは CRR を設定できません。ソース・デスティネーション両バケットでバージョニングを有効化してから設定してください。

6-5. 結果整合性運用とデータ衝突検知 SLO

DynamoDB Global Tables と S3 CRR は結果整合性モデルのため、レプリケーション遅延を継続的に監視する仕組みが必要です。CloudWatch のメトリクス ReplicationLatency にアラームを設定し、しきい値超過を検知します。通常は数秒以内に収束しますが、ネットワーク障害時は数分に延びることがあります。

resource "aws_cloudwatch_metric_alarm" "dynamodb_replication_lag" {
  alarm_name = "dynamodb-replication-latency"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 2
  metric_name= "ReplicationLatency"
  namespace  = "AWS/DynamoDB"
  period  = 60
  statistic  = "Maximum"
  threshold  = 5000
  alarm_description= "DynamoDB Global Tables レプリケーション遅延が 5 秒超"

  dimensions = {
 TableName = aws_dynamodb_table.cart.name
 ReceivingRegion = "ap-northeast-1"
  }
}

アプリ層では書き込み直後に別リージョンから読み取る場合、レプリケーション完了前にアクセスが到達する可能性があります。DynamoDB の TransactGetItems を利用した強整合性読み取り、または Aurora write forwarding の session モードを組み合わせてレプリケーション遅延の影響を隠蔽する設計が有効です。

SLO として「DynamoDB GT ReplicationLatency P99 \< 5 秒」「S3 RTC 99.99% を 15 分以内」を定義し、SLO バジェット消費をダッシュボードで可視化してください。

6-6. 3 点セット — Terraform、AWS CLI、コンソール

前述の各サブ節に示した Terraform リソースを同一 state で管理することで、3 データストアのドリフト検知が容易になります。terraform plan を定期実行することで予期しない設定変更を早期に発見できます。

AWS CLI での操作手順を示します。

# Aurora secondary クラスターに write forwarding を有効化
aws rds modify-db-cluster \
  --db-cluster-identifier app-secondary \
  --enable-global-write-forwarding \
  --region ap-northeast-1

# replica_read_consistency を session に変更 (再起動後に反映)
aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name app-secondary-params \
  --parameters "ParameterName=aurora_replica_read_consistency,ParameterValue=session,ApplyMethod=pending-reboot" \
  --region ap-northeast-1

# S3 バケットのレプリケーション設定を確認
aws s3api get-bucket-replication \
  --bucket my-source-bucket \
  --region ap-northeast-1

# DynamoDB Global Tables のレプリケーション遅延を確認
aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB \
  --metric-name ReplicationLatency \
  --dimensions Name=TableName,Value=cart Name=ReceivingRegion,Value=ap-northeast-1 \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-02T00:00:00Z \
  --period 3600 \
  --statistics Maximum \
  --region us-east-1

コンソール手順

Aurora write forwarding のコンソール設定は次のとおりです。RDS コンソール → 対象グローバルクラスターを選択 → 「変更」をクリック → 「グローバル書き込み転送 (write forwarding)」を有効化 → 「すぐに適用」を選択して変更を確定します。

S3 CRR のコンソール設定は次のとおりです。S3 コンソール → 対象バケット → 「管理」タブ → 「レプリケーションルール」→「レプリケーションルールを作成」→ レプリケーション先バケット・IAM ロール・RTC オプション・削除マーカーレプリケーションを設定 → 保存します。

7. Vol2 FIS 連携と Vol3 SSM Runbook 自動切替 (シリーズ統合実機検証)

7-1. シリーズ統合検証アーキテクチャ全体像

本章では、復旧・運用編シリーズを通じて構築した本番基盤を Multi-Region 構成へ統合し、障害注入から自動切替・RTO/RPO 実測までを end-to-end で検証する。Vol2 で確立した AWS Fault Injection Simulator による機械的障害シナリオと、Vol3 で整備した SSM Automation による自動復旧 Runbook を、本 Vol4 の Active-Active および Active-Passive 構成に適用することで、シリーズ集大成となる統合実機検証を完成させる。

統合検証シナリオは以下の 4 本立てで構成する。

各シナリオは「FIS 実験テンプレート実行 → 障害検知 (CloudWatch Alarm) → SSM Automation 起動 → ARC Routing Control 更新 → 回復確認」の流れで進行する。観測性 Vol3 で構築した SLO Burn Rate Alarm との連携により、SLO 違反検知から自動切替を発火させる設計とする。

検証環境の前提:
– Primary リージョン: ap-northeast-1 (東京)
– Secondary リージョン: ap-southeast-1 (シンガポール)
– Vol2 FIS 実験テンプレート: 既存の aws_fis_experiment_template リソースを拡張
– Vol3 SSM Automation Document: 既存の IR Runbook に ARC 操作ステップを追加

7-2. Vol2 FIS Experiment で A-A 構成を実機検証

Active-Active 構成の FIS 統合検証では、aws_fis_experiment_template で Global Accelerator Endpoint 障害と DynamoDB 書き込みエラーの 2 種類を実施する。

# FIS IAM ロール (Active-Active 検証用)
resource "aws_iam_role" "fis_aa" {
  name = "fis-aa-experiment-role"
  assume_role_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = { Service = "fis.amazonaws.com" }
 }]
  })
}

resource "aws_iam_role_policy_attachment" "fis_aa_network" {
  role = aws_iam_role.fis_aa.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSFaultInjectionSimulatorNetworkAccess"
}

# S-1: Global Accelerator Endpoint 障害注入テンプレート
resource "aws_fis_experiment_template" "aa_ga_endpoint_failure" {
  description = "A-A: Global Accelerator endpoint failure injection"
  role_arn = aws_iam_role.fis_aa.arn

  stop_condition {
 source = "aws:cloudwatch:alarm"
 value  = aws_cloudwatch_metric_alarm.ga_healthy_count.arn
  }

  action {
 name= "disrupt-primary-subnets"
 action_id = "aws:network:disrupt-connectivity"
 parameter {
key= "duration"
value = "PT5M"
 }
 target {
key  = "Subnets"
type = "aws:ec2:subnet"
 }
  }

  target {
 name  = "primary-subnets"
 resource_type  = "aws:ec2:subnet"
 selection_mode = "ALL"
 resource_tag {
key= "Region"
value = "primary"
 }
  }

  tags = { Experiment = "AA-GA-Endpoint-Failure" }
}

# S-2: DynamoDB Global Table 書き込みエラー注入テンプレート
resource "aws_fis_experiment_template" "aa_dynamodb_error" {
  description = "A-A: DynamoDB Global Table write disruption for LWW verification"
  role_arn = aws_iam_role.fis_aa.arn

  stop_condition {
 source = "aws:cloudwatch:alarm"
 value  = aws_cloudwatch_metric_alarm.dynamodb_error_rate.arn
  }

  action {
 name= "pause-dynamodb-replication"
 action_id = "aws:dynamodb:global-table-pause-replication"
 parameter {
key= "duration"
value = "PT3M"
 }
 target {
key  = "Tables"
type = "aws:dynamodb:table"
 }
  }

  target {
 name  = "global-table-primary"
 resource_type  = "aws:dynamodb:table"
 selection_mode = "ALL"
 resource_tag {
key= "MultiRegion"
value = "true"
 }
  }

  tags = { Experiment = "AA-DynamoDB-Write-Disruption" }
}

S-1 実行後、Global Accelerator が Secondary エンドポイントへ自動迂回することを確認し、フェイルオーバー完了時間を RTO として記録する。S-2 では DynamoDB 書き込み中断中に LWW 整合性が機能しているかを CloudWatch Metrics SystemErrors で観測する。

# S-1 FIS 実験開始
TEMPLATE_ID=$(aws fis list-experiment-templates \
  --query "experimentTemplates[?tags.Experiment=='AA-GA-Endpoint-Failure'].id" \
  --output text)

aws fis start-experiment \
  --experiment-template-id "$TEMPLATE_ID" \
  --tags "RunDate=$(date +%Y-%m-%d)"

# 実験状態確認
aws fis get-experiment \
  --id "$EXPERIMENT_ID" \
  --query "experiment.state.{status:status,reason:reason}"

7-3. Vol2 FIS Experiment で A-P 構成を実機検証

Active-Passive 構成の FIS 統合検証では、Primary リージョンの EC2 を停止し、SSM Automation による ARC Routing Control 切替との連携を確認する。

# FIS IAM ロール (Active-Passive 検証用)
resource "aws_iam_role" "fis_ap" {
  name = "fis-ap-experiment-role"
  assume_role_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = { Service = "fis.amazonaws.com" }
 }]
  })
}

resource "aws_iam_role_policy_attachment" "fis_ap_ec2" {
  role = aws_iam_role.fis_ap.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSFaultInjectionSimulatorEC2Access"
}

resource "aws_iam_role_policy_attachment" "fis_ap_rds" {
  role = aws_iam_role.fis_ap.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSFaultInjectionSimulatorRDSAccess"
}

# S-3: Primary リージョン EC2 停止注入テンプレート
resource "aws_fis_experiment_template" "ap_primary_ec2_stop" {
  description = "A-P: Primary region EC2 stop injection + ARC Routing Control verification"
  role_arn = aws_iam_role.fis_ap.arn

  stop_condition {
 source = "aws:cloudwatch:alarm"
 value  = aws_cloudwatch_metric_alarm.arc_routing_switched.arn
  }

  action {
 name= "stop-primary-ec2"
 action_id = "aws:ec2:stop-instances"
 parameter {
key= "duration"
value = "PT10M"
 }
 target {
key  = "Instances"
type = "aws:ec2:instance"
 }
  }

  target {
 name  = "primary-app-servers"
 resource_type  = "aws:ec2:instance"
 selection_mode = "ALL"
 resource_tag {
key= "Role"
value = "app-primary"
 }
  }

  tags = { Experiment = "AP-Primary-EC2-Stop" }
}

# S-4: Aurora Global Database フェイルオーバー注入テンプレート
resource "aws_fis_experiment_template" "ap_aurora_failover" {
  description = "A-P: Aurora Global Database failover injection for RPO verification"
  role_arn = aws_iam_role.fis_ap.arn

  stop_condition {
 source = "aws:cloudwatch:alarm"
 value  = aws_cloudwatch_metric_alarm.aurora_switchover_complete.arn
  }

  action {
 name= "failover-aurora-cluster"
 action_id = "aws:rds:failover-db-cluster"
 target {
key  = "Clusters"
type = "aws:rds:cluster"
 }
  }

  target {
 name  = "primary-aurora-cluster"
 resource_type  = "aws:rds:cluster"
 selection_mode = "ALL"
 resource_tag {
key= "Role"
value = "aurora-primary"
 }
  }

  tags = { Experiment = "AP-Aurora-Failover" }
}

S-3 実行後は CloudWatch Alarm が発火し、SSM Automation Document ARC-RoutingControl-AutoFailover が起動する。ARC Routing Control が Secondary リージョンへ切り替わるまでの時間を RTO として記録する。S-4 では Aurora Global Database の Switchover (RPO ≈ 0) と元の Primary の再追加を確認する。

# S-3 実験終了後の回復状態確認
aws route53-recovery-cluster get-routing-control-state \
  --routing-control-arn "$PRIMARY_RC_ARN" \
  --endpoint-url "$CLUSTER_ENDPOINT"

# Aurora Global Cluster メンバー確認
aws rds describe-db-clusters \
  --query "DBClusters[?DBClusterIdentifier=='global-cluster-member'].{ID:DBClusterIdentifier,Writer:DBClusterMembers[0].IsWriter}"

7-4. Vol3 SSM Automation で ARC Routing Control 自動切替

Vol3 で構築した IR Runbook 基盤を ARC Routing Control 操作へ拡張する。SSM Automation Document が route53-recovery-cluster update-routing-control-states を自動実行し、FIS 障害注入とシームレスに連携する。

# SSM Automation 実行 IAM ロール
resource "aws_iam_role" "ssm_arc_automation" {
  name = "ssm-arc-routing-control-role"

  assume_role_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = { Service = "ssm.amazonaws.com" }
 }]
  })
}

resource "aws_iam_role_policy" "ssm_arc_policy" {
  name = "ssm-arc-routing-control-policy"
  role = aws_iam_role.ssm_arc_automation.id

  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [
{
  Effect = "Allow"
  Action = [
 "route53-recovery-cluster:UpdateRoutingControlState",
 "route53-recovery-cluster:UpdateRoutingControlStates",
 "route53-recovery-cluster:GetRoutingControlState",
 "route53-recovery-cluster:ListRoutingControls"
  ]
  Resource = "*"
},
{
  Effect= "Allow"
  Action= ["cloudwatch:PutMetricData"]
  Resource = "*"
}
 ]
  })
}

# ARC Routing Control 自動切替 SSM Automation Document
resource "aws_ssm_document" "arc_routing_control_failover" {
  name = "ARC-RoutingControl-AutoFailover"
  document_type = "Automation"

  content = jsonencode({
 schemaVersion = "0.3"
 description= "Automated ARC Routing Control failover for Active-Passive Multi-Region switchover"
 assumeRole = aws_iam_role.ssm_arc_automation.arn
 parameters = {
PrimaryRoutingControlArn = {
  type  = "String"
  description = "Primary region Routing Control ARN to disable"
}
SecondaryRoutingControlArn = {
  type  = "String"
  description = "Secondary region Routing Control ARN to enable"
}
 }
 mainSteps = [
{
  name= "DisablePrimaryRoutingControl"
  action = "aws:executeAwsApi"
  inputs = {
 Service = "route53-recovery-cluster"
 Api  = "UpdateRoutingControlState"
 RoutingControlArn= "{{ PrimaryRoutingControlArn }}"
 RoutingControlState = "Off"
  }
},
{
  name= "EnableSecondaryRoutingControl"
  action = "aws:executeAwsApi"
  inputs = {
 Service = "route53-recovery-cluster"
 Api  = "UpdateRoutingControlState"
 RoutingControlArn= "{{ SecondaryRoutingControlArn }}"
 RoutingControlState = "On"
  }
},
{
  name= "PublishRTOMetric"
  action = "aws:executeAwsApi"
  inputs = {
 Service = "cloudwatch"
 Api  = "PutMetricData"
 Namespace  = "MultiRegion/Failover"
 MetricData = [{
MetricName = "ARCFailoverCompleted"
Value= 1
Unit = "Count"
 }]
  }
}
 ]
  })
}

# SLO Burn Rate Alarm → ARC フェイルオーバー自動起動
resource "aws_cloudwatch_metric_alarm" "slo_burn_rate_arc_trigger" {
  alarm_name = "slo-burn-rate-arc-failover-trigger"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 3
  metric_name= "burn_rate"
  namespace  = "AWS/ApplicationSignals"
  period  = 60
  statistic  = "Average"
  threshold  = 2.0
  alarm_description= "SLO Burn Rate > 2 triggers ARC Routing Control automatic failover"
  alarm_actions = [aws_sns_topic.arc_failover_trigger.arn]
}

SSM Automation 手動実行:

aws ssm start-automation-execution \
  --document-name "ARC-RoutingControl-AutoFailover" \
  --parameters \
 "PrimaryRoutingControlArn=$PRIMARY_RC_ARN,\
SecondaryRoutingControlArn=$SECONDARY_RC_ARN"

# 実行状態確認
aws ssm describe-automation-executions \
  --filter "Key=DocumentName,Values=ARC-RoutingControl-AutoFailover" \
  --query "AutomationExecutionMetadataList[0].{Status:AutomationExecutionStatus,Start:ExecutionStartTime}"

観測性 Vol3 で構築した SLO Burn Rate Alarm を Burn Rate > 2 (1 時間窓・3 分連続) で発火させ、ARC Routing Control 切替を完全自動化する。CloudWatch Alarm → SNS → Lambda → SSM Automation の連携チェーンにより、SLO 違反検知から 2 分以内にフェイルオーバーが完了する設計となる。コンソール操作では、SSM コンソールの [Automation] → [Execute automation] で ARC-RoutingControl-AutoFailover を選択し、Primary と Secondary の Routing Control ARN を入力して実行する。

7-5. RTO・RPO 実測比較と CloudWatch Custom Metric

FIS 実験実行後、以下の CloudWatch Custom Metrics でシナリオ別 RTO・RPO を計測する。

# RTO/RPO 計測用 CloudWatch ダッシュボード
resource "aws_cloudwatch_dashboard" "multi_region_rto_rpo" {
  dashboard_name = "MultiRegion-RTO-RPO-Dashboard"

  dashboard_body = jsonencode({
 widgets = [
{
  type= "metric"
  width  = 12
  height = 6
  properties = {
 title = "A-P Failover RTO (ARC Routing Control)"
 metrics = [
["MultiRegion/Failover", "ARCFailoverCompleted", { label = "A-P RTO" }],
["MultiRegion/Failover", "MeasuredRTO", { label = "RTO Seconds" }]
 ]
 period = 60
 stat= "Sum"
 view= "timeSeries"
  }
},
{
  type= "metric"
  width  = 12
  height = 6
  properties = {
 title = "A-A DynamoDB LWW Consistency Errors"
 metrics = [
["MultiRegion/DataConsistency", "LWWConflictCount", { label = "LWW Conflict (A-A)" }]
 ]
 period = 60
 stat= "Sum"
 view= "timeSeries"
  }
}
 ]
  })
}

RTO 実測スクリプト例:

# FIS 実験開始時刻記録
EXPERIMENT_START=$(date +%s)
aws fis start-experiment --experiment-template-id "$AP_EC2_TEMPLATE_ID"

# ARC Routing Control 切替完了を待機
until aws route53-recovery-cluster get-routing-control-state \
  --routing-control-arn "$SECONDARY_RC_ARN" \
  --endpoint-url "$CLUSTER_ENDPOINT" \
  --query "RoutingControlState" --output text | grep -q "On"; do
  sleep 5
done

FAILOVER_COMPLETE=$(date +%s)
RTO_SECONDS=$((FAILOVER_COMPLETE - EXPERIMENT_START))
echo "実測 RTO: ${RTO_SECONDS} 秒"

# CloudWatch Custom Metric に書き込み
aws cloudwatch put-metric-data \
  --namespace "MultiRegion/Failover" \
  --metric-data "MetricName=MeasuredRTO,Value=${RTO_SECONDS},Unit=Seconds"

7-6. 3 点セット — Terraform、AWS CLI、コンソール

§7 統合検証の 3 点セット早見表:

コンソール操作手順 (S-3 Active-Passive 実機検証):

1. AWS FIS コンソール → [Experiment templates] → AP-Primary-EC2-Stop を選択 → [Start experiment]
2. FIS 実験実行中、CloudWatch ダッシュボード MultiRegion-RTO-RPO-Dashboard でメトリクスを監視
3. SLO Burn Rate Alarm 発火後、SSM コンソール → [Automation] → [Executions] で ARC-RoutingControl-AutoFailover の実行を確認
4. ARC コンソール → [Routing controls] で Secondary の状態が On になるまでの時間を RTO として記録
5. aws route53-recovery-cluster get-routing-control-state で切替完了を確認後、FIS 実験を停止

8. まとめ — 復旧・運用編シリーズ完結宣言

8-1. 本記事のチートシート — A-A と A-P 選定フローチャート

5 次元評価から Active-Active か Active-Passive かを選定するフローチャートと主要 AWS リソース対応表を整理する。

A-A vs A-P 選定フローチャート

RTO < 30 秒 が必須?
├── YES → Active-Active (Global Accelerator + DynamoDB Global Tables)
└── NO  → RPO = 0 (データ無損失) が必須?
 ├── YES → Active-Passive (Aurora Global Database Switchover + ARC Routing Control)
 └── NO  → コスト優先?
  ├── YES → Active-Passive (Warm Standby または Pilot Light)
  └── NO  → 書き込みのリージョン分散が必要?
├── YES → Active-Active
└── NO  → Active-Passive

主要 AWS リソース対応表

8-2. 落とし穴 10 選 — Multi-Region 設計で踏み抜く前に

Multi-Region 設計の実装・運用で実際に踏み抜きやすい落とし穴 10 選を解説する。

1. ARC Cluster コストの過小評価
   ARC Cluster は月額 $2.5・Routing Control は $1/control/月と低単価に見えるが、Control Panel・Safety Rules・Readiness Check Resource Set を含めると月額 $30〜$80 になる。事前に aws route53-recovery-control-config list-routing-controls で現在の control 数を確認し、月次コスト試算を必ず行う。

2. Aurora Global Database write forwarding の DML 制約
   global_write_forwarding_requested = true 設定後も Secondary リージョンから DDL (CREATE TABLE、ALTER TABLE) は実行できない。DML のみフォワード可能であり、スキーマ変更は Primary リージョンで行う必要がある。replica_read_consistency は eventual、session、global の 3 段階から選択する。

3. DynamoDB Global Tables LWW タイムスタンプ衝突
   LWW (Last Writer Wins) は各リージョンのシステム時刻に依存するため、NTP 同期ずれがあると意図しない上書きが発生する。競合する書き込みには _record_version カラムを追加して楽観的ロックを補完するか、DynamoDB Streams + Lambda で後処理による衝突解決を実装する。

4. Global Accelerator BGP anycast の切替遅延
   Global Accelerator のヘルスチェック失敗から BGP 経路更新の反映には最大 30 秒かかる。RTO < 10 秒 を要求する SLA には GA は不適合であることを §2 の 5 次元比較表で明示し、アプリ層に 30 秒のリトライ設計を加える。

5. Aurora Switchover 後の Secondary 再追加忘れ
   Aurora Global Database Switchover 後、元の Primary はサポートが外れ Secondary として再追加が必要になる。Switchover 後に aws rds describe-db-clusters で Global Cluster メンバーを確認し、terraform apply で再追加するまでの間は構成が単一リージョンになることを運用手順書に明記する。

6. ARC Safety Rules の未設定によるスプリットブレイン
   ARC の Safety Rules は Routing Control が同時に Off になる事故を防ぐ ATLEAST ルールを最低 1 本設定する。未設定では Primary も Secondary も Off になりサービス停止が発生しうる。aws route53-recovery-control-config list-safety-rules で必ず確認する。

7. Multi-Region IAM 権限の拡大クリープ
   ARC Routing Control の操作権限 (route53-recovery-cluster:UpdateRoutingControlState) はリージョン障害時に複数の担当者が必要とするが、過剰な FullAccess 付与は禁物。IAM Identity Center の Permission Set で「ARC 操作専用」ロールを作成し、緊急時のみ昇格する体制を構築する。

8. Cross-Region データ転送料金の見落とし
   Aurora Global Database と S3 CRR、DynamoDB Global Tables はいずれも Cross-Region データ転送料金が発生する。Aurora は $0.02/GB、S3 CRR は $0.02/GB (us-east-1 起点)、DynamoDB Global Tables は $0.25/100 万 rWCU (repli)。月次データ転送量試算は §2 の月額コスト列に含める。

9. SLO Burn Rate の閾値設定ミスによる誤フェイルオーバー
   SLO Burn Rate Alarm のしきい値を低く設定しすぎると、一時的なレイテンシスパイクで ARC フェイルオーバーが誤発火する。Burn Rate > 2 (1 時間窓) を推奨値とし、evaluation_periods = 3 (3 分連続) で誤発火を防ぐ。

10. シリーズ完結後の Runbook 未更新
    Vol1〜Vol4 の全 Terraform モジュールと SSM Automation Runbook はシリーズ完結後も定期的な更新が必要。Aurora エンジンバージョン、Terraform AWS プロバイダー、FIS アクション名が変更になる場合があるため、四半期ごとの terraform plan 差分確認を運用スケジュールに組み込む。

8-3. 既存 14 リソース双方向クロスリンク (シリーズ完結)

復旧・運用編シリーズ完結に際し、既存 12 巻に加えて Vol1〜Vol3 を含む全 14 リソースとの双方向クロスリンクを整備する。

8-4. 復旧・運用編シリーズ完結宣言 — DR 階層 4 段階踏破

復旧・運用編シリーズ全 4 巻が本記事をもって完結する。Vol1 から Vol4 までの 4 段階で構成された DR 階層を振り返り、読者が到達した地点を総括する。

DR 階層 4 段階踏破の軌跡

本 Vol4 の完成により、読者は単一リージョン障害から Multi-Region 構成での最高レベルの可用性設計まで、Terraform で本番投入可能な状態を手に入れた。Backup/DR の基礎から Chaos Engineering による継続的な品質担保、IR Runbook による自動復旧、そして Active-Active と Active-Passive の戦略的選択まで — DR 階層の 4 段階を完全踏破した。