📌 はじめに
大規模障害（リージョン障害）に備えるディザスタリカバリ（DR）設計において、コストと復旧時間のバランスを取る代表的な手法が 「Pilot Light（パイロットライト）」 パターンです。
平常時はコンピュートリソースを起動せず（コスト最小化）、データのみをスタンバイリージョンへ非同期レプリケーションしておき、障害発生時に Route 53 のヘルスチェックと AWS Lambda を連携させて RTO < 15分 で自動昇格・起動・トラフィック切替を完結させる標準アーキテクチャについて整理します。
1. 業務シナリオとDR要件の整理
業務背景
- 構成パターン: Pilot Light（データ層は常時同期、コンピュート層は待機/最小構成）。
- プライマリリージョン (Primary Region): ALB + 稼働中の Auto Scaling EC2 + Multi-AZ RDS プライマリインスタンス。
-
セカンダリ/DRリージョン (Secondary Region): ALB のみ事前作成。Auto Scaling グループは
Min=0, Max=0（EC2 コストを削減）。データベースは RDS クロスリージョンリードレプリカ（Read Replica） による非同期レプリケーションを維持。
コア要件
- RTO < 15分: 障害発生からフェイルオーバー完了までを極めて短時間で達成すること。
- 完全自動フェイルオーバー (Automatic Failover): プライマリリージョン全損時、人間の介入なしでリードレプリカの昇格、EC2 のスケールアウト、DNS 切替を自律実行すること。
2. アーキテクチャトポロジーとフェイルオーバーフロー
[ 全世界のエンドユーザー / クライアント ]
│
▼
[ Amazon Route 53 ドメイン名前解決 ]
(フェイルオーバールーティング + プライマリヘルスチェック)
│ │
(プライマリ健全時: 通常ルーティング) (ヘルスチェック異常検知: DR側へ自動切替)
▼ ▼
┌───────────────────────────┐ ┌───────────────────────────┐
│ プライマリリージョン │ │ DR / セカンダリリージョン│
│ │ │ │
│ [ ALB ] │ │ [ ALB ] │
│ │ │ │ │ │
│ [ EC2 Auto Scaling 組 ] │ │ [ EC2 Auto Scaling 組 ] │
│ (正常稼働インスタンス) │ │ (平常時 Min=0, Max=0) │
│ │ │ │ │ (Lambdaにより自動スケール)│
│ ▼ │ │ ▼ │
│ [ RDS Multi-AZ 主DB ] │ │ [ RDS リードレプリカ ] │
│ │ │ │ (平常時: 非同期レプリカ) │
│ └─(クロスリージョン同期)──┼──►│ │ (Lambdaにより昇格) │
└───────────────────────────┘ └───────▲───────────────────┘
│ │
(ヘルスチェック失敗) │
▼ │
[ Route 53 Health Check ] │
│ (Unhealthy) │
▼ │
[ Amazon SNS トピック ] ───────────┘
│ (通知・トリガー)
▼
[ AWS Lambda (自動化スクリプト) ]
1. rds:PromoteReadReplica でリードレプリカを独立マスターへ昇格
2. autoscaling:UpdateAutoScalingGroup で Min/Desired を引き上げEC2起動
3. コア設計ロジック（トラフィック面 ＆ コントロール面の連動）
RTO < 15分の自動冷備（Cold Standby）切り替えを実現するためには、トラフィック面（DNS） と コントロールプレーン（リソースプロビジョニング） を完全に連動させます。
① トラフィック層の自動切替：Route 53 Failover Routing
- 設計: Route 53 で フェイルオーバールーティングポリシー（Failover Policy） を設定し、プライマリレコードにプライマリリージョンの ALB に対する Route 53 Health Check をバインドします。
-
動作: プライマリリージョンが途絶してヘルスチェックが
Unhealthyになると、Route 53 はトラフィックの向け先をセカンダリリージョンの ALB へ自動的かつシームレスに切り替えます。
② コントロール層の自動復旧：SNS ＋ Lambda オーケストレーション
- トリガー: Route 53 のヘルスチェックが異常を検知した際、CloudWatch アラーム経由で Amazon SNS トピック へ通知を発行し、セカンダリリージョンに配置した AWS Lambda 関数 をキックします。
- Lambda の実行タスク:
-
リードレプリカのプライマリ昇格:
rds:PromoteReadReplicaAPI を呼び出し、セカンダリ側の RDS リードレプリカをスタンドアロンの書き込み可能なプライマリ DB へ昇格。 -
EC2 の高速起動:
autoscaling:UpdateAutoScalingGroupAPI を呼び出し、セカンダリ側 ASG のMinSize、MaxSize、DesiredCapacityを必要な台数（例: 2台以上）へ更新。
4. 自動化 Lambda スクリプト例 (Python / boto3)
import boto3
import os
rds = boto3.client('rds', region_name=os.environ['DR_REGION'])
asg = boto3.client('autoscaling', region_name=os.environ['DR_REGION'])
def lambda_handler(event, context):
db_instance_id = os.environ['DR_DB_INSTANCE_IDENTIFIER']
asg_name = os.environ['DR_ASG_NAME']
desired_capacity = int(os.environ.get('DESIRED_CAPACITY', '2'))
print(f"Starting Disaster Recovery Failover Process in {os.environ['DR_REGION']}...")
# 1. RDS リードレプリカをプライマリへ昇格
try:
print(f"Promoting RDS Read Replica: {db_instance_id}")
rds.promote_read_replica(
DBInstanceIdentifier=db_instance_id,
BackupRetentionPeriod=7
)
print("RDS promote request submitted successfully.")
except Exception as e:
print(f"Error promoting RDS: {str(e)}")
raise e
# 2. DRリージョンの Auto Scaling グループをスケールアウト
try:
print(f"Scaling up Auto Scaling Group: {asg_name} to capacity: {desired_capacity}")
asg.update_auto_scaling_group(
AutoScalingGroupName=asg_name,
MinSize=desired_capacity,
MaxSize=desired_capacity * 2,
DesiredCapacity=desired_capacity
)
print("ASG capacity updated successfully.")
except Exception as e:
print(f"Error updating ASG: {str(e)}")
raise e
return {
"status": "success",
"message": "DR failover process initiated."
}
5. まとめ
-
コスト最適化: 平常時はセカンダリリージョンの EC2 を稼働させず（
Min=0）、RDS リードレプリカの同期費用のみに抑えることで Pilot Light のコストメリットを最大化。 - RTO 15分以内の達成: ヘルスチェック検知から Lambda による DB 昇格およびインスタンス起動までを完全に自動化し、人的オペレーションを排除することで 5〜10 分程度で切り替えを完結。