AWSでのマルチリージョン設計は本当に必要か？

マルチAZとマルチリージョン

AWS(Amazon Web Services)でシステム構築を行う際に、可用性を担保するための構成として、マルチAZとマルチリージョンがあります。それぞれの構成について、そもそもどのような構成なのか、どういったユースケースに適しているのかを解説していきます。

マルチAZ構成とは？

マルチAZ（Availability Zone）とは、同じリージョン内にある独立したデータセンター群にシステムの部品を分散配置する設計です。

たとえば、受付役のALBは各AZに入り口を用意し、サーバーとしてのEC2は複数AZに1台ずつ、データベースのRDSはMulti-AZ構成でスタンバイを用意します。こうすることで、AZの片側に停電が発生しても、もう片側がサービス提供を継続できます。

イメージとしては「同じショッピングモール内の別棟にもう1店舗」を構えるようなものです。片方が工事中でも、もう一方は営業できます。

ただし守備範囲は「特定データセンター（AZ）の障害」までで、リージョン全体のトラブルはカバーできません。したがって、まずはマルチAZを標準装備とし、その上で「地域全体が丸ごと停止しても稼働させたいか」を検討するのが一般的な順序です。

マルチAZ・マルチリージョンで対障害性を確保するスタイルズのAWS導入・移行サービスはこちら→

 

マルチリージョン構成とは？

マルチリージョンは、さらに広域の可用性を確保する構成です。東京と大阪のように地理的に離れた複数のリージョンにほぼ同じシステムを構築し、片方が停止してももう一方で継続運用します。

マルチリージョンの方式はコストや復旧速度の観点から、大きく3つのパターンがあります。

• パイロットライト：最小限の構成をバックアップ側のサブリージョンに配置し、データのレプリケーションやバックアップに必要な部分だけを稼働しておきます。災害時に全体を起動してさらに必要に応じてスケールアウトして本格稼働させます。コストは低い一方、復旧は遅めです。
• ウォームスタンバイ：サブリージョンも縮小構成で常時稼働させ、データもレプリケーションしておきます。切替はパイロットライトより早いですが、平常時もパイロットライトより高めのコストが発生します。
• アクティブ-アクティブ：両リージョンで同時稼働し、DNSやGlobal Acceleratorで振り分けます。復旧速度は最速ですが、設計・運用の難易度とコストは最も高くなります。

データは非同期レプリケーションが基本で、距離の都合上どうしても「若干の遅延」または「整合性の緩み」を受け入れる場面が出ます。ここがマルチAZとの大きな違いです。

マルチリージョンが必要になるのはどんな時か？

必要性は感覚ではなく、SLA/SLO・RTO・RPOといった指標で判断します。例としては以下の通りです。

• RTOが数分以内、RPOがほぼゼロ：QRコード決済など、停止が許されない基幹・決済系システム → アクティブ–アクティブ構成を検討。
• データ主権や法令要件：金融系のシステムや個人情報を取り扱うシステムなど、国や地域外にデータを出せないシステムではマルチリージョンは控えることとなります。逆に長期保管のための広域バックアップが必須なシステムは、マルチリージョン設計が選択肢になります。
• 広域災害対策：災害時伝言板など、地域全体に影響が出ても稼働が必要なシステム → 高度なBCP要件で採用。
• グローバル利用：世界的なECサイトや動画配信サービスなど世界各地から同じアプリにアクセスする場合もマルチリージョンが必要です。近いリージョンにサーバーを配置することで、低遅延も実現できます。
• 収益インパクトが極大なシステム…短時間の停止でも売上・信用に致命的影響 → コストをかけて冗長化。

一方で、社内向けや停止許容が数時間のシステムでは、まずマルチAZ＋バックアップの堅牢化（復元訓練込み）を先に満たすほうが費用対効果が高いケースが大半です。

マルチリージョンがサポートされているか

「やろうと思えば全部できる」わけではありません。AWSでは、サービスごとにマルチリージョン対応しているものと、そうでないものがあります。対応状況を把握しておくことで、設計時の検討がスムーズになります。以下に代表例を挙げます。

データベース

• Aurora Global Database：クロスリージョン読み取り・高速フェイルオーバーに対応
• RDS（MySQL/PostgreSQLなど）：クロスリージョン読み取りレプリカ構成が可能。マスターDBへの昇格も可
• DynamoDB Global Tables：マルチリージョン・マルチアクティブ構成に対応

ストレージ

• S3：CRR（クロスリージョンレプリケーション）構成が可能。バージョニングが必須で、片方向同期が基本
• EBS：スナップショットのクロスリージョンコピーが可能

ネットワーク

• Route 53：グローバル利用が可能。DNSフェイルオーバー、地理的ルーティングなどに対応
• CloudFront：グローバル配信を前提としたサービス

サーバー

• ECS/EKS/Lambda/EC2：他リージョンへの直接的な冗長構成はサポートなし。基本はリージョンごとに同構成を二重化して構築

マルチリージョンが必要となるケースを整理

意思決定をシンプルにするため、以下のステップで観点を整理します。

ステップ1…データ保存要件

EU内でのデータ保存を義務付けるGDPRなど、法的制約がある場合はマルチリージョン構成が採用できない場合があります。まず法的制約を確認しましょう。

ステップ2…システム・アプリケーションのBCP要件

停止の影響が大きい/小さい＋復旧要求が厳しい/厳しくないかを確認します。具体例を挙げると以下のような整理になりますが、RPOやRTOなどは、BCP要件に応じて具体的な値を設定するようにしましょう。

停止の影響：大 …売上・法令・信用に直結（例：決済／受注／在庫管理、対外SLAあり）

停止の影響：小 … 社内中心、短時間の代替策あり（例：社内ポータル、レポート系）

復旧要求：厳しい …RTO ≤ 15分 かつ RPO ≤ 数分

復旧要求：緩い …RTO ≥ 1時間 かつ RPO ≥ 15分

例えば、停止の影響「大」 × 復旧要求「厳しい」であれば、マルチリージョンかつアクティブ—アクティブの構成が推奨されます。逆に、停止の影響「小」 × 復旧要求「緩い」であれば、単一リージョン構成でも問題ないという判断になります。

マルチAZ・マルチリージョンで対障害性を確保するスタイルズのAWS導入・移行サービスはこちら→

 

まとめ

マルチAZは「同じ都市の別棟」での備え、マルチリージョンは「別の都市にも同じ店を持つ」備えです。まずはマルチAZを標準化し、そのうえでRTO/RPO・法令・収益影響・レイテンシといった数値と事実を基にマルチリージョンの要否を判断します。

むやみに広域化すると、コストと運用負荷は指数的に増大し、クラウドのメリットを損なう可能性があります。また、構築後はリカバリ試験や運用訓練を定期的に実施し、確実に機能させる体制を整えることが重要です。

マルチリージョン構成は高度なシステムの可用性を実現できますが、一方で検討事項も非常に多いため、導入の際には経験豊富なべンダーに相談してみるといいでしょう。