グローバルインフラストラクチャ

AWSグローバルインフラストラクチャとは、ユーザーの近くでワークロードを実行し、局所的な障害を乗り越え、データ主権規制を満たすためにAWSが運用する、物理データセンター・ネットワークリンク・エッジPoP（Points of Presence）の世界規模のネットワークだ。CLF-C02試験ではRegions・Availability Zones・Edge Locationsの階層構造、および特殊レイヤー（Local Zones・Wavelength Zones・Outposts）と各インフラ層がレイテンシー・コンプライアンス・耐障害性・コストといった実際のビジネス要件にどう対応するかを知っていることが求められる。

このページはドメイン3（クラウドテクノロジーとサービス）のタスクステートメント3.2に属する。AWSグローバルインフラストラクチャの構造的なレイアウトに焦点を当てている。CloudFront・Route 53・Global Acceleratorのネットワーク動作の詳細はnetwork-servicesのトピックに属する。AWSグローバルインフラストラクチャ全体にわたってワークロードを配置するデプロイツール（CloudFormation・Elastic Beanstalk）はdeployment-operation-methodsに属する。

AWSグローバルインフラストラクチャとは何か？

AWSグローバルインフラストラクチャとは、Amazon Web Servicesが世界中に配置した物理的なフットプリントだ：30以上のRegion、100以上のAvailability Zone、そして人が住むすべての大陸に広がる数百のEdge LocationとRegional Edge Cache。AWSグローバルインフラストラクチャの各層はそれぞれ異なる問題を解決する。Regionは障害の封じ込めとデータ主権を解決する。Availability ZoneはRegion内の高可用性を解決する。Edge Locationは、CloudFront・Route 53・Global Acceleratorを通じて最後の1マイルのレイテンシーを解決する。Local ZonesとWavelength ZonesはAWSグローバルインフラストラクチャを大都市圏と5Gネットワークに拡張する。AWS OutpostsはAWSグローバルインフラストラクチャを顧客自身のデータセンターに持ち込む。

CLF-C02試験がAWSグローバルインフラストラクチャを重点的にテストする理由は、他のほぼすべてのAWSサービスがその下にあるインフラ層のプロパティを継承するからだ。AWSグローバルインフラストラクチャを理解すれば、EC2・S3・RDS・Lambda・CloudFrontなどあらゆるサービスについて、個別に暗記することなく耐障害性・レイテンシー・コンプライアンスを論理的に推論できる。

AWSグローバルインフラストラクチャがCLF-C02で重要な理由

AWSグローバルインフラストラクチャは試験問題に3つの形で登場する：

1. 定義問題 — 「RegionとAvailability Zoneの違いは何か？」
2. シナリオ問題 — 「EU内に顧客データを保管し、モバイルデバイスから低レイテンシーでアクセスが必要な企業が選ぶべきAWSグローバルインフラストラクチャのコンポーネントの組み合わせはどれか？」
3. 罠問題 — Local ZonesとWavelength Zones、またはCloudFront Edge LocationsとRegional Edge Cachesを混同させる。

階層の全体像

最上位にAWSグローバルインフラストラクチャ全体がある。その中にRegionsがある。各Regionの中にAvailability Zonesがある。それらのRegionsの周囲、ユーザーに向かって広がるのがEdge LocationsとRegional Edge Cachesだ。そしてコアレイヤーの隣に特殊な拡張機能がある——Local Zones・Wavelength Zones・AWS Outposts——それぞれが特定の種類のワークロードにAWSグローバルインフラストラクチャをより近づける。

やさしい解説: AWSグローバルインフラストラクチャ

AWSグローバルインフラストラクチャは書類上は難解に見えるが、その本質は階層型の配送システムだ：少数の重量級ハブ、より広い環状の地域施設、そしてエンドユーザーのそばに密に配置された軽量な接点の網。以下の3つの比喩はそれぞれ異なる角度からこの概念を攻める——主権とコンプライアンス、障害の分離、そして近接性とレイテンシー。CLF-C02試験がどんな形でシナリオを出してきても、すでにメンタルモデルが準備できている状態にする。

Analogy 1 — 日本の行政区画（主権とコンプライアンス）

AWSグローバルインフラストラクチャを日本の行政区画の階層として考えてみよう：都道府県、その中の市区町村、市区町村の中の町・丁目。Regionは都道府県だ——独自の条例・予算・境界を持ち、外部の自治体が容易に介入できない。これがeu-central-1にEU顧客データを置き、GovCloudにITARワークロードを置く理由そのものだ。Availability Zonesは市区町村にあたる——独立した行政が可能なほど分離されているが、インフラを共有できるほど近接している。Edge Locationsは地域の公共施設——図書館の分館・郵便ポスト・コンビニ——市民が実際に住む場所に設置されることで都庁（Regionオリジン）が過負荷にならない。

Analogy 2 — 宅配便ネットワーク（障害の分離）

AWSグローバルインフラストラクチャは、障害が起きても荷物が届き続けるよう設計された国際宅配ネットワークにもたとえられる。Regionは各国の配送センターだ——大阪の倉庫が台風で閉鎖されても、北海道の配送センターは動き続ける。これがus-east-1の障害がeu-west-2を巻き込まない理由と同じだ。Availability Zonesは異なる地域に設置された複数の仕分けセンターだ——それぞれ独立した電源グリッドを持つため、一つが浸水しても全国配送は止まらない。Regional Edge Cachesは地区のハブ施設、Edge Locationsは近隣の宅配ポイント、AWS Outpostsは企業キャンパス内に設置された同一手順で動くプライベート荷物室だ。

Analogy 3 — 全国チェーンの飲食店（近接性とレイテンシー）

最後に、AWSグローバルインフラストラクチャをスピード重視の全国チェーン飲食店として想像してみよう。RegionはレシピとコンプライアンスをすべてGerのする本社・セントラルキッチンだ——AuroraやBedrockのような重量級マネージドサービスはここで「調理」される。Availability Zonesはその国内に点在するリージョナルキッチンだ——1つのオーブンが故障してもランチラッシュが止まらないよう冗長化されている。Edge Locationsは街角の小さな店舗だ：本格的なキッチンはないが、人気メニュー（キャッシュ済みコンテンツ）を数秒で温め直して提供できる——これがCloudFrontがレイテンシーを削減するメカニズムだ。Local Zonesは特定の都市中心部に設置されたエクスプレスキオスク、Wavelength Zonesは5Gキャリアの会場内に直接停車したフードトラックで、モバイル客は一歩も外に出ずに注文できる。

Core Operating Principles — Regions・AZs・Edge Locationsの階層

AWSグローバルインフラストラクチャはCLF-C02試験に繰り返し登場する3つの硬いアーキテクチャ原則に従っている。

原則1 — Regionsは意図的に分離されている

AWSグローバルインフラストラクチャの各AWSリージョンは独立した障害ドメインだ。AWSはRegion間でデータを自動的にレプリケートしない。us-east-1のS3にオブジェクトを保存すれば、そのオブジェクトは明示的にクロスリージョンレプリケーションを設定しない限りus-east-1に留まる。この分離こそ、AWSグローバルインフラストラクチャがGDPR・HIPAA・中国のPIPLなどのデータ主権規制に準拠できる理由だ。

原則2 — Availability Zonesは物理的に分離されているが論理的に近い

Region内のAvailability Zonesは意味のある距離（通常は数十km）で分離されており、洪水・火災・地震・停電による相関障害を避ける。同時に、各AZはAWS所有の低レイテンシー・高帯域幅の専用光ファイバーで接続されているため、同期レプリケーション（例：Multi-AZ RDSやEFS）が現実的だ。

原則3 — EdgeはコンテンツをユーザーにPushする

Edge LocationsとRegional Edge CachesはRegionの境界の外側にある。3つのエッジ対応サービス——Amazon CloudFront・Amazon Route 53・AWS Global Accelerator——が使用する。試験ではこれらのEdge Locationsを、一般的なコンピューティングワークロードをホストしないにもかかわらず、AWSグローバルインフラストラクチャの一部として扱う。

AWS Regions — 地理的分離・データ主権・レイテンシー

AWS Regionとは、世界中のどこかにあるAWSがデータセンターをクラスター化した物理的な場所だ。2026年現在、AWSグローバルインフラストラクチャは30以上のRegionを公開しており、さらに計画中のものがある。各Regionにはus-east-1（バージニア北部）・ap-northeast-1（東京）・eu-west-2（ロンドン）のようなコードがある。

Regionの解剖学

AWSグローバルインフラストラクチャの各Regionは以下を含む：

• 少なくとも3つのAvailability Zone（新しいRegionは通常3つでローンチし、成熟したRegionの多くは6つある）。
• リージョナルサービスカタログ — すべてのAWSサービスがすべてのRegionで利用可能なわけではない。例えばBedrockはサブセットのRegionのみで利用可能だ。
• 課金境界 — Region内のデータ転送は通常無料または安価だが、Region間のデータ転送は課金される。
• そのRegion固有のコンプライアンス認定（例：GovCloud RegionはU.S.政府要件を満たす）。

AWSグローバルインフラストラクチャにRegionsが存在する理由

1. 障害の封じ込め — RegionはAWS上で構築できる最大のブラストラジアスだ。Regionが停止しても（極めてまれ）、他のRegionはサービスを継続する。
2. データ主権・データレジデンシー — eu-central-1にリソースを配置することで、データをドイツおよびEUの法的フレームワーク内に保持できる。
3. レイテンシー — ワークロードをユーザーの近くに配置することで往復時間を削減できる。
4. コスト — オンデマンド料金はRegionによって異なる。us-east-1（バージニア北部）は最も安価になる傾向がある。

Regionの命名とスコープ

RegionのフルネームはUS East (N. Virginia)のように見え、コードはus-east-1だ。注目すべき例外：us-east-1（バージニア北部）はIAM・CloudFrontコントロールプレーン・Route 53コントロールプレーンなど多くのグローバルサービスのホームだ。IAMはAWSグローバルインフラストラクチャのグローバルサービスで、そのメタデータはus-east-1に存在する、ということを多くの受験者が忘れる。

AWS Regionの選び方

CLF-C02試験でRegion選択を左右する4つの基準：

1. コンプライアンス・データレジデンシー — GDPRがEU Regionsを強制する可能性がある。HIPAAワークロードはBAA対応Regionが必要だ。
2. エンドユーザーへのレイテンシー — ユーザーの大多数に地理的に最も近いRegionを選ぶ。
3. サービス可用性 — 特定のAWSサービスがそのRegionで提供されているか確認する。
4. コスト — オンデマンド料金は異なる。us-east-1はコンピューティングとストレージで一般的に最安値だ。

Availability Zones — 物理的な分離と単一障害点の排除

Availability Zone（AZ）とは、Region内の独立した電源・冷却・物理セキュリティ・ネットワークを持つ、1つ以上の物理的に独立したデータセンターだ。AZはRegionを離れることなく高可用性のワークロードを設計するためのAWSグローバルインフラストラクチャの構成要素だ。

AZをAZたらしめるもの

• 独立した電力グリッドのサブステーションとオンサイト発電機からの冗長電源。
• 1つのチラーが故障しても別のAZに影響しない独立した冷却設備。
• 各AZが独自のラック上部スイッチとスパインスイッチを持ち、Regionの光ファイバーバックボーンへの専用アップリンクを持つ分離されたネットワークファブリック。
• 通常100 km以内に収まるが、AZ間のサブミリ秒の光ファイバーレイテンシーを保てるほど近い意味のある物理的距離。

AZ識別子と難読化

AWSアカウント内では、AZはus-east-1a・us-east-1b・us-east-1cのように表示される。AWSはアカウントごとにこれらの文字サフィックスをランダムにマッピングするため、あなたのus-east-1aは別の顧客のus-east-1aと必ずしも同じ物理AZではない。これにより、すべての顧客が「最初の」AZをデフォルトにしてホットスポットが生まれるのを防ぐ。

最低AZ数のルール

AWSグローバルインフラストラクチャのすべてのAWS Regionは最低3つのAvailability Zoneを持つ。一部のサービスは複数のAZを必要とする——例えばMulti-AZ RDSは2つのAZ間で同期レプリケーションを行い、Elastic Load BalancerはAZをまたいでターゲットにルーティングする。

複数AZを使った高可用性

AWSグローバルインフラストラクチャでの標準的な高可用性パターンは「Multi-AZ」だ。例：

• Amazon RDS Multi-AZ — AZ-aにプライマリ、AZ-bに同期スタンバイ。フェイルオーバーは60〜120秒。
• Auto Scaling GroupをAZ全体に展開 — ALBの背後に2〜3つのAZにEC2を分散する。
• Amazon EFS — AZ間でデータが自動的にレプリケートされる。
• Amazon S3 Standard — Region内の少なくとも3つのAZにオブジェクトを冗長保存する。

Multi-AZでは不十分な場合 — マルチリージョン

Region全体の停止を乗り越えるディザスタリカバリには、マルチリージョンが必要だ。AWSグローバルインフラストラクチャでマルチリージョンに移行する典型的なトリガー：

• 異なる管轄にDRサイトを置く規制要件。
• グローバルに重要なシステムのRTO/RPOが非常に短い場合。
• 大陸をまたいで分散するユーザーに対して海越えレイテンシーが許容できない場合。

Edge Locations — CloudFront・Route 53・Global Accelerator

Edge Locationsは世界中の数百の都市に展開されたAWSグローバルインフラストラクチャのエンドポイントだ。RegionsやAZsとは異なり、Edge Locationsはあなたのec2インスタンスやS3バケットをホストするためには使われない。エンドユーザーのトラフィックをビューワーの近くで終端し、リクエストをオリジンRegionに向けて転送するために存在する。

Edge Locationsを使用するサービス

AWSグローバルインフラストラクチャのEdgeレイヤーに位置するCLF-C02の3つのサービス：

• Amazon CloudFront — グローバルCDN（コンテンツデリバリーネットワーク）。静的・動的コンテンツをEdge Locationsにキャッシュし、繰り返しリクエストがオリジンまで戻らなくて済むようにする。
• Amazon Route 53 — Edge Locations全体に広がるAnycastネットワークを持つDNSサービス。DNSクエリは最も近いPoPで解決される。
• AWS Global Accelerator — EdgeをAWSバックボーン上でTCP/UDPトラフィックをルーティングするために使い、公共インターネットを使う場合よりも一貫性を高め、ジッターを削減する。

数十のRegionに対して数百のPoP

Regionsは数十単位で計測される。Edge Locationsは数百単位だ。AWSはグローバルで100以上の都市に600以上のPoP（Points of Presence）を持つ。このスケールこそ、CloudFrontがRegionから直接サービスする場合と比べてエンドユーザーのレイテンシーを劇的に削減できる理由だ。

なぜこれが構造的なトピックでサービストピックではないのか

CloudFrontは特定のAWSサービスだが、CLF-C02の設計図は知識を分割している：

• グローバルインフラストラクチャ（タスク3.2） — Edge LocationsがAWSグローバルインフラストラクチャの一層として存在することを知る。
• ネットワークサービス（タスク3.5） — CloudFrontディストリビューション・無効化・キャッシュ動作の設定方法を知る。

このページでは構造的な境界で止まる——CloudFrontはAWSグローバルインフラストラクチャの一部であるEdge Locationsを使用する。CloudFrontの詳細な機能についてはnetwork-servicesのトピックを参照せよ。

Regional Edge Caches — EdgeとオリジンをつなぐレイヤーのMiddle Tier

Regional Edge CachesはAWSグローバルインフラストラクチャのあまり知られていないレイヤーで、古いCLF-C01の学習教材では不足しがちだ。Edge Locationsとオリジンの間に位置するより大きなCloudFrontキャッシュだ。

Regional Edge Cachesが存在する理由

単一のEdge Locationはストレージ容量が限られており、リクエストが少ないコンテンツを素早く追い出す。リクエストがEdgeキャッシュにヒットせず、インターネットを経由してオリジンRegionまで戻らなければならない場合、レイテンシーが急上昇する。Regional Edge Cacheはその中間に位置する：Edgeにキャッシュされるほどホットではないがオリジンから繰り返しフェッチするには人気すぎるコンテンツを保持する。

フローの仕組み

1. ビューワーがexample.com/video.mp4をリクエストする。
2. リクエストは最も近いEdge Locationに届く。キャッシュミス。
3. Edge Locationは最も近いRegional Edge Cacheからフェッチする。ヒット。
4. Edgeはオブジェクトをキャッシュしてビューワーに配信する。

この多層キャッシュはAWSグローバルインフラストラクチャにおけるCloudFrontの動作の重要な部分で、ロングテールコンテンツでもヒット率が高いままである理由を説明している。

AWS Local Zones — 大都市圏への超低レイテンシー

Local ZonesはAWSグローバルインフラストラクチャの拡張機能で、特定の大都市圏に対して単桁ミリ秒のレイテンシーが必要なワークロード向けに設計されている。Edge Locations（読み取り専用キャッシュ）とは異なり、Local Zonesは実際のコンピューティング・ストレージ・データベースサービスを実行する。

Local Zoneで動くもの

Local Zoneが通常サポートするもの：

• Amazon EC2インスタンスファミリー（選択タイプ）
• Amazon EBSボリューム
• Amazon FSx
• Elastic Load Balancer
• Local ZoneへのAmazon VPCサブネットの拡張
• Amazon RDS（選択エンジン）

Local Zoneのユースケース

1. リアルタイムゲーミング — ロサンゼルスのプレイヤーがゲームサーバーに対して10 ms未満のレイテンシーが必要な場合、us-west-2-lax-1a Local Zoneがサーバーをホストする。
2. メディア・エンタープライズのポストプロダクション — ワークステーション品質のレイテンシーでリモートから編集する大容量ビデオファイル。
3. ライブ動画ストリーミングとトランスコーディング — バースト的なアップロードを行うコンテンツクリエイター。
4. AR/VRトレーニングシミュレーション — 50 msのRTTを許容できない産業ワークフロー。

親Regionとの関係

すべてのLocal Zoneは親Regionに接続されている。例えば、us-west-2-lax-1aは親Regionがus-west-2（オレゴン）のロサンゼルスにあるLocal Zoneだ。Local Zone内のサービスはアイデンティティ・ネットワーク・グローバルコントロールプレーンを親Regionから継承する。親RegionからLocal ZoneにVPCを拡張する。

AWS Wavelength Zones — 5GネットワーカにおけるAWSグローバルインフラストラクチャ

Wavelength ZonesはAWSグローバルインフラストラクチャを通信事業者の5Gネットワーク内に埋め込む。目標はモバイルデバイスのトラフィックがモバイルキャリアのネットワークを離れることなく超低レイテンシーアクセスを実現することだ。

Wavelength ZonesがLocal Zonesと異なる点

• Local Zones — 大都市圏のAWS所有施設にあるAWSグローバルインフラストラクチャ。公共インターネットまたはDirect Connect経由でアクセス可能。
• Wavelength Zones — 特定の通信事業者の5Gネットワーク内部にあるAWSグローバルインフラストラクチャ（米国ではVerizon、日本ではKDDI、英国・ドイツではVodafone、韓国ではSK Telecom）。そのキャリアのモバイルデバイスから直接アクセスする。

Wavelength Zonesのユースケース

1. 5Gモバイルエッジコンピューティング — ARグラス・コネクテッドカー・リアルタイム映像解析。
2. 産業IoT — ミリ秒の応答を必要とするプライベート5G上の工場ロボット。
3. モバイルからのライブブロードキャスト — コンテンツがキャリアのバックボーンを離れることなく配信するストリーミングクリエイター。

サポートされるサービス

Wavelength ZonesでLocal Zonesより少ないサービスが動く——通常はEC2・EBS・VPC・ロードバランシングだ。Aurora・Bedrockなどの重量級マネージドサービスは親Regionに留まる。

AWS Outposts — 顧客施設上のAWSグローバルインフラストラクチャ

AWS Outpostsは、同じAWSグローバルインフラストラクチャのハードウェア・サービス・API・ツールを顧客自身のデータセンターに持ち込む。「データをビル外に出せないがAWSの一貫性が必要な場合はどうするか？」という問いへの答えだ。

Outpostsのフォームファクター

• Outposts Racks — 完全に設定済みで出荷される42Uの標準ラック。
• Outposts Servers — より小さなスペース向けの1Uまたは2Uサーバー（小売店・支店・船舶）。

Outpostsがサポートするもの

• EC2・EBS・S3 on Outposts
• コンテナ向けECS・EKS
• Amazon RDS on Outposts
• Application Load Balancer
• ローカルビッグデータ処理向けEMR

Outpostsのユースケース

1. 低レイテンシーのローカルアプリケーション — WANリンクに依存してはならない製造フロアの制御システム。
2. データレジデンシー — AWS Regionがまだ存在しないが、データをオンプレミスに留める必要がある国。
3. ローカルデータ処理 — サマリーをクラウドに送る前に大規模データセットを前処理する。
4. レガシー統合 — AWSサービスのそばにメインフレームや専用ハードウェアを隣接させる。

AWSグローバルインフラストラクチャの境界

Outpostsは、あなたが物理的に収容するAWSグローバルインフラストラクチャの唯一の部分だ。AWSは引き続きハードウェアを所有・運用し（完全マネージド）、パッチを適用し、交換品を出荷する——ただしそれはあなたの住所に存在する。これがAWSグローバルインフラストラクチャがハイブリッドクラウドと出会う境界線だ。

Regionの選び方 — CLF-C02の意思決定フレームワーク

Regionの選択はCLF-C02試験で繰り返し登場するシナリオだ。AWSグローバルインフラストラクチャの問題が出たら、この4ステップの決定順序を使おう。

ステップ1 — コンプライアンス・データレジデンシー

法律または契約によってデータを特定の国境内に留める必要があるか？ある場合、その管轄のRegionに絞り込む。例：

• GDPR → EUのRegion（eu-west-1・eu-central-1・eu-west-3など）。
• HIPAA → BAAがカバーする商用Region。新しいワークロードにオプトインRegionは避ける。
• ITAR / FedRAMP High → AWS GovCloud（US）Regions。
• 中国のPILP → SinnetとNWCDが運用するAWS China（北京・寧夏）。

ステップ2 — ユーザーへのレイテンシー

ユーザーの大多数はどこにいるか？地理的に最も近いRegionを選ぶ。グローバルアプリには、AWSグローバルインフラストラクチャのEdgeレイヤー（CloudFront＋Global Accelerator）を使ってレイテンシーをさらに削減する。

ステップ3 — サービス可用性

リージョナルサービスリストを確認する。Amazon Bedrock・Amazon Q・SageMaker JumpStart・Local ZonesはすべてのRegionにあるわけではない。

ステップ4 — コスト

オンデマンド料金はRegionによって異なる。us-east-1が通常最安値で、us-east-2とus-west-2がそれに続く。日本やオーストラリアのRegionはより高くなる傾向がある。

AWSグローバルインフラストラクチャでの高可用性設計

AWSグローバルインフラストラクチャは3つのスケールの高可用性を提供する：

• 単一AZ・マルチラック — ラックレベルの障害のみ保護。本番環境にはほとんど適切でない。
• Region内のMulti-AZ — デフォルトのHAパターン。局所的な自然災害を含むAZ障害から保護する。AWS内部の低レイテンシー光ファイバーを使用。
• マルチリージョン — 壊滅的なRegion停止・グローバルDR・国境をまたぐコンプライアンスに対応。通常、アクティブ・パッシブまたはアクティブ・アクティブのレプリケーション（S3 CRR・DynamoDB Global Tables・Aurora Global Database）が必要。

一般的なMulti-AZパターン

• ステートレスウェブ層 — 3つのAZにまたがるAuto Scaling Group＋Application Load Balancer。
• ステートフルデータベース層 — RDS Multi-AZ・AZ間のレプリカを持つAuroraクラスター・DynamoDB（Region内でネイティブにMulti-AZ）。
• 共有ファイルシステム — Amazon EFS（デフォルトでMulti-AZ）またはMulti-AZデプロイのFSx。

マルチリージョンDRパターン

• バックアップとリストア — 最安値・最も遅いRTO。定期的なクロスリージョンバックアップ。
• パイロットライト — DRリージョンで最小限のリソースが動き、フェイルオーバー時にスケールアップ。
• ウォームスタンバイ — スケールダウンしたフルスタックが動いており、フェイルオーバー時にスケールアウト。
• アクティブ・アクティブ / マルチサイト — 両Regionでフル容量を持ちインテリジェントルーティング。

これらのDRパターンはWell-Architected FrameworkのReliabilityピラーとリンクする——詳細はwell-architected-frameworkを参照せよ。

データレジデンシー・主権・コンプライアンス

データレジデンシーはデータがAWSグローバルインフラストラクチャのどこに物理的に存在するかを制御し、データ主権はどの管轄の法律が適用されるかを制御する。どちらもまずRegionレイヤーで解決する。

Regionレベルの制御

• 自動的なレプリケートを行わない — S3 Cross-Region Replicationはオプトイン。デフォルトではオブジェクトはその場に留まる。
• Regionスコープのサービス — ほとんどのサービスはRegionスコープ。IAM・CloudFront・Route 53は例外だ。
• オプトインRegion — 一部のRegion（香港・バーレーン・ケープタウン・ミラノ・UAE・テルアビブ・ジャカルタ・チューリッヒ・ハイデラバード・メルボルン・マレーシア）は誤ったデータ配置を防ぐために明示的なオプトインが必要だ。

GovCloudとSovereign CloudのRegion

• AWS GovCloud（US） — U.S.政府のワークロード向けの隔離されたRegion。商用AWSグローバルインフラストラクチャとは物理的・論理的に分離されている。
• AWS Sovereign Cloud（EU） — AWSはEUの厳格な主権要件を持つワークロード向けにEuropean Sovereign Cloudを発表した。
• AWS China Regions — ローカルパートナーシップの下で運用。別のAWSアカウントが必要だ。

重要な数値と必須暗記事項

よくある試験の罠 — AWSグローバルインフラストラクチャの境界テスト

罠1 — RegionとAvailability Zone

Regionは単一のデータセンターではない。AZは単一の建物ではない。受験者は試験のプレッシャーの下でこれを逆に覚えてしまう。アンカー：Region → AZs → データセンター。

罠2 — Edge LocationとRegional Edge Cache

Edge Locationsはビューワー向けで数が多い。Regional Edge Cachesは少なく、Edge Locationsとオリジンの間にある。問題に「オリジン負荷を軽減するための中間層キャッシュ」とあれば、Regional Edge Cacheと答える。

罠3 — Local ZoneとWavelength Zone

Local Zone = 一般ワークロード向けの大都市圏。Wavelength Zone = モバイルエッジワークロード向けの5Gキャリア内。問題文にキャリア名が登場すれば正解はWavelength Zoneだ。

罠4 — OutpostsをRegionとして扱う

OutpostsはRegionではない。あなたのフロアに存在するが、親Regionの拡張だ。試験のダミー選択肢がOutpostsを独立したRegionとして扱うことがある——これは誤りだ。

罠5 — CloudFrontは純粋にEdgeだという誤解

CloudFrontはEdgeに位置するが、その設定・無効化・ディストリビューションメタデータはus-east-1のグローバルエンドポイントからコントロールされる。これがCloudFrontがグローバルAWSグローバルインフラストラクチャサービスと呼ばれる理由だ。

罠6 — すべてのサービスがすべてのRegionに存在すると仮定する

Bedrock・Amazon Q・一部のMLサービスは最初に一部のRegionのみでローンチされる。試験に「ムンバイの企業がBedrockをClaude Sonnet 3.5で使いたい」とあり、ap-south-1が選択肢として出たら、そのサービスが利用可能か確認する——そうでなければ別のRegionが正解かもしれない。

AWSグローバルインフラストラクチャとネットワークサービス — スコープ境界

これはタスクステートメント3.2のトピックだ：構造。隣接するタスクステートメント3.5（ネットワークサービス）は、そのインフラの上で動くサービスをカバーする。

• 3.2（このページ） — Regions・AZs・Edge Locations・Regional Edge Caches・Local Zones・Wavelength Zones・Outpostsの存在とレイアウト。
• 3.5（network-services） — VPC・サブネット・Security Groups・NACL・Route 53ルーティングポリシー・CloudFrontディストリビューション・Direct Connect・VPN・Global Acceleratorの設定方法。

「AWSグローバルインフラストラクチャのどの部分がユーザーの近くにコンテンツをキャッシュするか？」→ Edge Locations（3.2の答え）。「ユーザーの近くにコンテンツをキャッシュするのはどのサービスか？」→ CloudFront（3.5の答え）。

演習問題リンク — タスク3.2対応練習問題

タスク3.2にマッピングされたAWSグローバルインフラストラクチャの概念を練習しよう：

• 「すべてのAWS Regionが持つ最低AZ数は？」— 最低AZルールを対象にする。
• 「Amazon CloudFrontが使用するAWSグローバルインフラストラクチャのコンポーネントはどれか？」— Edge Locations。
• 「ロサンゼルスのゲーミング企業がLAメトロのプレイヤーに単桁ミリ秒のレイテンシーが必要。」— Local Zone。
• 「通信パートナーが5Gネットワーク内にAWSサービスを埋め込む必要がある。」— Wavelength Zone。
• 「銀行が特定のデータセットをオンプレミスから移動できないがAWS APIが必要。」— AWS Outposts。
• 「EU顧客がユーザーデータをEU内に保持しなければならない。」— EUのRegionを選ぶ。

FAQ — AWSグローバルインフラストラクチャのよくある質問

Q1. AWS RegionとAvailability Zoneの違いは何か？

AWSグローバルインフラストラクチャのRegionは、複数のAvailability Zoneを含む地理的なエリアだ。AZはそのRegion内の1つ以上の物理的に独立したデータセンターで、独立した電源・冷却・ネットワークを持つ。コンプライアンスとレイテンシーのためにRegionを選び、高可用性のためにそのRegion内の複数のAZを選ぶ。AWSグローバルインフラストラクチャのすべてのRegionは少なくとも3つのAZを持ち、通常は数十km離れているが低レイテンシーのAWS所有光ファイバーで接続されている。

Q2. Edge LocationsはAvailability Zonesと同じか？

異なる。Edge LocationsはAvailability Zonesとは別物で、EC2インスタンスやS3バケットなどの顧客ワークロードをホストしない。Edge LocationsはCloudFront・Route 53・Global AcceleratorがビューワーのそばでユーザートラフィックをTLS終端するために使用するAWSグローバルインフラストラクチャのPoPレイヤーだ。Region内のAZsはコンピューティングとストレージが存在する場所だ。Edge Locationsをインフラの「ラストマイル」、AZsを「データセンターコア」と考えてよい。

Q3. Local ZoneとWavelength Zoneはいつ使い分けるか？

公共インターネット経由で特定の大都市圏のユーザーに対して単桁ミリ秒のレイテンシーが必要な場合（ゲーミング・メディアレンダリング・ライブ動画）はLocal Zoneを使う。ユーザーが特定の5Gモバイルキャリアを通じて接続し、トラフィックがそのキャリアのネットワーク内に留まる必要がある場合（コネクテッドカー・5G上のAR/VR・産業IoT）はWavelength Zoneを使う。どちらもAWSグローバルインフラストラクチャの拡張機能で親Regionに紐づくが、アクセス経路が異なる。

Q4. AWSはRegion間でデータを自動的にレプリケートするか？

しない。デフォルトではAWSグローバルインフラストラクチャは、作成したRegion内にデータを保持する。S3 Cross-Region Replication・DynamoDB Global Tables・Aurora Global Database・AWS Backupクロスリージョンコピーはすべてオプトイン機能だ。このデフォルトは意図的だ：データ主権を保護し、予期しない課金を避ける。多くのCLF-C02問題がこれに絡む——設定せずにレプリケーションを前提にしないこと。

Q5. AWS Regionはどうやって選ぶか？

CLF-C02では4つの基準を順番に評価する：（1）コンプライアンス・データレジデンシー——法的制約を満たさないRegionを除外する。（2）ユーザーへのレイテンシー——最も近いRegionを選ぶ。（3）サービス可用性——必要な特定のサービスがそのRegionに存在するか確認する。（4）コスト——オンデマンド料金を比較し、us-east-1が通常最安値であることを認識する。4つのうち1つでも欠けると、シナリオに対してRegionの選択が誤りになる。

Q6. AWS OutpostsはRegionと同じか？

異なる。AWS Outpostsはオンプレミスに設置され、親Regionに接続するAWSグローバルインフラストラクチャのハードウェアだ。独立したRegionではない。Outpostsラックをデプロイすると、親RegionからVPCを拡張し、IAM・コントロールプレーンはその親Regionに残る。Outpostsは低レイテンシーのローカルワークロード・Regionが存在しない場所でのデータレジデンシー・オンプレミスシステムとの緊密な統合に正しい答えだが、常に親AWSリージョンの子だ。

Q7. 高可用性においてAWSグローバルインフラストラクチャはなぜ重要か？

AWSグローバルインフラストラクチャの各レイヤーが異なる障害分離の境界を提供するからだ。1つのRegion内のMulti-AZデプロイはデータセンターレベルの障害から保護する。マルチリージョンアーキテクチャはRegion全体の停止と大都市圏全体に影響する自然災害から保護する。Edge Locations・Regional Edge Caches・Global Acceleratorを組み合わせることでネットワークエッジの耐障害性が増す。この階層を理解することは、CLF-C02試験のRPO・RTO・可用性目標に関するシナリオ問題に答える最速の方法だ。

AWSグローバルインフラストラクチャ — 参考リンク

• AWSグローバルインフラストラクチャの概要 — https://aws.amazon.com/about-aws/global-infrastructure/
• RegionsとAvailability Zones — https://aws.amazon.com/about-aws/global-infrastructure/regions_az/
• AWS Local Zones — https://aws.amazon.com/about-aws/global-infrastructure/localzones/
• AWS Wavelength — https://aws.amazon.com/wavelength/
• AWS Outpostsファミリー — https://aws.amazon.com/outposts/
• Amazon CloudFrontグローバルエッジネットワーク — https://aws.amazon.com/cloudfront/features/
• CLF-C02 試験ガイド v1.0（PDF）— https://d1.awsstatic.com/training-and-certification/docs-cloud-practitioner/AWS-Certified-Cloud-Practitioner_Exam-Guide.pdf