パイロットライトとウォームスタンバイ
ワークロードの最小限の中核を第2のリージョンで稼働させるパイロットライト、または縮小された完全稼働可能なコピーであるウォームスタンバイを維持し、拡張に備えます。
「パイロットライトとウォームスタンバイ」はCoddyKit上の無料Cloud & IT Cert Prepレッスンです。 これはレッスン3/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはCloud & IT Cert Prep学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Cloud & IT Cert Prepコースには全4レッスンが含まれています。
Backup and Restore の先へ
RTO の要件が数時間より厳しい場合、Backup and Restore では不十分です。次の 2 つの DR ティアであるPilot LightとWarm Standbyは、常に DR リージョンでインフラストラクチャの一部または全部を稼働させておくことで、復旧にかかる時間を大幅に短縮します。どちらの戦略でも DR 環境を継続的に維持し、災害時には Route 53 のヘルスチェックフェイルオーバーを使用してトラフィックをリダイレクトします。違いは、DR 環境のどれだけの部分を実際に稼働させておくかです。
Pilot Light:コア部分を常時稼働
Pilot Light 戦略では、システムの重要なコア部分だけを DR リージョンで稼働させます。通常は、継続的にレプリケーションされるデータベース層のみです。アプリケーションサーバーは稼働させず、代わりに事前構築した AMI、起動テンプレート、または Infrastructure as Code を維持して、必要なときにすばやく起動できるようにします。これは、小さな炎を灯し続け、必要なときには数分で大きな炎に点火できるガスコンロのパイロットランプのようなものです。RTO は通常 30~60 分です。
# Pilot Light: what runs 24/7 in DR region
# - RDS Read Replica (receiving continuous replication)
# - Minimal VPC/networking (no extra cost if no data transfer)
# - Route 53 failover record (inactive, health check pointing to primary)
# What is prepared but NOT running:
# - EC2 launch template pointing to DR AMI
# - ALB (can be created in minutes)
# - ASG with desired=0, can scale to 10 on demandPilot Light のフェイルオーバー手順
プライマリリージョンに障害が発生し、Pilot Light のフェイルオーバーが開始された場合は、次の手順を実行します。Step 1 — DR リージョンの RDS Read Replica を、独立したプライマリデータベースに昇格します。Step 2 — 事前構築した AMI または起動テンプレートから EC2 インスタンスを起動します。Step 3 — Application Load Balancer を作成または有効化し、新しい EC2 インスタンスを登録します。Step 4 — 昇格したデータベースのエンドポイントを参照するように、アプリケーション設定を更新します。Step 5 — Route 53 のヘルスチェックフェイルオーバーによって DNS の切り替えが完了します。合計時間:30~60 分。
# Step 1: Promote RDS Read Replica
aws rds promote-read-replica \
--db-instance-identifier mydb-dr-replica \
--region us-west-2
# Step 2: Scale up ASG in DR region
aws autoscaling update-auto-scaling-group \
--auto-scaling-group-name app-asg-dr \
--min-size 2 \
--desired-capacity 4 \
--region us-west-2
# Step 3: Route 53 failover happens automatically
# via health check detecting primary region failureWarm Standby:縮小構成でも完全に機能する環境
Warm Standby 戦略では、本番環境を完全に再現しつつ規模を縮小した環境を DR リージョンで継続的に稼働させます。Web サーバー、アプリケーションサーバー、データベースなど、すべてのアプリケーション層がアクティブですが、容量は削減されています(たとえば、20 台ではなく 2 台)。フェイルオーバー時には、DR 環境をスケールアップして本番環境の負荷に対応させます。Route 53 はヘルスチェックフェイルオーバーによってトラフィックを自動的に切り替えます。RTO は通常 15 分未満です。Warm Standby は、ビジネスクリティカルなアプリケーションで最も一般的な DR ティアです。
# Production vs Warm Standby capacity:
# Tier Production DR Standby
# Web servers 20 EC2 (c5.xl) 2 EC2 (c5.xl)
# App servers 10 EC2 (m5.xl) 2 EC2 (m5.xl)
# Database RDS db.r5.2xl RDS Read Replica (db.r5.xl)
# Cache Redis r6g.xl Redis r6g.medium
#
# Cost: DR standby ~15% of production costWarm Standby のための Aurora Global Database
Aurora Global Database は、Warm Standby DR に最適なデータベース技術です。セカンダリリージョンのクラスターは常に稼働し、常にレプリケーションを受信しており(遅延は 1 秒未満)、1 分未満でプライマリに昇格できます。これは、RDS Read Replica の昇格よりもはるかに高速です。RDS Read Replica の昇格には、レプリケーションを停止して残りの遅延を適用する必要があるためです。そのため、RTO の要件が数十分ではなく数分の範囲にある場合、Aurora Global Database が推奨されます。
# Promote Aurora Global DB secondary to primary
# (during DR failover)
aws rds failover-global-cluster \
--global-cluster-identifier my-global-db \
--target-db-cluster-identifier my-aurora-cluster-us-west-2
# Aurora handles promotion automatically
# Typical promotion time: 1-2 minutes
# vs RDS Read Replica promotion: 10-30 minutesRoute 53 の自動フェイルオーバー設定
Pilot Light と Warm Standby はどちらも、トラフィックを自動的にリダイレクトするために Route 53 failover routing に依存します。ヘルスチェックを関連付けたPrimary レコードを設定し、本番リージョンの ALB またはエンドポイントを参照させます。次に、DR リージョンのエンドポイントを参照するSecondary レコードを設定します。Route 53 が、設定したしきい値を超えてプライマリのヘルスチェックに失敗したことを検知すると、プライマリレコードの返却を停止し、セカンダリレコードのみを返すようになります。これは DNS TTL の期間内に完了します。
# Primary record (production)
aws route53 change-resource-record-sets \
--hosted-zone-id ZXXX \
--change-batch '{
"Changes": [{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "api.example.com",
"Type": "A",
"Failover": "PRIMARY",
"SetIdentifier": "primary",
"HealthCheckId": "hc-us-east-1",
"AliasTarget": {"DNSName": "alb-prod.us-east-1.elb.amazonaws.com","EvaluateTargetHealth": true}
}
}]
}'DR 環境の事前ウォームアップ
Warm Standby で目標 RTO を達成するには、DR 環境を事前にウォームアップしておく必要があります。つまり、フェイルオーバー時にスケールアップするだけで済むよう、環境を完全に構成し、テストしておきます。具体的には、データベース接続を確立してキャッシュし、アプリケーション設定ファイルで DR リージョンのエンドポイントを参照し、EC2 インスタンスを(台数が少ない状態でも)ALB の背後でサービス提供状態にし、ヘルスチェックをパスさせます。本番環境の設定を最新の状態に保つため、毎月 DR 訓練を実施し、フェイルオーバーをシミュレーションしてください。
# Validate DR warm standby health
# 1. Check DR ALB target health
aws elbv2 describe-target-health \
--target-group-arn arn:aws:elasticloadbalancing:us-west-2:123:targetgroup/app-dr/xyz
# 2. Check Aurora Global DB secondary
aws rds describe-global-clusters \
--global-cluster-identifier my-global-db
# 3. Verify Route 53 health checks
aws route53 get-health-check-status \
--health-check-id hc-us-west-2DR の一貫性を保つ Infrastructure as Code
DR 環境を本番環境と同期させ続けることは、運用上最も難しい課題です。本番環境を手動で設定し、DR の更新を忘れると、実際の災害時に DR 環境が正しく機能しない可能性があります。解決策は、両方のリージョンに同じテンプレートをデプロイするInfrastructure as Code(IaC)です。AWS CloudFormation StackSets またはTerraform with multiple workspacesを使用し、単一のコードベースから両リージョンに同一のインフラストラクチャをデプロイします。これにより、構成のドリフトを防止できます。
# CloudFormation StackSet: deploy to multiple regions
aws cloudformation create-stack-set \
--stack-set-name my-app-infrastructure \
--template-url https://s3.amazonaws.com/mybucket/template.yaml
# Deploy to DR region
aws cloudformation create-stack-instances \
--stack-set-name my-app-infrastructure \
--accounts 123456789012 \
--regions us-west-2 \
--parameter-overrides \
ParameterKey=DesiredCapacity,ParameterValue=2コスト比較:Pilot Light と Warm Standby
この 2 つの戦略には、大きなコスト差があります。Pilot Light では、通常プライマリ DB のコストの 50~100% に相当するデータベースレプリカと、DR リージョンの最小限のネットワーク費用だけがかかります。アプリケーションサーバーは停止しているため、EC2 の費用は発生しません。Warm Standby では、縮小構成の EC2 インスタンス、ALB、場合によっては小規模なキャッシュクラスターの実行費用が追加されます。通常、本番環境全体のコストの 15~30% 程度です。重要なのは、Warm Standby のより短い RTO が、継続的に発生する高いコストに見合うかどうかです。
# Example monthly cost comparison:
# Production environment: $10,000/month
# Pilot Light DR:
# RDS Read Replica: $500/month
# Minimal networking: $50/month
# Total: $550/month (~5.5% of production)
# Warm Standby DR:
# RDS Read Replica: $500/month
# 2x EC2 instances: $400/month
# ALB + networking: $200/month
# Total: $1,100/month (~11% of production)フェイルバック:プライマリへの復帰
プライマリリージョンが復旧したら、そこへ戻すためのフェイルバック計画が必要です。フェイルバックは、DRで最も難しい部分になることがよくあります。障害発生中にDRリージョンで新しいデータが処理されている可能性があり、それをプライマリへ同期し戻す必要があるためです。データベースでは、DRからプライマリへの逆レプリケーションを設定するか、再同期が必要になる場合があります。Route 53では、ヘルスチェックを設定したプライマリレコードを復元します。フェイルオーバーと同じように、フェイルバックの手順も入念に計画し、テストしてください。
# Failback procedure steps:
# 1. Restore primary region infrastructure
# 2. Set up replication from DR to primary
# (reverse replication to sync new data)
# 3. Verify data consistency
# 4. Re-enable primary Route 53 health check
# 5. Gradually shift traffic back (weighted routing)
# Route 53 weights: Primary=10%, DR=90%
# Primary=50%, DR=50%
# Primary=100%, DR=0%
# 6. Decommission DR region back to standby capacityPilot Light と Warm Standby の選び方
次の場合はPilot Lightを選択します。RTOが30~60分を許容し、DRコストを最小限に抑えたい場合です。主なリスクは、災害発生時のプレッシャーの中でアプリケーションサーバーを起動して設定するのに必要な時間です。次の場合はWarm Standbyを選択します。RTOで15分以内の復旧が求められる場合、アプリケーションが複雑で災害時に新規起動するのがリスクになる場合、または顧客とのSLAでより迅速な復旧が求められる場合です。中程度の重要度を持つ本番ワークロードの多くでは、Warm Standbyが適切なバランスです。
# Decision guide:
# RTO > 1 hour: Backup and Restore
# RTO 30-60 min: Pilot Light
# RTO 5-15 min: Warm Standby
# RTO < 5 min: Multi-Site Active-Active
# Additional factors for Warm Standby:
# - Complex application startup procedures
# - Contractual SLA commitments to customers
# - High revenue loss per minute of downtime
# - Regulatory requirements for fast recoveryクイックチェック
このレッスンで学んだAWS Solutions Architect (SAA-C03)の概念について、理解度を確認しましょう。
レッスンのまとめ
このレッスンでは、Pilot LightではDRでデータベースのみを稼働させ、フェイルオーバー時にアプリケーションサーバーを起動すること、Warm Standbyでは縮小した完全な環境を稼働させ、フェイルオーバー時にスケールアップすること、そしてInfrastructure as Codeによってプライマリ環境とDR環境の設定ドリフトを防げることを学びました。フェイルオーバーだけでなく、フェイルバックの手順も必ず計画してテストしてください。次は、DynamoDB Global TablesとRoute 53を使用したマルチサイトのアクティブ-アクティブ構成について学びます。
よくある質問
「パイロットライトとウォームスタンバイ」レッスンは無料ですか?
はい。「パイロットライトとウォームスタンバイ」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、Cloud & IT Cert Prepコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Cloud & IT Cert Prepコースには全4レッスンが含まれています。
「パイロットライトとウォームスタンバイ」で何を学びますか?
ワークロードの最小限の中核を第2のリージョンで稼働させるパイロットライト、または縮小された完全稼働可能なコピーであるウォームスタンバイを維持し、拡張に備えます。 ブラウザで直接実行するハンズオンコードでCloud & IT Cert Prepを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
Cloud & IT Cert Prepを始めるのに経験は必要ですか?
事前経験は必要ありません。CoddyKitのCloud & IT Cert Prepは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン3/4です。
「パイロットライトとウォームスタンバイ」レッスンにはどのくらい時間がかかりますか?
ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このCloud & IT Cert Prepレッスンでコードを書いて実行できますか?
はい。すべてのCloud & IT Cert Prepレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。
このコースのすべてのレッスン
- RTO、RPO、DRティア
- バックアップと復元
- パイロットライトとウォームスタンバイ
- Global TablesとRoute 53によるマルチサイト・アクティブ-アクティブ