🍽️ AWS災害復旧戦略

レストランチェーンの災害対応で理解する超入門ガイド

🔥 火事になった時、どう営業を続ける?

AWSの災害復旧戦略を、人気レストランチェーンの災害対応で分かりやすく説明します!

📊 まず理解しよう:RPOとRTO

📅

RPO(Recovery Point Objective)

データ損失許容時間


🍕 レストランの例

「何時間前までの 注文履歴 なら失っても大丈夫?」


RPO = 1時間
→ 1時間前までの注文データを失ってもOK

RPO = 0分
→ 1つの注文も失ってはダメ

RTO(Recovery Time Objective)

復旧時間目標


🍕 レストランの例

「災害から何時間で 営業再開 する?」


RTO = 24時間
→ 1日以内に営業再開

RTO = 5分
→ 5分以内に営業再開

🚨 災害発生!レストランはどう対応する?

🔥 緊急事態:本店が火災で営業不可能に!

人気レストラン「AWS亭」の本店が火災で使えなくなりました。
お客様への影響を最小限に抑えて営業を続けるには、どの戦略を選びますか?

💾

バックアップ&リカバリー

「保険で復旧」戦略

RPO
1時間〜24時間
RTO
24時間〜数週間

🏪 レストランの対応

完全閉店して、保険金で新店舗を建設。レシピや顧客データは定期的にバックアップ。

☁️ AWSサービス

S3、Glacier、EBS Snapshot

🕯️

パイロットライト

「最低限の準備」戦略

RPO
15分〜1時間
RTO
1時間〜24時間

🏪 レストランの対応

別の場所に小さな厨房だけ確保。災害時は急いで設備を増強して営業再開。

☁️ AWSサービス

EC2(停止状態)、RDS(スタンバイ)

🏠

ウォームスタンバイ

「縮小版で継続」戦略

RPO
5分〜15分
RTO
5分〜1時間

🏪 レストランの対応

小さな支店で常に営業中。災害時は座席を増やして本店の客を受け入れ。

☁️ AWSサービス

EC2(小さなインスタンス稼働中)、RDS(リードレプリカ)

🏢

マルチサイト
アクティブ/アクティブ

「完全冗長化」戦略

RPO
0分〜5分
RTO
0分〜5分

🏪 レストランの対応

複数の同規模店舗が常に営業。本店に問題があっても、他店舗で影響なく継続。

☁️ AWSサービス

複数リージョンでフル稼働、Route 53、ALB

📈 詳細比較:どの戦略を選ぶべき?

比較項目
バックアップ&リカバリー
パイロットライト
ウォームスタンバイ
マルチサイト
月額コスト
$100〜
$500〜
$2,000〜
$10,000〜
RPO
1時間〜24時間
15分〜1時間
5分〜15分
0分〜5分
RTO
24時間〜数週間
1時間〜24時間
5分〜1時間
0分〜5分
複雑さ
シンプル
普通
複雑
最も複雑
向いている企業
小規模
コスト重視
中規模
バランス重視
大規模
継続性重視
ミッションクリティカル
無停止要求

🍽️ 各戦略の実際の流れを見てみよう

📋 バックアップ&リカバリー戦略の場合

📊

平時:定期バックアップ

レストラン: 毎日レシピと顧客データを金庫に保管
AWS: 毎日S3にデータベースのスナップショットを保存

🔥

災害発生:一時閉店

レストラン: 火災で本店使用不可、全面的に営業停止
AWS: プライマリシステム停止、サービス一時停止

🏗️

復旧作業:環境再構築

レストラン: 新しい場所で店舗を再建、設備を新調
AWS: 新しいEC2インスタンス起動、バックアップからデータ復元

🎉

営業再開:サービス復旧

レストラン: 金庫のデータで顧客情報復元、営業再開
AWS: 最新のバックアップ時点のデータでサービス再開

⏰ 災害復旧タイムライン比較

🔥 災害発生

全戦略共通:サービス停止

📱 マルチサイト

0-5分後 :自動切り替えで即座に復旧

🏠 ウォームスタンバイ

5分-1時間後 :縮小環境をスケールアップして復旧

🕯️ パイロットライト

1-24時間後 :最小環境から本格環境を構築して復旧

💾 バックアップ&リカバリー

24時間-数週間後 :ゼロから環境を再構築して復旧

⚡ AMI・CloudFormation活用戦略

🍕 レシピと設計図で迅速復旧

AMIとCloudFormationテンプレートは、災害時の迅速復旧を可能にする「レシピ」と「設計図」です!

📦

AMI(Amazon Machine Image)

完成料理のレシピ


🍕 レストランの例

「特製ピザのレシピ」
材料、調理手順、盛り付けまで
すべて記録された完璧なレシピ


AWS: OS、アプリ、設定が
すべて組み込まれたサーバーイメージ

📋

CloudFormation テンプレート

店舗設計図


🏪 レストランの例

「店舗レイアウト設計図」
厨房、客席、設備の配置まで
詳細に記載された設計図


AWS: VPC、EC2、RDS等の
インフラ構成をコード化したテンプレート

🎯

パイロットライト戦略での活用が最適!

AMI・CloudFormationの事前作成は、主に「パイロットライト戦略」で威力を発揮します

🔄 平時 → 災害時の流れ

🕯️ 平時(パイロットライト状態)
  • ✅ AMI作成済み
  • ✅ CFテンプレート準備済み
  • ✅ RDSスタンバイ稼働
  • ❌ EC2は停止状態

月額コスト: 数千円

🔥 災害時(緊急スケールアップ)
  • 🚀 CFでインフラ自動構築
  • ⚡ AMIから高速EC2起動
  • 📈 必要台数まで自動スケール
  • ✅ 30分〜2時間で復旧

復旧時間: 大幅短縮!

📊 各戦略でのAMI・CloudFormation活用度比較

災害復旧戦略
AMI活用度
CloudFormation活用度
主な用途
メリット
💾 バックアップ&リカバリー
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
完全再構築
ゼロから確実な復旧
🕯️ パイロットライト
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
迅速スケールアップ
最も効果的!
🏠 ウォームスタンバイ
⭐⭐⭐
⭐⭐⭐
追加スケール時
既存環境の拡張
🏢 マルチサイト
⭐⭐
⭐⭐
初期構築時のみ
標準化された構築

🍕 パイロットライト:AMI活用の実例

📦

1. AMI作成(レシピ完成)

レストラン: 特製ピザのレシピを完璧に記録
AWS: Web/Appサーバーを完全設定してAMI作成
ami-webapp-v1.2.3

📋

2. CloudFormation作成(設計図完成)

レストラン: 災害時の迅速店舗再建設計図を準備
AWS: インフラ全体をコード化してテンプレート作成
disaster-recovery-template.yaml

🔥

3. 災害発生(緊急展開開始)

レストラン: 本店火災!設計図とレシピで迅速に新店舗オープン
AWS: 本番環境障害!CFテンプレートとAMIで自動復旧開始
aws cloudformation deploy --template-file disaster-recovery-template.yaml

4. 迅速復旧完了(30分〜2時間)

レストラン: レシピ通りの美味しいピザで営業再開!
AWS: 事前設定済みAMIで本番同等環境を高速構築完了
結果: データ損失最小限、復旧時間大幅短縮

💡 実装のポイント

🔄 定期更新

AMIは月1回更新してセキュリティパッチを適用

🧪 定期テスト

CFテンプレートで実際に環境構築テストを実施

🏷️ バージョン管理

AMI・CFテンプレートの世代管理で確実な運用

📊 監視・アラート

自動起動の成功/失敗を確実に検知

🛠️ 主要AWSサービスの役割

📦

Amazon S3

レストランの金庫
データのバックアップを安全に保管。99.999999999%の耐久性で大切なデータを守ります。

💻

Amazon EC2

レストランの厨房
アプリケーションが動く仮想サーバー。災害時には素早く別の場所で起動できます。

🗃️

Amazon RDS

顧客台帳
データベースを管理。自動バックアップとリードレプリカで高可用性を実現。

🌐

Route 53

道案内係
DNS設定でトラフィックを正常な環境に自動的に誘導。ヘルスチェック機能付き。

⚖️

Elastic Load Balancer

受付係
複数のサーバーに負荷を分散。1台が故障しても他のサーバーが処理を継続。

🚀

Lambda

緊急スタッフ
サーバーレスで必要な時だけ起動。災害時の自動処理や通知に最適。

💰 あなたの会社に最適な戦略を診断

下記の質問に答えて、最適な災害復旧戦略を見つけましょう!

✅ AWS災害復旧のベストプラクティス

🧪

定期的なテスト

災害復旧計画は定期的にテストして、実際に動作することを確認しましょう。

📚

文書化

復旧手順を詳細に文書化し、担当者以外でも実行できるようにしましょう。

👥

チーム体制

災害時の責任者と連絡体制を明確にし、役割分担を決めておきましょう。

自動化

可能な限り復旧プロセスを自動化し、人為的ミスを減らしましょう。

🔄

段階的改善

小さく始めて段階的に改善し、予算と要件に応じて戦略をアップグレードしましょう。

💡

継続的監視

システムの健全性を常に監視し、問題を早期発見できる体制を整えましょう。

🎯 まとめ

💡 重要なポイント

  • RPO は「どのくらいのデータ損失まで許容できるか」
  • RTO は「どのくらいの時間で復旧する必要があるか」
  • コスト 復旧要件 のバランスが重要
  • 段階的に 戦略をアップグレードしていくのがおすすめ

🚀 はじめの一歩

  1. 現在のRPO/RTO要件を明確にする
  2. バックアップ&リカバリーから始める
  3. 定期的なバックアップとテストを実施
  4. 要件に応じて段階的にアップグレード

Created by SSuzuki1063

AWS SAP Learning Resources

Created by SSuzuki1063

AWS SAP Learning Resources