リージョン・アベイラビリティゾーン・エッジロケーションの違いとは？AWSとAzureの地理概念をオンプレ経験者向けに整理する

クラウドを使い始めたエンジニアが最初に混乱するのが「リージョン」「アベイラビリティゾーン」「エッジロケーション」という地理概念です。オンプレのシステム設計では「どのデータセンターに置くか」という発想でよかったものが、クラウドでは複数の地理的な概念が階層構造になっており、どれを選ぶかで可用性・レイテンシー・料金が大きく変わります。

この記事では、AWSとAzureの地理概念を体系的に整理し、オンプレ経験者がスムーズにクラウド設計の発想に切り替えられるよう解説します。リージョン選択の基準からマルチAZ設計の基本パターン、エッジロケーションの役割まで、現場で即使える知識を網羅します。

なぜ「地理概念」がシステム設計に直結するのか

オンプレのインフラ設計では、サーバーを置く場所は「自社データセンター」か「コロケーション施設」のどちらかがほとんどでした。拠点を複数持つ大企業なら「東京のDCと大阪のDCに冗長化」という設計を取ることもありますが、それも数か所の選択肢の中から選ぶ話です。

クラウドでは状況がまったく異なります。AWSは2026年3月時点で世界34のリージョン、各リージョンに3～6のアベイラビリティゾーン、さらにCloudFront用のエッジロケーションが世界600か所以上あります。Azureも同様に世界60を超えるリージョンを持ちます。

この「どこに置くか」という判断が、以下の3点に直結します。

・可用性: AZをまたいだ設計で単一障害点を排除できるかどうか
・レイテンシー: エンドユーザーに近い場所に置けているかどうか
・料金: リージョン間のデータ転送料が発生するかどうか

地理概念を正しく理解せずにクラウドを使い始めると、「同じリージョンのつもりが別リージョンになっていてデータ転送料が発生していた」「単一AZで運用していて障害時に止まってしまった」というトラブルに直結します。

リージョン（Region）とは

1. AWSのリージョン

AWSのリージョンとは、物理的に独立した地理的エリアです。それぞれのリージョンは完全に独立しており、あるリージョンで障害が起きても他のリージョンには影響しません。

日本に関連する主なリージョンは以下の通りです。

AWSの各サービスはリージョンごとに独立してデプロイされます。東京リージョンで作成したEC2インスタンスは、大阪リージョンからは参照できません。リージョン間でリソースを参照するには、明示的にクロスリージョン設定が必要です。

2. AzureのリージョンとRegion Pairs

AzureのリージョンはAWSと同様に地理的エリアです。ただし、Azureには「リージョンペア（Region Pairs）」という概念があり、「東日本（East Japan）」と「西日本（West Japan）」のように、同一の地理圏内でペアになったリージョンが設定されています。

Azureの特徴として、リージョンペアのうち片方で大規模障害が発生した場合、段階的なメンテナンスがペア先に影響しないよう設計されています。また、一部のサービスはリージョンペア間でデータを自動的にレプリケートします。

3. リージョン選択の3つの判断基準

リージョンを選ぶ際、現場でよく使われる判断基準は以下の3点です。

① データレジデンシー（データ所在地）
個人情報保護法・GDPRなどの規制によって、データを保存できる国・地域が制限される場合があります。日本国内のユーザーのデータを国外に出せない要件がある場合は、東京リージョンまたは大阪リージョンを選択します。

② エンドユーザーへのレイテンシー
サービスの利用者が主に日本国内にいるなら東京リージョンが最も低レイテンシーです。グローバルサービスでは複数リージョンにデプロイするマルチリージョン構成を検討します。

③ サービス提供状況と料金
AWSの新サービスはまずバージニア北部リージョン（us-east-1）で先行提供され、東京リージョンへの展開に数か月遅れることがあります。また、同一のEC2インスタンスでもリージョンによって料金が異なります（2026年3月時点で東京は米国東部より約10～15%高い傾向）。

アベイラビリティゾーン（AZ）とは

1. AWSのAvailability Zone

アベイラビリティゾーン（Availability Zone、AZ）は、リージョン内に複数設置された独立したデータセンター群です。東京リージョン（ap-northeast-1）には4つのAZ（ap-northeast-1a・1b・1c・1d）があります。

各AZは以下の条件で独立しています。

・物理的な独立: 別の建物（または建物群）にある
・電源の独立: 別々の電力供給系統を持つ
・ネットワークの独立: 専用の低レイテンシー光回線でAZ間を接続

AZ間の通信レイテンシーはミリ秒未満に設計されており、同期レプリケーションを行うデータベースのマルチAZ設計に耐えられます。

# AWSリージョン・AZの階層構造（概念図）
# ap-northeast-1（東京リージョン）
# ├── ap-northeast-1a（AZ-A）
# │   └── EC2インスタンス、RDS、ELBなど
# ├── ap-northeast-1b（AZ-B）
# │   └── EC2インスタンス、RDS（スタンバイ）、ELBなど
# ├── ap-northeast-1c（AZ-C）
# │   └── 追加のワークロード
# └── ap-northeast-1d（AZ-D）
#     └── 追加のワークロード

2. AzureのAvailability Zones

AzureのAvailability Zones（可用性ゾーン）は、AWSのAZと同様の概念で、リージョン内の独立したデータセンター施設です。ただし、AzureはすべてのリージョンでAvailability Zonesをサポートしているわけではなく、「ゾーン対応リージョン」と「ゾーン非対応リージョン」があります。

東日本リージョン（Japan East）はAvailability Zonesに対応しており、3つのゾーン（Zone 1・Zone 2・Zone 3）が利用できます。西日本リージョン（Japan West）はゾーン対応外のため、高可用性を求める場合は東日本を主用途とするのが一般的です。

3. マルチAZ設計の基本パターン

マルチAZ設計とは、複数のAZにリソースを分散して配置し、1つのAZで障害が発生しても他のAZで処理を継続できるようにする設計です。オンプレで言えば「2拠点冗長化」に相当しますが、AZはリージョン内に3つ以上あるため、2AZまたは3AZ構成を取ることが多いです。

重要なのは、「マルチAZ設定をするだけでは不十分な場合がある」という点です。たとえばAmazon RDSのMulti-AZ設定はスタンバイインスタンスへの自動フェールオーバーを提供しますが、フェールオーバーには通常60～120秒かかります。RTO（目標復旧時間）がそれより短い要件であれば、Aurora Global Databaseのような設計を検討する必要があります。

エッジロケーションとは

エッジロケーション（Edge Location）は、リージョンやAZとは別の概念で、エンドユーザーに近い場所に設置されたキャッシュ・配信拠点です。AWSではAmazon CloudFrontのコンテンツ配信に使われます。

1. AWSのエッジロケーション

Amazon CloudFrontのエッジロケーションは、2026年3月時点で世界600か所以上に設置されています。東京・大阪・名古屋・福岡・那覇など日本国内にも複数のエッジロケーションがあります。

エッジロケーションの役割は以下の2点です。

・コンテンツキャッシュ: 画像・CSS・JSファイルをユーザーの近くでキャッシュし、オリジンサーバーへのリクエストを減らす
・レイテンシー削減: 地理的に近いエッジから配信することでTCPラウンドトリップを削減する

リージョンとエッジロケーションの違いを混同しやすいのは、エッジロケーションにはコンピュート・ストレージリソースが存在しないからです。EC2やRDSはリージョン内に配置します。CloudFrontはキャッシュ機能に特化した別レイヤーです。

2. AWS Lambda@EdgeとCloudFront Functions

AWSにはエッジロケーションでコードを実行できるサービスとして「AWS Lambda@Edge」と「CloudFront Functions」があります。これを「エッジコンピューティング」と呼び、ユーザーに最も近い場所でリクエスト処理・レスポンス変換・認証処理を行えます。

オンプレで言えばCDNにあたる概念ですが、単なる静的コンテンツ配信にとどまらず、動的なリクエスト処理がエッジで完結する点が異なります。

3. AzureのPoPとAzure CDN

AzureではAzure CDNのPoP（Point of Presence）がエッジロケーションに相当します。Azure Front Doorを使うと、エッジレベルでのロードバランシング・SSL終端・WAF・キャッシュを一元的に設定できます。AWSのCloudFrontに相当するサービスと理解するとわかりやすいです。

AWSのローカルゾーンとWavelengthゾーン

AWSには、リージョン・AZ・エッジロケーションに加えて、より特殊な地理概念があります。

1. ローカルゾーン（Local Zone）

ローカルゾーンは、大都市圏のエンドユーザーに近い場所に設置された小規模なAWSインフラです。EC2・EBS・VPCなどの一部サービスをリージョンより低レイテンシーで利用できます。

例えばロサンゼルスのエンドユーザーに向けたリアルタイム映像処理や、ゲームサーバーの超低レイテンシー配信など、数ミリ秒の差が重要なユースケースで使われます。日本では2026年3月時点で東京ローカルゾーンが提供されています。

2. WavelengthゾーンとAzure Edge Zones

AWSのWavelengthゾーンは、5G通信キャリアのネットワーク内にAWSコンピュートを埋め込む仕組みです。5Gデバイスからのリクエストがインターネットを経由せずキャリアネットワーク内で処理されるため、超低レイテンシーが実現します。自動運転・工場IoT・ARといった用途が想定されています。

AzureにはAzure Edge Zonesという同様のコンセプトがあり、通信キャリアのエッジ設備にAzureサービスを展開できます。

地理概念まとめ対応表：AWS vs Azure

よくある混同と設計ミス

混同1: 「AZを分けたから冗長構成になっている」は半分正解

EC2インスタンスを複数のAZに分散してELBで振り分けていても、データベースが単一AZにしか存在しなければ、DBのAZで障害が起きた瞬間にシステム全体が止まります。「冗長化」はアプリケーション層だけでなく、データ層・ネットワーク層も含めて考える必要があります。

RDS Multi-AZ設定やElastiCacheのクラスターモードなど、各サービスに対して個別に冗長化設定を行うのがAWSの基本です。サービスのデフォルト状態が「冗長化なし」のものも多いため、設計時に明示的に確認が必要です。

混同2: エッジロケーション = リージョンではない

CloudFrontをデプロイしている = 東京リージョンにデータがある、という理解は誤りです。CloudFrontのエッジロケーションはキャッシュ拠点であり、オリジンサーバー（EC2・S3等）は別途リージョンに存在します。

データレジデンシー要件（データを日本国内に置く必要がある）がある場合、CloudFrontはエッジで一時的にキャッシュするだけで、オリジンデータは東京リージョンにあるため問題ありません。ただし、CloudFrontのログをS3に保存する場合、どのリージョンのS3バケットを指定するかを意識する必要があります。

混同3: 「東京リージョン = 低コスト」ではない

東京リージョン（ap-northeast-1）は米国東部リージョン（us-east-1）と比べてEC2・RDS・データ転送料ともに高い傾向があります。コスト試算を「us-east-1の公式価格表を参照」した場合、実際の東京リージョンの請求額とズレが生じます。AWSコンソールやAWS Pricing Calculatorでリージョンを正しく指定して試算することが重要です。

混同4: データ転送料とリージョン間トラフィック

同一AZ内のEC2インスタンス間のデータ転送は無料ですが、AZをまたぐ場合は1GB当たり0.01USD（2026年3月時点、方向あたり）の転送料が発生します。マルチAZ構成のRDSではプライマリとスタンバイ間のレプリケーションにこのコストがかかります。設計段階でAZをまたぐデータ量を見積もることでコスト試算の精度が上がります。

Linuxサーバーの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。クラウドのEC2やAzure VMで動くOSの基礎知識を身につけたい方にも参考になります。

本記事のまとめ

・リージョン: 物理的に独立した地理エリア。データ所在地・法規制・レイテンシー・料金の判断軸で選択する
・アベイラビリティゾーン（AZ）: リージョン内の独立したデータセンター群。マルチAZ設計で高可用性を実現する
・エッジロケーション: CloudFront・Azure CDNのキャッシュ配信拠点。リージョンではなくCDNレイヤー
・ローカルゾーン: 都市圏に近い超低レイテンシー拠点。特殊なユースケース向け
・Wavelengthゾーン: 5Gキャリアネットワーク内にAWSコンピュートを組み込む仕組み
・Azureリージョンペア: 同一地理圏内のペアリージョンで計画メンテナンスと障害を分離する設計