クラウド

リージョンとアベイラビリティゾーンとは？違いと冗長化の考え方

2026/10/14 シリーズ「クラウド入門」 第7回 / 全9回

🤖 AIを使用して執筆

リージョンとアベイラビリティゾーン

AWS は、リージョンを互いに別の地理的な地域とし、各リージョンをほかのリージョンから切り離すよう設計している²。リージョンは互いに切り離されているので、EC2 の資源を AWS がリージョンをまたいで自動で複製することはない²。

アベイラビリティゾーン（AZ）は、リージョンの中にある区画である。AWS によれば、アベイラビリティゾーンは、それぞれ切り離され、冗長な電源、ネットワーク、接続を備えた一つ以上のデータセンターである³。ゾーンどうしは数キロメートル以上離れている。それでもすべて 100 km 以内にあり、高速で遅れの小さい専用の回線でつながっている³。各リージョンは、最低三つのゾーンでできている³。

Azure では、アベイラビリティゾーンを可用性ゾーンと呼び、リージョンの中の、物理的に分かれた一つ以上のデータセンターの論理的なまとまりと説明している⁴。ゾーンごとに電源、冷却、ネットワークが独立しているので、一つのゾーンで障害が起きても、事業者のリージョンのサービスは残りのゾーンで続く⁴。Google Cloud は、ゾーンをリージョンの中の一つの障害の単位とみなし、可用性を高めるには複数のゾーンにアプリを置くよう勧めている⁵。ただし、Google Cloud の大阪などのリージョンでは、三つのゾーンが一つか二つのデータセンターに置かれている⁵。ゾーンが必ず別の建物だとは限らない。

関係を整理すると、リージョンの中に複数のゾーンがあり、ゾーンの中に一つ以上のデータセンターがある。ただし Azure では、可用性ゾーンを持たないリージョンもある⁴。リージョンを分ければ地域ごとの災害に備えられる。ゾーンを分ければ一つのゾーンの停電や故障に備えられるが、ゾーンが別の建物かどうかは事業者やリージョンによって違う。

ゾーンを使った冗長化の仕組み

複数のゾーンに同じものを置くには、いくつかの部品を組み合わせる。

• ロードバランサー：届いた要求を、一つ以上のゾーンにある複数のサーバーに振り分ける。サーバーの状態を定期的に確かめ、正常なサーバーにだけ要求を回す⁶。異常なサーバーを見つけると要求を回すのをやめ、正常に戻れば再開する⁷。ロードバランサーそのものも、有効にしたゾーンごとに動く部分（ノード）を持つ¹。
• 台数を自動で保つ仕組み（オートスケーリング）：サーバーの状態を確かめ、止まったり異常になったりしたサーバーを置き換えて、決めた台数を保つ。需要に合わせて台数を増減もする⁸。
• データベースの予備（マルチ AZ）：AWS のデータベースのサービス RDS では、マルチ AZ の構成にすると、別のゾーンに予備のデータベースを置き、同じ内容を同期して書き続ける⁹。障害のときは予備に自動で切り替わり、予備が一つの構成では、切り替えに通常 60〜120 秒かかる¹⁰。

製品名でいえば、要求の振り分けは AWS の Elastic Load Balancing、台数を保つ仕組みは AWS の Amazon EC2 Auto Scaling、Azure の Virtual Machine Scale Sets¹¹、Google Cloud のマネージド インスタンス グループ¹² である。

ただし、Azure では、すべての資源が自動で複数のゾーンに広がるとは限らない。Azure は、一つのゾーンを選んで置く資源（ゾーン リソース）と、事業者が複数のゾーンに複製したり分散したりする資源（ゾーン冗長リソース）を分けている⁴。一つのゾーンに置いた資源は、そのゾーンが止まったときには自動では守られず、利用者が別のゾーンへ切り替える⁴。

止まってから増やすのでは間に合わない

ゾーンが止まってから、ほかのゾーンでサーバーを増やせばよいと考えるかもしれない。AWS は、それでは備えとして弱いとしている。

AWS の 2022 年の白書は、クラウドのサービスを二つの部分に分けて説明している。資源を作る、読む、変える、消す、一覧するための管理の窓口を、コントロールプレーンと呼ぶ。動いているサーバーやデータの読み書きのような、サービスの本来の働きを、データプレーンと呼ぶ¹³。新しいサーバーを起動するのはコントロールプレーンの仕事で、すでに動いているサーバーが要求に応えるのはデータプレーンの働きである。この分け方は、リージョンやゾーンと並ぶ別の切り分けで、AWS は大半のサービスをこの二つに分けている¹³。障害のときに新しいサーバーを起動するには、コントロールプレーンが動いている必要がある。

そこで AWS は、静的安定性という考え方を勧めている。障害の間に、サーバーを新しく起動するような変更をしなくても、そのまま動き続けられるように作っておく考え方である¹³。ゾーンが止まってから新しいサーバーを起動するのではなく、一つのゾーンを失っても残りのゾーンで負荷をさばけるだけの余裕を、前もって用意しておく¹³。余裕がなければ、残りのゾーンのサーバーが負荷を処理しきれなくなることがある¹³。AWS の Builders’ Library は、アベイラビリティゾーンの上にシステムを作るときに学んだ教訓の一つを、障害が起きる前に障害に備えることだとしている¹⁴。

たとえば、ふだんは二台で足りるサービスでも、一つのゾーンが止まった日に、残りのゾーンだけでその日の負荷をさばけるだけの台数を、前もって置いておくことになる。

ゾーンを分ければ足りるのか：独立の設計と、広がった障害

事業者は、ゾーンやリージョンを、互いに独立して故障するように設計している。AWS の白書は、ゾーンごとに資源を置くサービスは、各ゾーンで独立して動き、独立して故障すると書いている¹³。Google Cloud も、一般に一つのリージョンが故障しても、影響を受けるのはそのリージョンだけを使っている利用者だとしている¹⁵。ただし同じ文書は、すべてのサービスに共通する依存として、IAM のポリシーや全世界のファイアウォール規則のような全世界の設定を挙げている¹⁵。

一方、各社の公式の障害報告には、ゾーンを分けても防げなかった障害がある。原因は二つの型に分けられる。

一つ目は、リージョンのすべてのゾーンが頼る共有の部分が壊れた例である。

• AWS S3（2017 年 2 月 28 日）：データを保管するサービス S3 の担当者が、手順書に沿って少数のサーバーを外すコマンドを実行したが、入力の一つを誤り、想定より多くのサーバーを外した¹⁶。リージョンのすべての S3 のデータの所在を管理する部分が再起動を要し、その間は S3 が要求に応えられず、EC2 の新しいサーバーの起動など、S3 に頼る同じリージョンのほかのサービスも影響を受けた¹⁶。障害の状況を知らせるページの管理画面も S3 に頼っていたため、しばらく更新できなかった¹⁶。
• AWS（2021 年 12 月 7 日）：監視や認可、仮想サーバーのサービス EC2 のコントロールプレーンの一部などの基盤のサービスは、AWS 内部のネットワークにある¹⁷。主のネットワークで動くサービスの台数を自動で増やす処理が、内部のネットワークにある多数のクライアント（接続を始める側のプログラム）の想定外の動きを引き起こし、二つのネットワークの間の機器が接続の急増で混雑した¹⁷。動いていた EC2 のサーバーは影響を受けなかったが、サーバーを新しく起動したり状態を調べたりする API は誤りと遅れが増えた¹⁷。障害の状況を知らせるページを予備のリージョンへ切り替えることも、混雑に妨げられた¹⁷。

二つ目は、全世界に配られる設定が、各地の仕組みを一斉に止めた例である。

• Google Cloud（2025 年 6 月 12 日）：API の要求を受け付けるかを、利用量の上限（クォータ）などの設定と照らして判断する仕組み（Service Control）は、リージョンごとに動いている¹⁸。その設定データは、数秒で全世界に複製された。データに意図しない空の欄があり、誤りへの備えのないコードが止まり、各リージョンの仕組みが一斉に止まった¹⁸。障害の状況を知らせる仕組みもこの障害で止まり、最初の報告は約 1 時間後になった¹⁸。
• Azure Front Door（2025 年 10 月 29 日）：Azure の配信のサービス Front Door では、利用者の設定の変更そのものは正当なものだったが、二つの版の管理の仕組みをまたいで行われたため、互換性のない設定データができた。そのデータが世界中の配信の拠点に配られると、配信の仕組みに潜んでいた不具合が表に出た¹⁹。影響は協定世界時の 15 時 41 分に検証用の環境から始まり、15 時 45 分までに世界中の拠点に広がった¹⁹。Front Door は設定を段階に分けて配り、各段階でデータプレーンから正常の信号が届いてから次へ進める仕組みを持っていた¹⁹。この設定では不具合が約 5 分遅れて表に出たので、検査を通り抜けて大半の拠点に届いていた¹⁹。

ここから二つのことがいえる。一つは、コントロールプレーンとデータプレーンは別々に止まりうることである。2021 年の AWS の障害では、動いているサーバーは無事だったが、新しく起動するためのコントロールプレーンが乱れた¹⁷。前もって余裕を置いておく静的安定性は、この場合に効く¹³。もう一つは、全体が頼る共有の部分や、全体に配られる設定が壊れると、ゾーンを分けても一緒に止まることである。全世界に配られる設定が壊れれば、リージョンを分けても防げない。Google は、データを全世界で一度にそろえる業務上の必要があっても、複製は少しずつ広げ、確かめる時間を取る必要があると書いている¹⁸。ただし Azure の障害では、段階を分けて確かめる仕組みがあっても、遅れて現れる不具合は止められなかった¹⁹。

この型の障害は、利用者の側では防ぎにくい。利用者にできるのは、障害に気づく手段を同じ事業者の上だけに置かないことである。2025 年の Google の障害では、Google Cloud の上で監視の仕組みを動かしていた一部の利用者は、監視も止まり、障害が起きたことすら分からなかった¹⁸。

どこまで備えるか

備えには費用がかかる。ゾーンを増やせばサーバーが増え、リージョンを増やせばデータの複製や切り替えの手間も増える。どこまで備えるかは、止まったときにどれだけ困るかで決める。AWS の白書も、復旧の備えの費用が障害で失うものより大きければ、規制などの理由がない限り備えを置かないよう勧めている²⁰。

その目安として、二つの数字がよく使われる。同じ白書によれば、目標復旧時間（RTO）は、サービスが止まってから復旧するまでに許せる最大の時間である²⁰。目標復旧時点（RPO）は、障害が起きた時点と、最後に保存してあったデータの時点の間に許せる最大の時間で、どれだけのデータを失ってもよいかを表す²⁰。

デジタル庁の、国の情報システム向けの指針は、災害への備えを四つの形に分けている²¹。市の情報システムは対象ではないが、指針は、地方公共団体がガバメントクラウドの利用を検討する場合にも参考にするよう求めている²¹。

• リージョン全域の災害は想定せず、部分的な障害に備えるマルチゾーンの形（一つのリージョン）
• リージョン全域の災害に備え、データだけをリージョンの外に保管するバックアップの形
• 災害用のリージョンに最小限の構成を置いておき、災害のときはそこで動かし続けるウォームスタンバイの形（二つのリージョン）
• 費用をかけても二つのリージョンで同時に動かし続けるアクティブ-アクティブの形

職員向けのシステムや一部の国民向けのサービスは前の二つが基本で、止まると国民の生活に影響する広く国民向けのサービスだけが後の二つを想定する、とする²¹。複数の事業者を使う災害への備え（マルチクラウド）は、費用対効果が特に悪いので、原則として選ばないとしている²¹。

災害のときにこそ使われるサービスでは、リージョン全域が被災したとき、データを外に保管しておいて後から作り直すのか、別のリージョンにすぐ動かせる構成を置いておくのかが、判断の分かれ目になる。前者は費用が小さいが、作り直すまでの間はサービスが止まる。一方、職員向けの庶務のシステムなら、マルチゾーンで足りるかもしれない。

Amazon の最高技術責任者（CTO）の Vogels は 2016 年、故障は避けられないもので、ルーターからディスクまで、すべてはいずれ壊れると書き、故障の影響が及ぶ範囲を管理する技術を磨いてきたと述べている²²。ゾーン、リージョン、余裕の台数は、この範囲を区切るための道具である。

ただし、備えを厚くするほど、請求も増える。止まらないためのサーバーも、使わずに待っている時間の分まで料金がかかる。クラウドの料金はどう決まり、どう抑えればよいのかが、次の問いである。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。