AWSグローバルインフラストラクチャと配置設計

1. AWSには複数の「配置場所」がある

AWSのインフラストラクチャは、大まかに次のように考えます。

AWS
│
├─ AWSリージョン
│   │
│   ├─ アベイラビリティーゾーン
│   ├─ アベイラビリティーゾーン
│   └─ アベイラビリティーゾーン
│
├─ AWS Local Zones
│     └─ ユーザーや産業拠点に近い場所
│
├─ AWS Wavelength
│     └─ 通信事業者ネットワークのエッジ
│
├─ AWS Outposts
│     └─ 顧客自身の施設
│
└─ AWSグローバルエッジネットワーク
      └─ エッジロケーション / PoP

重要なのは、これらを「大きさの違う同じデータセンター」と考えないことです。それぞれ役割が違います。

2. AWSリージョン

AWSリージョンは、AWSがインフラストラクチャを運用している地理的に分離された領域です。

アジアパシフィック（東京）
アジアパシフィック（大阪）
米国東部（バージニア北部）

多くのAWSリソースでは、まずリージョンを決め、そのリージョン内へリソースを配置するという考え方になります。

まずリージョンを決める
        ↓
そのリージョン内へリソースを配置する

3. リージョンは「一番近い場所」だけでは決めない

AWSリージョンは、単にユーザーから近い場所や最安の場所を選ぶのではなく、必須条件を満たす候補を絞った上で比較します。AWSサービスや機能の提供状況、ユーザーとの距離、法的要件などを確認し、料金もリージョンごとの差を考慮します。

4. 必須条件と最適化条件を分ける

Aリージョン
国内
30 ms
月100万円

Bリージョン
国外
20 ms
月80万円

要件が「顧客データは国内から出してはならない」なら、Bリージョンの方が速く安くても候補から外れます。

逆に法令・サービス要件に差がなく、夜間バッチなのでユーザー応答時間が重要ではないなら、コストの安いリージョンが有力になる可能性があります。

最安
=
必ず正解

最も近い
=
必ず正解

満たさなければならない条件を先に絞り、その中で性能・コストを最適化すると考えます。

5. アベイラビリティーゾーン

1つのAWSリージョンには複数のアベイラビリティーゾーン（可用性ゾーン、AZ）があります。

AZはリージョン内の独立した場所で、1つ以上の個別データセンターから構成され、電源、ネットワーク、接続などが冗長化されています。AWSはAZ同士を障害が相関しにくいよう物理的に分離しながら、低レイテンシーで接続できるよう設計しています。

東京リージョン
│
├─ AZ-A
│
├─ AZ-B
│
└─ AZ-C

6. リージョンとAZの役割は違う

リージョン
→ 地理的配置を決める

AZ
→ そのリージョン内の障害分離を考える

7. 台数を増やすこととAZを分けることは違う

AZ-A
├─ ウェブ01
├─ ウェブ02
├─ ウェブ03
└─ ウェブ04

4台あるので、1台のEC2障害には耐えられるかもしれません。しかしAZ-A全体が利用できなくなった場合は、4台すべてが同じ障害範囲に含まれます。

AZ-A                AZ-B
├─ ウェブ01             ├─ ウェブ03
└─ ウェブ02             └─ ウェブ04

SAP-C02では、台数だけではなく、同じ障害範囲に何台あるかを見ることが重要です。

8. 複数AZと複数リージョンも同じではない

東京リージョン
├─ AZ-A
├─ AZ-B
└─ AZ-C

複数AZに配置しても、それらは同じAWSリージョン内です。

東京リージョン
+
大阪リージョン

したがって「AZ単位の障害から守りたい」と「地理的に別地域へ配置したい」は異なる要件です。マルチリージョンのDRやレプリケーションは、配置先の選択とは別の設計判断です。

9. 複数アカウントではAZ IDを基準にする

複数AWSアカウントをまたいで、リソースを同じ物理AZへ配置したい場合があります。

アカウント A
us-east-1a

アカウント B
us-east-1a

ここで、AZ名が同じだから必ず同じ物理AZとは限らない点に注意します。一部のリージョンでは、2025年11月より前に作成されたAWSアカウントについて、AZ名と物理AZの対応がアカウントごとに異なる場合があります。

一方、AZ IDはAWSアカウントをまたいで同じ物理AZを表します。

AZ名
us-east-1a
→ アカウントによって対応が異なる場合がある

AZ ID
use1-az1
→ アカウントをまたいで同じ物理AZ

2025年11月以降に作成されたアカウントでは、従来アカウントごとにAZ名が個別マッピングされていたリージョンでも同じAZコードが同じAZへマッピングされます。それでも、複数アカウントで物理AZを確実に揃える必要があるならAZ IDを確認する、という設計判断が最も明確です。

10. AWS Local Zones

通常のAWSリージョンでは、ユーザーとの物理的距離によってネットワーク遅延が大きくなる場合があります。そこで利用できる選択肢の1つがAWS Local Zonesです。

ローカルゾーンは、コンピューティング、ストレージ、データベースなどの選択されたAWSリソースを大規模な人口・産業拠点の近くへ配置するAWSリージョンの拡張です。

ユーザー
    │
    │ 低レイテンシー
    ▼
ローカルゾーン
    │
    │ AWSネットワーク
    ▼
親リージョン

代表的な用途には、リアルタイムゲーム、仮想ワークステーション、AR / VR、ライブストリーミングなどがあります。

11. ローカルゾーンは独立したリージョンではない

ローカルゾーンには親リージョンがあります。ローカルゾーン名にも親リージョンのコードが含まれます。したがって、ローカルゾーンは小さな独立AWSリージョンではありません。

また、すべてのAWSサービスをローカルゾーン内で利用できるわけではありません。対応しているAWSリソースをユーザーや業務拠点に近づけるために使います。

12. AWS Outposts

次はユーザーではなく、顧客自身のデータセンターや工場の中へAWSインフラストラクチャを持ってくる場合です。

AWS Outpostsは、AWSインフラストラクチャ、AWSサービス、API、ツールを顧客施設へ拡張するフルマネージドのソリューションです。

AWSリージョン
       │
       │ サービスリンク
       │
       ▼
顧客施設
┌────────────────┐
│ AWS Outposts   │
│                │
│ AWSリソース    │
└────────────────┘
       │
       ▼
工場設備 / 社内システム

主な要件は、オンプレミス機器との低レイテンシー通信、ローカルデータ処理、ローカルシステムとの密接な依存関係、データレジデンシーなどです。

13. Outpostsで最も注意する点

ここは旧教材からの重要な修正点です。

Outpostsは顧客施設へAWS設備を置くため、「データを絶対に外へ出せない → Outposts」と単純化したくなります。しかしOutpostsは、AWSリージョンとのサービスリンクを必要とします。

サービスリンクではOutpostsの管理通信が行われ、構成によっては関連VPCとのカスタマートラフィックも通過します。

データをローカルで処理したい
→ AWS Outpostsは有力

いかなる通信も施設外へ出してはいけない
→ AWS Outpostsと即断しない

後者では、どの通信・データがサービスリンクを通るのかまで要件確認が必要です。

14. AWS Wavelength

AWS Wavelengthは、AWSのコンピューティングやストレージを通信サービスプロバイダーのネットワークエッジへ配置する仕組みです。

モバイル端末
     │
     │ 4G / 5G等
     ▼
通信事業者ネットワーク
     │
     ▼
Wavelength Zone
     │
     ▼
親AWSリージョン

例えば、モバイル端末、コネクテッドカー、リアルタイムゲーム、AR / VR、通信事業者ネットワークを利用するエッジアプリケーションなどが候補になります。

Wavelength ゾーンは親AWSリージョンに関連付けられたリージョンの論理的な拡張です。

15. 「Wavelength = 5G」という丸暗記もしない

Wavelengthは5G向けとしてよく説明されますが、設計判断では、通信事業者ネットワークのエッジへコンピューティングを置きたいという部分が本質です。

現在のWavelengthでは、通信事業者によって4G/LTE、5G、固定無線アクセスなどとの接続形態もあります。

5Gという文字を見た
→ 無条件にWavelength

通信事業者ネットワークのエッジで
低レイテンシー処理が必要
→ Wavelengthを検討

16. エッジロケーション

AWSには、リージョンとは別に世界中へ分散したポイントオブプレゼンス（PoP）があります。Amazon CloudFrontでは、このPoPをエッジロケーションとも呼びます。

CloudFront、Amazon Route 53、AWS Global AcceleratorなどがAWSグローバルエッジネットワークを利用します。

利用者
   │
   ▼
近くのAmazon CloudFront POP
   │
   │ キャッシュミス時
   ▼
オリジン

CloudFrontは通常、適切なPoPへユーザーをルーティングし、キャッシュされたコンテンツがあればそこから配信します。

17. エッジロケーションとローカルゾーンを混同しない

例えば「世界中へ画像を高速配信したい」ならCloudFront / エッジロケーションが候補です。一方、「ユーザー操作を処理するレンダリング用EC2自体を都市の近くに置きたい」ならローカルゾーンを検討します。

18. ローカルゾーン / Outposts / Wavelengthの決定的な違い

覚え方はサービス名ではなく、誰・何との距離を縮めたいのかです。

19. 全体比較

20. SAP-C02で使う配置判断フロー

① 地理・法令・データレジデンシーの必須条件はあるか
         │
         ▼
   利用可能な地域を絞る
         │
         ▼
② 必要なAWSサービス / 機能を利用できるか
         │
         ▼
③ 通常のAWSリージョンでレイテンシーを満たせるか
         │
    ┌────┴────┐
   はい       いいえ
    │          │
リージョン      ▼
を候補       何との距離が問題か？
               │
        ┌──────┼─────────┐
        │      │         │
     ユーザー  顧客施設   通信事業者
        │      │         │
        ▼      ▼         ▼
   ローカルゾーン AWS Outposts AWS Wavelength

別軸:
CDN / エッジ配信
        ↓
Amazon CloudFront等のPOP

リージョン内では
        ↓
AZ障害への耐性が必要か
        ↓
複数AZ配置を検討

最後に
        ↓
コスト・運用・性能を比較

21. よくある失敗

失敗1：一番近いリージョンを必ず選ぶ

必要サービスや法令要件を満たさなければ不適切です。

失敗2：安いリージョンを必ず選ぶ

レイテンシーやデータレジデンシーの必須要件を無視できません。

失敗3：EC2を10台置けば高可用性

10台とも同じAZならAZ障害という共通障害範囲が残ります。

失敗4：us-east-1aなら全アカウントで同じ場所

複数アカウントで物理AZを揃える場合はAZ IDを確認します。

失敗5：低レイテンシーなら全部ローカルゾーン

顧客施設との距離ならOutposts、通信事業者ネットワークならWavelengthなど、対象によって変わります。

失敗6：データを外へ出せないならOutposts

OutpostsにはAWSリージョンとのサービスリンクが必要です。通信要件を確認せず無条件に選択しません。

失敗7：エッジロケーションへ普通のEC2を置く

エッジロケーション / PoPとローカルゾーンは別物です。

このページで最終的に判断できること

地理的なAWS配置
→ リージョン

リージョン内の障害分離
→ AZ

都市圏・産業拠点近くでアプリ処理
→ ローカルゾーン

顧客施設でAWS処理
→ AWS Outposts

通信事業者ネットワークエッジ
→ AWS Wavelength

CDNやエッジサービス
→ エッジロケーション / PoP

最重要なのは、「どのAWSサービスを知っているか」ではなく、要件上どの場所へ処理を配置する必要があるかです。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド
• AWSリージョンとアベイラビリティーゾーン
• AZ ID
• AWS Local Zones
• AWS Outposts
• AWS Outposts — サービスリンク
• AWS Wavelength
• CloudFrontがコンテンツを配信する方法