AWSを利用してシステムを構築する際、高い可用性を確保するためには、同一リージョン内（例えば東京リージョンのみ）で複数のアベイラビリティゾーン (AZ) を活用することが一般的です。しかし、非常に稀とはいえ、リージョン全体に影響を及ぼすような大規模障害が発生するリスクはゼロではありません。

そうしたリージョン規模での障害の影響を最小限に食い止め、ビジネスの継続性を担保するためのアーキテクチャが「マルチリージョン構成」です。

本記事では、AWSにおけるマルチリージョン構成の一般的なパターンを整理するとともに、多くのシステムで採用されているウェブ三層構成（Web / App / DB）を前提に、WordPressなどの具体的な構成例をイメージしながら、最適なデータベースの選定方法について解説します。

1. 復旧目標を定める2つの指標（RPO と RTO）

マルチリージョン構成を検討する上で、真っ先に検討すべきなのが以下の2つの指標です。

• RPO (Recovery Point Objective: 復旧時点目標)
  「障害発生時に、どの時点までのデータ損失を許容できるか」を示す指標です。「数時間前のバックアップまで戻ればよい」のか、「直前のアクセスデータも極力失いたくない（数秒以下の損失に留める）」のかによって構成が大きく変わります。
• RTO (Recovery Time Objective: 復旧時間目標)
  「障害発生から、システムが再び利用可能になるまでの許容時間」を示す指標です。「数日かけて復旧すればよい」のか、「数分以内に自動で切り替わればよい」のかを定義します。

一般的に、「要件を高く（損失0、ダウンタイム0に）すればするほどシステム構成は複雑化し、コストが跳ね上がる」と言われています。しかし、ここで言う「コスト」には、AWSの 「クラウドリソース利用料」 だけでなく、システムの 「初期構築コスト」 や、有事のリカバリ対応および定期的な切り替え訓練にかかる 「運用保守工数（人的コスト）」 など多面的な要素が含まれます。

たとえば、最も可用性の高い「Active-Active」構成を採用した場合、クラウドリソース利用料こそ高くなりますが、フェイルオーバーが自動化（あるいは極めて単純化）されるため、Pilot Light構成などに比べて 運用保守の人的コストが下がる という傾向があります。そのため、単なる「クラウド利用料の比較」ではなく、「自社のサービスと運用体制に見合った総合的なコスト構造はどれか」を見極めることが非常に重要です。

2. 実践的な3つのAWS構成パターンの比較

AWSのディザスタリカバリ (DR) 戦略（詳細はAWS公式ホワイトペーパーを参照）では、システムの重要度に応じて 「Backup & Restore」「Pilot Light」「Warm Standby」「Multi-site Active/Active」 の4段階の戦略が提示されています。

本記事では、このうちシステムの要件定義において概念の境界が明確で、比較検討の軸にされやすい 「Backup & Restore」「Pilot Light」「Active-Active」 の3つのパターンに絞り、それぞれの特徴とコスト構造の違いを整理します。

※「Warm Standby」は、待機系でもアプリケーションを最小限の縮退構成で稼働させておく手法ですが、機能的には「RTOを短縮したPilot Light」という位置づけであり、Active-Activeのようなフェイルオーバー完全自動化のメリットとは性質が異なるため、本記事の詳細な比較からは割愛しています。

Backup & Restore

東京リージョンにあるデータをS3などを経由して大阪リージョンへ定期的にコピーしておく最もシンプルな構成です。平時の待機系リソースはゼロで済むためコストは最小ですが、いざという時にはVPCからEC2、RDSまですべてを新規に構築・復元する必要があり、復旧には時間を要します。

Pilot Light

小規模な「種火」（パイロット・ライト）だけを待機系リージョンで燃やし続ける構成です。

具体的には、データの復元に最も時間と手間がかかるデータベース (RDSなど) だけはクロスリージョン・リードレプリカ等を利用してあらかじめ同期・稼働させておきます。一方、EC2などのアプリケーション層はAuto Scaling Groupの「希望する容量」を0にしておくなど、停止状態で定義のみ配置しておきます。

障害発生時には、DBをマスターに昇格させた後、アプリケーションのサーバを起動してトラフィックを受け付けるため、比較的中庸なコストと復旧時間が特徴です。ただし、 「平時に稼働していない待機系のアプリケーションがいざという時に確実に起動するか」 という、本番環境（東京リージョン）との設定の乖離(かいり)に伴う起動失敗のリスクに備え、継続的な切替訓練が必要です。

Active-Active (Multi-site Active/Active)

両方のリージョンでアプリケーションもデータベースも完全に立ち上げておき、平常時からRoute 53のレイテンシーベースルーティング等を用いてトラフィックを両リージョンに分散させる構成です。

片方のリージョンがダウンした場合、ヘルスチェックによって自動的に切り離され、正常なリージョンへ全トラフィックが流れるため、 RTOは実質的に数分以内（DNSの切り替え時間のみ） となります。

コストは倍増しますが、常に両リージョンが本番として稼働しているため、「いざという時に切り替わらない」というシステム上の不安を取り除くことができる堅牢な構成と言えます。

3. DBレプリケーション方式の選択

構成パターンを決める上で、システムの中核となるリレーショナルデータベース（MySQL）をどのようにリージョン間で同期させるかが最大の設計ポイントになります。

ここで比較対象となるのが、 「RDS for MySQL (クロスリージョン Read Replica)」 と 「Aurora Global Database」 です。

なぜ Active-Active では Aurora Global Database が必要なのか？

Pilot Light構成であれば、待機側のリージョンは平常時は「読み取り」すら行われないため、安価な RDS for MySQL のクロスリージョンリードレプリカで十分事足ります。

しかし、「Active-Active」構成とする場合、大阪（Secondary）のWebサーバにもユーザーからのアクセスが発生します。WordPressなどのCMSでは、ユーザーが単にページを閲覧しているだけでも、セッション情報の更新やログイン処理などの「書き込み処理 (UPDATE/INSERT)」が発生する仕様になっています。
通常のRDSのクロスリージョンレプリカは読み取り専用であるため、大阪のWebサーバから書き込もうとするとエラーになってしまいます。

ここで活躍するのが Aurora Global Database の 「Write Forwarding (書き込み転送)」 機能です。
この機能を有効にしておくと、Secondaryリージョン（大阪）のアプリーケーションがローカルのDBに対して通常のINSERT/UPDATEクエリを投げた際、Aurora側が自動的にそれをPrimaryリージョン（東京）に転送し、処理を行って書き込みを完了させます。
アプリケーション側（WordPress）に「書き込みは東京に向け、読み込みは大阪に向ける」といった複雑な改修を入れることなく、Active-Active環境を成立させることが可能になる画期的な機能です。

※なお、ネットワークの物理的な限界があるため、Write Forwarding による書き込み時にはリージョン間の往復遅延 (RTT) が付与されます。しかし、WordPressのような書き込み頻度がそこまで過密でないライトなワークロードであれば、運用のシンプルさに勝る実用的な落としどころとなります。

4. まとめと次回予告

本記事では、AWSにおけるマルチリージョン戦略のうち、Webアプリケーションで採用されやすい3つのパターンと、それを支えるデータベースの選定ルールを整理しました。

• コストを抑えて災害対策を行いたい場合は、 Pilot Light と RDS for MySQL の組み合わせが有力です。
• 予算をかけてでもダウンタイムを最小限（自動復旧）にしたい場合は、 Active-Active と Aurora Global Database の構成が最適解となります。

次回の記事では、この解説の中で最も高度かつ可用性の高い 「Active-Active + Aurora Global Database」 の手法を用いて、実際に東京 / 大阪リージョン間でWordPressを構築し、リージョン障害を想定したフェイルオーバー試験を行った結果に基づき、具体的なアーキテクチャ図や復旧までにかかる時間（RTO）などを公開します。ぜひご期待ください。