333-AWS SAP AWS 「理論・実践・一問道場」バックアップとリストア

type

status

date

slug

summary

理論

AWSにおける災害復旧（Disaster Recovery, DR）戦略の概要

AWSでは、ビジネス要件に応じた災害復旧（DR）戦略を構築するためのさまざまなサービスとアプローチが提供されています。以下では、コスト、復旧時間目標（RTO）、および復旧時点目標（RPO）に基づく主要なDR戦略を解説します。

1. バックアップとリストア (Backup and Restore)

概要: 必要なデータを定期的にバックアップし、障害発生時に復元する。

特徴:

コスト: 非常に低い（バックアップストレージのみ）
RTO: 数時間～1日
RPO: バックアップ間隔次第（例: 8時間ごと）

使用するAWSサービス:

Amazon S3（バックアップストレージ）
AWS Backup（自動化されたバックアップ管理）

2. パイロットライト (Pilot Light)

概要: 必要最低限のリソースを稼働状態にしておき、障害時に迅速にスケールアップする。

特徴:

コスト: 低～中（最小限のリソースのみ稼働）
RTO: 数時間
RPO: 最小限（レプリカを活用）

使用するAWSサービス:

Amazon RDS（クロスリージョンリードレプリカ）
AWS Auto Scaling（リソーススケールアップ）

3. ウォームスタンバイ (Warm Standby)

概要: セカンダリリージョンで縮小された形で本番環境を稼働させ、障害時に完全稼働に切り替える。

特徴:

コスト: 中（縮小された環境の維持が必要）
RTO: 数分～数時間
RPO: レプリケーション頻度に依存（ほぼゼロも可能）

使用するAWSサービス:

Amazon EC2（縮小構成での常時稼働）
Elastic Load Balancer（DNS切り替え）

4. マルチサイト (Multi-Site Active-Active)

概要: 複数のリージョンで本番環境を常時稼働させる。

特徴:

コスト: 高（複数のフル環境を維持）
RTO: ほぼゼロ
RPO: ほぼゼロ（同期レプリケーション）

使用するAWSサービス:

Amazon Route 53（トラフィック分散）
AWS Global Accelerator（低レイテンシ接続）

効果的な災害復旧の構築に必要な要素

データの保護

Amazon S3を利用したデータバックアップとクロスリージョンレプリケーション。

Amazon RDSのスナップショットとリードレプリカ。

リソースのプロビジョニング

AWS CloudFormationを利用してリソースを自動デプロイ。

Auto ScalingやAWS Lambdaを活用して障害時に迅速にリソースをスケールアップ。

DNS管理

Amazon Route 53を使用したフェイルオーバーとトラフィックルーティング。

具体例: パイロットライト戦略の構築

構成:

プライマリリージョンでフル稼働のアプリケーション。
セカンダリリージョンで最小限のリソース（例: リードレプリカ、スケールダウンしたインスタンス）。

障害発生時の手順:

リードレプリカをプライマリに昇格。

Auto Scalingポリシーでインスタンスを増加。

DNS（Route 53）をセカンダリリージョンに切り替え。

まとめ

AWSの災害復旧戦略は、コストと復旧速度のバランスを考慮して選択することが重要です。

上記のような戦略を理解し、適切なAWSサービスを組み合わせることで、効率的かつ信頼性の高いDR環境を構築できます。

実践

略

一問道場

Question #333

ある企業が、コミュニティフォーラムサイトをホストしています。このサイトは、**Application Load Balancer（ALB）**と、Amazon ECS クラスターでホストされている Docker アプリケーションを使用しています。

サイトデータは Amazon RDS for MySQL に保存されており、コンテナイメージは Amazon ECR に保存されています。同社は、災害復旧（DR）に関する SLA を顧客に提供する必要があり、以下の要件を満たす必要があります：

RTO（復旧時間目標）：24時間以内

RPO（復旧時点目標）：8時間以内

次のうち、要件を満たす最もコスト効率の高い方法はどれですか？

AWS CloudFormation を使用して、2つのリージョンに同一の ALB、EC2、ECS、および RDS リソースをデプロイします。

8時間ごとに RDS スナップショットをスケジュールします。RDS のマルチリージョンレプリケーションを使用して、セカンダリリージョンにデータベースを更新します。障害が発生した場合、最新のスナップショットから復元し、Amazon Route 53 の DNS フェイルオーバーポリシーを使用して顧客をセカンダリリージョンの ALB に自動的にリダイレクトします。

Docker イメージを 2つのリージョンの ECR に保存します。8時間ごとに RDS スナップショットをスケジュールし、スナップショットをセカンダリリージョンにコピーします。障害が発生した場合、AWS CloudFormation を使用してセカンダリリージョンに ALB、EC2、ECS、および RDS リソースをデプロイし、最新のスナップショットから復元し、DNS レコードをセカンダリリージョンの ALB に更新します。

AWS CloudFormation を使用して、セカンダリリージョンに同一の ALB、EC2、ECS、および RDS リソースをデプロイします。RDS MySQL のバックアップを毎時 Amazon S3 に保存し、クロスリージョンレプリケーションを使用してデータをセカンダリリージョンのバケットにレプリケートします。障害が発生した場合、最新の Docker イメージをセカンダリリージョンの Amazon ECR にインポートし、EC2 インスタンスにデプロイし、最新の MySQL バックアップを復元して、DNS レコードをセカンダリリージョンの ALB に更新します。

セカンダリリージョンに パイロットライト環境 をデプロイします。この環境には、ALB と最小リソースの EC2 デプロイメント（スケーリングポリシー付き AWS Auto Scaling グループでノード数とインスタンスサイズを増やす設定）を含みます。RDS データのクロスリージョンリードレプリカを作成します。障害が発生した場合、レプリカをプライマリに昇格し、DNS レコードをセカンダリリージョンの ALB に更新します。

解説

正解が B とのことなので、その理由を分析します。

B. 解説

内容:

Dockerイメージ: 2つのリージョンのECRに保存。
RDSスナップショット: 8時間ごとに取得し、セカンダリリージョンにコピー。
障害発生時:

CloudFormationでリソース（ALB、ECS、RDSなど）をセカンダリリージョンにデプロイ。
RDSスナップショットを復元。
DNSを更新してALBにルーティング。

このアプローチの強み

コスト効率:

セカンダリリージョンでは平常時にリソースを稼働させないため、運用コストを抑えられる。

パイロットライトのように最小限のリソースを維持する必要がなく、完全に停止状態。

RPO（8時間以内）:

8時間ごとのRDSスナップショットとそのクロスリージョンコピーにより、データ損失を8時間以内に抑える。

RTO（24時間以内）:

CloudFormationを使用することで、障害時に必要なリソースを迅速にプロビジョニング可能。

作業が自動化されており、運用負荷も低い。

D.（パイロットライト）との比較

比較項目	B（正解）	D（パイロットライト）
コスト	セカンダリでリソース未稼働 → コスト効率が非常に高い	最小リソースを常時稼働 → Bよりコストが高い
RTO（復旧時間）	リソース構築に時間がかかる可能性（CloudFormation依存）	既にパイロット環境が稼働 → 短時間で切り替え可能
RPO（データ損失）	スナップショットコピーに依存（最大8時間の損失可能性）	クロスリージョンリードレプリカ → データ損失が少ない