--- title: "リージョンとアベイラビリティゾーン。障害に備えた配置の考え方｜アメリア・テクノロジー株式会社" url: https://www.ameliatechnology.co.jp/blog/region-availability-zone-design/ description: "リージョンはクラウドのデータセンターを置く地域、アベイラビリティゾーンはその中で電源やネットワークを分けた拠点です。AWS・Azure・Google Cloud の説明をもとに、障害の範囲ごとの配置と費用のつり合いを説明します。" updated: 2026-11-14 publisher: "アメリア・テクノロジー株式会社" --- # リージョンとアベイラビリティゾーン。障害に備えた配置の考え方 リージョンはクラウドのデータセンターを置く地域、アベイラビリティゾーンはその中で電源やネットワークを分けた拠点です。AWS・Azure・Google Cloud の説明をもとに、障害の範囲ごとの配置と費用のつり合いを説明します。 2026.11.14 [クラウドと運用](https://www.ameliatechnology.co.jp/blog/category/cloud/) 執筆 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/)（グループCTO） クラウドと運用（CLOUD & OPERATIONS）のコラム ## この記事の要点 - アベイラビリティゾーンは、同じリージョンの中で電源・冷却・ネットワークを分けたデータセンターのまとまりです - 2つ以上のゾーンに分けて置くと、1つのゾーンの障害に耐えられますが、リージョン全体の障害には備えられません - どこまで分けるかは、止まったときの業務への影響と、構成・費用・運用の重さとのつり合いで決めます リージョンとは、クラウドの事業者がデータセンターを置いている地域の単位で、アベイラビリティゾーン（ゾーン）とは、1つのリージョンの中で、電源やネットワークを分けたデータセンターのまとまりです。システムを2つ以上のゾーンに分けて置くと、1つのゾーンで障害が起きても動き続けられます。 クラウドに置いたからといって、システムが自動的に止まらなくなるわけではありません。どのゾーン、どのリージョンに、どう分けて置くかは、使う側が設計して決めることです。この記事では、障害の範囲ごとの配置の考え方を説明します。 ## リージョンとアベイラビリティゾーンとは [リージョンとアベイラビリティゾーン](https://www.ameliatechnology.co.jp/glossary/region-availability-zone/)は、クラウドの資源を置く場所を表す、大小2つの単位です。リージョンが大きな地域、ゾーンがその中の独立した拠点です。 AWS は、アベイラビリティゾーンを、AWS のリージョンの中にある、独立した冗長な電源・ネットワーク・接続を持つ1つ以上のデータセンターと定義しています。同じリージョンのゾーンどうしは、同時に障害が起きないよう最大で約100km離しつつ、同期して複製できる程度の近さに置き、発電機や冷却の設備も共有しない、と説明しています。 出典：[Availability Zones - AWS Fault Isolation Boundaries（AWS）](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html) Microsoft Azure も、多くのリージョンでアベイラビリティゾーンを提供しており、各ゾーンは独立した電源・冷却・ネットワークを持ち、ゾーンどうしは通常100km以内に置かれる、としています。Google Cloud では、リージョンは独立した地理的な地域で、ゾーンで構成される、と説明されています。 出典：[What are availability zones?（Microsoft Learn）](https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview)、[Regions and zones（Google Cloud）](https://docs.cloud.google.com/compute/docs/regions-zones) 国内には、2026年11月時点で、3社とも東京と大阪にリージョンがあります。地域の選び方と出典は[クラウド（AWS・Azure・Google Cloud）の選び方](https://www.ameliatechnology.co.jp/blog/choosing-cloud/)で触れています。 ## 1つのゾーンだけに置くと、何が起きるのか 1つのゾーンだけにサーバーを置くと、そのゾーンで電源やネットワークの障害が起きたとき、システム全体が止まります。ゾーンが、止まると全体が止まる箇所（単一障害点）になるためです。 Microsoft は、資源を1つのゾーンに置く形（ゾーン単位の配置）は、ほかのゾーンの障害からは切り離されるものの、自分のゾーンが止まったときに自動的に生き残るわけではなく、ほかのゾーンへの切り替えは利用者の責任になる、と説明しています。AWS も、複数のゾーンを使うアプリケーションは、1つのゾーンの物理的な基盤に起きた問題から守られやすくなる、としています。 出典：[What are availability zones?（Microsoft Learn）](https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview)、[Availability Zones - AWS Fault Isolation Boundaries（AWS）](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html) ## 複数のゾーンに分けて置く 止まると困るシステムは、まず同じリージョンの中の2つ以上のゾーンに分けて置くことを考えます。Microsoft は、資源が2つ以上のゾーンを使っていれば、1つのゾーンの障害に耐えられる、と説明しています。 よく使われる構成は、次のような形です。 - Web サーバーを2つ以上のゾーンに置き、[ロードバランサー](https://www.ameliatechnology.co.jp/glossary/load-balancer/)で振り分ける - データベースは、別のゾーンに待機の複製を置き、障害のときに切り替える - 台数は、負荷に応じて自動で増減させる（[オートスケーリング](https://www.ameliatechnology.co.jp/glossary/auto-scaling/)） サービスによっては、事業者が複数のゾーンへの分散を自動で受け持つものもあります。Microsoft は、こうした形をゾーン冗長と呼び、ほかのゾーンへの切り替えを Microsoft が自動で管理する、と説明しています。自分で分けて置くのか、サービスが分散してくれるのかを、使うサービスごとに確かめます。 ゾーンの間の通信の料金の扱いは、事業者によって違います。Azure は、同じリージョンのゾーンの間のデータ転送には料金がかからないと説明していますが、ほかの事業者では料金がかかる場合があるため、各社の料金のページで確かめます。 ## ゾーンでは防げない障害と、リージョンを分ける判断 アベイラビリティゾーンは、リージョン全体が止まる障害には備えられません。Microsoft も、ゾーンはリージョン全体の障害からは守らないとし、業務の中心となるシステムには、複数のリージョンと複数のゾーンを組み合わせる設計を検討するよう勧めています。 出典：[What are availability zones?（Microsoft Learn）](https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview) ただし、リージョンを分ける構成は、データの複製、切り替えの手順、両方の環境の維持が加わり、構成と費用と運用が大きく重くなります。すべてのシステムに必要なわけではありません。 判断の手がかりは、止まったときにどれだけの時間で戻す必要があるか、どの時点までのデータを戻せればよいか、という[RTO・RPO](https://www.ameliatechnology.co.jp/glossary/rto-rpo/)です。数時間の停止を許せるシステムなら、別のリージョンにバックアップを置き、障害のときに作り直す形で足りることもあります。止まると業務がすぐに止まるシステムなら、別のリージョンに待機の環境を用意する形を考えます。 リージョン全体の障害への備えは、RTO・RPO から決める - **複数のゾーンに分けるだけ**：リージョン全体が止まる障害には備えられない - **数時間の停止を許せる**：別のリージョンにバックアップを置き、障害のときに作り直す形で足りることもある - **止まると業務がすぐに止まる**：別のリージョンに**待機の環境**を用意する形を考える リージョンを分ける構成は、構成と費用と運用が大きく重くなります。すべてのシステムに必要なわけではありません バックアップと復旧の設計は、[バックアップと復旧の設計。何を、どこに、どのくらい残すか](https://www.ameliatechnology.co.jp/blog/backup-recovery-design/)で説明しています。 ## 配置を決めるときの手順 配置は、システムごとに、止まったときの影響から逆算して決めます。 1. システムごとに、止まったときの業務への影響と、許せる停止の時間を決める 2. 1つのゾーンで足りるか、複数のゾーンが要るか、別のリージョンへの備えが要るかを決める 3. 使うサービスが、ゾーンやリージョンの分散を自動で受け持つかを確かめる 4. 切り替えとバックアップからの戻しを、実際に試して時間を測る 5. 構成図と手順書に、どこに何を置いたかを残す クラウドの事業者が公表する稼働率の保証（SLA）も、複数のゾーンに分けて置くことを前提にしている場合があります。読み方は[クラウドのSLA（稼働率の保証）の読み方](https://www.ameliatechnology.co.jp/blog/cloud-sla-reading/)で説明しています。障害への備え全体の考え方は、[冗長化](https://www.ameliatechnology.co.jp/glossary/redundancy/)と[災害対策](https://www.ameliatechnology.co.jp/glossary/disaster-recovery/)の用語もご覧ください。 ## 当社のご支援 当社の[クラウドの構築と運用管理](https://www.ameliatechnology.co.jp/service/cloud/)では、システムごとの止まったときの影響を伺い、ゾーンとリージョンの配置、切り替えとバックアップの手順を設計し、構築と運用をお手伝いしています。いまの構成が1つのゾーンに偏っていないか、切り替えを試したことがあるかを確かめたい方は、クラウドの現状チェックや[クラウドの自己診断](https://www.ameliatechnology.co.jp/diagnosis/cloud/)（無料）をご利用ください。 - リージョン - アベイラビリティゾーン - 冗長化 - 災害対策 ## この記事に出てくる用語 - [リージョンとアベイラビリティゾーン](https://www.ameliatechnology.co.jp/glossary/region-availability-zone/) - [クラウド](https://www.ameliatechnology.co.jp/glossary/cloud/) - [AWS（Amazon Web Services）](https://www.ameliatechnology.co.jp/glossary/aws/) - [Microsoft Azure](https://www.ameliatechnology.co.jp/glossary/azure/) - [Google Cloud](https://www.ameliatechnology.co.jp/glossary/google-cloud/) - [サーバー](https://www.ameliatechnology.co.jp/glossary/server/) - [冗長化](https://www.ameliatechnology.co.jp/glossary/redundancy/) - [ロードバランサー](https://www.ameliatechnology.co.jp/glossary/load-balancer/) この記事を書いた人 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/) グループCTO インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。 このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。 ## あわせて読みたい - [Windowsサーバーと Active Directory を Azure へ移すときの考え方](https://www.ameliatechnology.co.jp/blog/windows-ad-to-azure/) - [Google Cloud を選ぶ場面。データ分析と Google Workspace とのつながり](https://www.ameliatechnology.co.jp/blog/when-to-choose-google-cloud/) - [Well-Architected の柱で、いまの構成を確かめる](https://www.ameliatechnology.co.jp/blog/well-architected-review/) [クラウドと運用のコラムを見る](https://www.ameliatechnology.co.jp/blog/category/cloud/) [コラムの一覧に戻る](https://www.ameliatechnology.co.jp/blog/) ## 次の一歩 ### クラウドの構築と運用を任せる AWS・Microsoft Azure・Google Cloud の設計・構築・移行から、監視・運用・セキュリティまでを一つのチームで受け持ちます。監視は仕組みで24時間365日自動に回し、原因の調査と再発の防止は当社が担います。 [クラウドの構築と運用管理を見る](https://www.ameliatechnology.co.jp/service/cloud/) ### クラウドの状態を、無料で確かめる 15の設問に答えると、構成と管理・権限・守り・障害への備え・費用と体制の5つの分野の点数と、最初に取り組むことをまとめたレポートをその場でお届けします。 [クラウドの自己診断（無料）を受ける](https://www.ameliatechnology.co.jp/diagnosis/cloud/) ## ご関心に合わせて、お選びください。 [情報を集めている方へ会社案内、AI開発の例、セキュリティ診断の報告書の見本をお送りします。資料をダウンロード](https://www.ameliatechnology.co.jp/download/)[課題が見えている方へオンラインで30分、お話をうかがいます。費用はかかりません。無料で相談する](https://www.ameliatechnology.co.jp/contact/)[進め方を決めたい方へ2〜4週間で、優先順位と計画をまとめるAI活用の診断です。診断について見る](https://www.ameliatechnology.co.jp/pricing/#diagnosis) --- 出典：アメリア・テクノロジー株式会社「リージョンとアベイラビリティゾーン。障害に備えた配置の考え方｜アメリア・テクノロジー株式会社」 https://www.ameliatechnology.co.jp/blog/region-availability-zone-design/