AWS上でWebサイトを運用し、CDNやWAFを導入していれば、アクセス集中やWeb攻撃への備えを強化できます。
しかし、CDNやWAFは、障害が発生したサーバーや失われたデータを復旧するためのバックアップではありません。
また、バックアップを取得していても、本番環境と同じAWSリージョンにしか保存していない場合、障害や災害の影響によって本番環境とバックアップの両方を利用できなくなる可能性があります。
今回紹介する教育機関サイトでは、既存のCDN・WAFサービスを活かしながらAWS上にWebサイトの運用環境を構築し、さらに通常利用するリージョンとは別の大阪リージョンにもバックアップ（AMIバックアップ）を保管しました。
本記事では、この事例をもとに、バックアップを別リージョンにも保管した理由と、障害時に実際に復旧するために考えておきたいポイントを解説します。
目次
AWSのバックアップを同じリージョンだけに置くリスク
AWSでは、サーバーやデータベースなどのサービスを提供する地理的な領域を「リージョン」と呼びます。AWSのリージョンは、それぞれ独立した地理的領域として設計されており、日本では東京リージョンと大阪リージョンが提供されています。
各リージョンの中には、独立した複数の「アベイラビリティーゾーン（AZ）」があります。
そのため、特定のサーバーや一つのAZで障害が発生した場合には、同じリージョン内の別環境やバックアップを利用して復旧できる場合があります。
一方で、本番環境とバックアップを同じリージョンだけに置いていると、そのリージョン内の複数設備やサービスが影響を受けた際に、バックアップも利用できなくなる可能性があります。
AWS上のリソースが別のリージョンへ自動的に複製されるとは限らないため、別リージョンにも復旧用データを残したい場合は、対象となるサービスに応じてリージョン間の複製やバックアップを設計する必要があります。
障害の範囲によって、備え方を分けて考えることが重要です。
| 障害の範囲 | 主な例 | 備え方の例 |
| サーバー単体 | OS障害、サーバーの不具合、データ破損 | 通常のバックアップ |
| 一部設備 | 特定AZやサービスの障害 | 同一リージョン内の冗長化・分散 |
| より広い範囲 | 複数設備やサービスへの影響、災害など | 別リージョンへのバックアップや復旧環境 |
「バックアップを取得しているか」だけではなく、「本番環境と同時に影響を受けない場所にも残しているか」まで確認する必要があります。
CDNやWAFだけでは、障害からWebサイトを復旧できない
CDNは、Webサイトのコンテンツを複数の配信拠点に一時保存し、利用者へ配信する仕組みです。
キャッシュされたコンテンツをCDN側から返すことで、すべてのリクエストを元のWebサーバーで処理する必要がなくなり、アクセス集中時の負荷を抑えられます。例えばAmazon CloudFrontでも、キャッシュを利用してオリジンサーバーへのリクエストを減らす仕組みが提供されています。
WAFは、Webサイトへの通信を確認し、不正なリクエストを検知・遮断する仕組みです。AWS WAFでは、IPアドレスやアクセス頻度、通信内容などを条件として、Webリクエストを許可・遮断するルールを設定できます。
一方、CDNやWAFは、障害が発生したサーバーやデータを元に戻すための仕組みではありません。
それぞれの役割は次のように異なります。
| 対策 | 主に備えるリスク |
| CDN | アクセス集中、配信負荷 |
| WAF | Web経由の攻撃 |
| 通常のバックアップ | サーバー障害、データ破損、操作ミス |
| 別リージョンバックアップ | 通常利用するリージョンの環境を使えない場合 |
CDN上にキャッシュされたページが表示され続ける場合があっても、CDNをWebサイトのバックアップとして扱うことはできません。
CDNには、CMSの設定やデータベース、非公開ファイル、サーバー設定など、Webサイトの運用環境を復旧するために必要な情報がすべて保存されているとは限らないためです。
「ページを配信できること」と「Webサイトの運用環境を復旧できること」は分けて考える必要があります。
教育機関サイトのAWS環境構築で、バックアップ構成も見直した
ある教育機関では、受験情報や在学生向け情報を掲載する公式Webサイトを運営していました。
入試や合格発表などの時期には、通常時よりもアクセスが集中する可能性があります。そのため、既存のCDN・WAFサービスを継続利用しながら、AWS上に新しいWebサイト運用環境を構築しました。
CMSでは静的なWebコンテンツを生成し、公開用のWebサーバーへ反映する構成を採用しています。
また、公開WebサーバーとCMSサーバーを分離しました。これにより、CMS上での更新処理や設定変更、負荷の増加が公開サイトへ直接影響しにくい構成としています。
この構成によって、アクセス集中やWeb経由の攻撃、CMS側の処理が公開サイトへ与える影響には備えられます。
一方、AWS環境の構成を検討するなかで、通常利用するリージョンだけにサーバーとバックアップを置いた場合のリスクが残りました。
本番環境とバックアップが同じリージョンにあると、障害や災害の影響範囲によっては、両方を利用できなくなる可能性があります。
バックアップを取得していても、必要なときにそのデータへアクセスできなければ復旧には使用できません。
そこで、通常のサーバー障害に備えるバックアップに加えて、通常利用するリージョンとは別の場所にも復旧用データを残すことにしました。
大阪リージョンに1日1回、3世代のバックアップを保管
今回の構成では、通常利用するAWSリージョンとは別に、大阪リージョンにもバックアップを保管しました。
バックアップの対象は、Web／CMSサーバー上のデータと、CMSで利用するデータベースです。
1日1回バックアップを取得し、大阪リージョン側に直近3世代を保管します。
通常リージョン内のバックアップだけに依存せず、離れたリージョンにも復旧用データを残すことで、本番環境とバックアップが同時に影響を受けるリスクを抑えました。
AWSにも、対応するリソースのバックアップを別のAWSリージョンへコピーする仕組みがあります。通常環境とは異なるリージョンへバックアップを保管することは、障害や災害に備えて復旧手段を増やす方法の一つです。
今回の構成は、次のように分けられます。
通常利用するリージョン
- 公開Webサーバー
- CMSサーバー
- データベース
- 通常の障害復旧に利用するバックアップ
大阪リージョン
- Web／CMSデータのバックアップ
- データベースのバックアップ
- 1日1回取得
- 直近3世代を保管
1日1回のバックアップでは、障害が発生した時刻によって、前回のバックアップ取得以降に更新されたデータが失われる可能性があります。
また、3世代を保管することで、直近の状態だけでなく、それ以前の状態から復旧する選択肢も残せます。
例えば、データの破損に気づくまで時間がかかった場合、最新のバックアップにも破損後のデータが含まれている可能性があります。複数世代を残しておけば、破損前の状態へ戻せる可能性があります。
ただし、「1日1回・3世代」がすべてのWebサイトに適しているわけではありません。
更新頻度が高いサイトや、申込情報など失われた場合の影響が大きいデータを扱うサイトでは、より短い間隔でのバックアップや、より多くの世代を保管する必要があります。
必要な頻度や世代数は、「どの程度のデータ損失まで許容できるか」に応じて決める必要があります。
大阪リージョンのバックアップから手動で復旧し、DNSを切り替えてサイトを再開
今回の構成では、通常利用するリージョンに障害や災害が発生した場合、大阪リージョンに保管しているバックアップを利用して手動で復旧します。
大阪リージョンには1日1回、直近3世代のバックアップを保管しているため、通常利用するリージョンの環境を利用できない場合でも、大阪リージョンに残したデータから復旧できます。
復旧時は、保存しているバックアップを利用して環境を復旧したうえで、Webサイトの接続先を大阪リージョン側へ切り替えます。
主な流れは次のとおりです。
- 通常利用するリージョンの障害状況を確認する
- 大阪リージョンに保管しているバックアップから環境を復旧する
- WebサイトやCMS、データベースの動作を確認する
- DNSの接続先を復旧した環境へ切り替える
- Webサイトの公開を再開する
この構成は、障害を検知すると自動的に大阪リージョンへ切り替わる仕組みではありません。
一方で、通常利用するリージョンとは別の場所に復旧可能なバックアップを残しておくことで、通常環境を利用できない場合にも、手動で復旧してサイトを再開できるようにしています。
バックアップ頻度は、許容できるデータ損失から決める
今回のバックアップは1日1回取得しています。
そのため、障害が発生したタイミングによっては、前回のバックアップ取得後に更新されたデータが復旧できない可能性があります。
バックアップの取得頻度を考える際には、「最大でどの程度のデータ損失まで許容できるか」を決める必要があります。
AWSでは、このような「どの時点までデータを戻せればよいか」という目標をRPO（Recovery Point Objective）として整理しています。
また、障害発生からどの程度の時間でWebサイトを再開する必要があるかという目標は、RTO（Recovery Time Objective）と呼ばれます。
今回のような手動復旧では、バックアップの有無だけでなく、復旧作業とDNS切り替えを含めてどの程度の時間がかかるかも確認しておくことが重要です。
まとめ｜バックアップは「どこにあり、どう復旧するか」まで確認する
CDNやWAFは、アクセス集中やWeb攻撃に備えるための重要な対策です。
一方で、障害や災害によって通常利用するAWSリージョンを利用できなくなる場合に備えるには、別リージョンにも復旧可能なバックアップを残しておく方法があります。
今回の教育機関サイトでは、大阪リージョンにも1日1回、3世代のバックアップを保管しました。
通常利用するリージョンで障害が発生した場合は、大阪リージョンに保管したバックアップから手動で復旧し、DNSの接続先を切り替えることでWebサイトを再開できる構成としています。
今回の構成は、障害発生時に自動で別リージョンへ切り替わる仕組みではありません。そのため、バックアップを取得しているかだけでなく、
- どのリージョンにバックアップを保管しているか
- サーバーやデータベースのどこまで復旧できるか
- どの時点のデータまで戻せるか
- 復旧時にどのような作業が必要か
- DNSの切り替えを含め、復旧にどの程度の時間がかかるか
- 誰が復旧を判断し、誰が作業するか
まで確認しておくことが重要です。
なお、障害発生時に別リージョンへ自動で切り替える構成については、別の事例記事で紹介します。
現在のバックアップ先と復旧方法を確認します
バックアップを取得していても、保管先や復旧方法を把握していなければ、障害や災害が発生した際にWebサイトをどのように再開できるか判断できません。
まずは、現在の環境について次の点を確認します。
- バックアップをどのAWSリージョンに保管しているか
- Webサーバーやデータベースのどこまでがバックアップ対象か
- どのくらいの頻度で取得し、何世代を保管しているか
- 通常利用するリージョンが使えない場合、どのバックアップから復旧するか
- 復旧後にDNSなどの切り替えが必要か
- 復旧作業を誰が担当し、どの程度の時間を想定しているか
- 手動復旧で要件を満たせるか、自動切り替えまで必要か
クロジカでは、現在のAWS構成やバックアップ状況、求められる復旧時間、運用体制を確認したうえで、別リージョンへのバックアップや復旧方法を整理します。
現在のバックアップ先や障害時の復旧方法が分からない段階でもご相談いただけます。
コーポレートサイトをクラウドでセキュアに
クラウドサーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカクラウドサーバー管理の主な機能
- 導入事例
- 導入までの流れ
