はじめまして！短足犬です。
ちいかわも草むしり検定5級に受かったというところで、私も資格を取ろうと思い、AWS ソリューションアーキテクトを取得しようとしています！
今回は「グローバルインフラストラクチャとネットワーク」についてまとめてみました！
目次
- 結論（この記事の要点）
- リージョンとは
- アベイラビリティゾーン（AZ）とは
- エッジロケーションとは
- CloudFront（CDN）とは
- Local Zone とは
- Outposts とは
- AWS のインフラ構造がこうなっている理由
- よくある誤解と注意点
- 実務での使いどころ（Webアプリ視点）
- まとめ
結論（この記事の要点）
AWS のグローバルインフラは「どの距離で AWS を使うか」という視点で理解すると、全体像が一気に整理できます。
リージョン（Region）
地理的な大枠。国・地域単位で分かれる。データ主権や災害対策の単位。
アベイラビリティゾーン（AZ）
リージョン内の独立したデータセンター群。高可用性の基本単位。
エッジロケーション（Edge Location）
CloudFront や Route53 が動作する、ユーザーに最も近いキャッシュ配信拠点。
CloudFront（CDN）
エッジでコンテンツを配信し、レイテンシを最小化する仕組み。
Local Zone
都市部に近い低レイテンシ拠点。ゲーム・映像・医療などで利用。
Outposts
オンプレに AWS を持ち込む仕組み。データを外に出せない環境向け。
これらはすべて「遠い（リージョン）→ 近い（AZ）→ もっと近い（Edge）→ ほぼオンプレ（Outposts）」という階層構造で理解できます。
AWS の設計思想や SAA の出題意図もこの構造に沿っているため、全体像をつかみやすくなります。
リージョンとは
リージョンは、AWS が世界中に配置している「地理的な大枠の単位」です。
国・地域ごとに分かれており、データ主権（どの国にデータを置くか）や災害対策の観点で重要です。
1つのリージョンは複数の AZ（アベイラビリティゾーン）で構成されます。
リージョンの特徴
- 国・地域単位で分かれている（例：東京、バージニア、シンガポール）
- リージョン間は物理的に離れているため、レイテンシが大きい
- データ主権の要件に対応するために分割されている
よくある誤解
- リージョン＝データセンターではない（実際は複数の AZ の集合）
- リージョン間は高速ではない（数十〜数百 ms のレイテンシ）
- リージョンをまたぐ同期レプリケーションは基本的に困難
実務での使いどころ
- 日本国内にデータを置きたい → ap-northeast-1（東京）
- 災害対策で別リージョンにバックアップを配置
- 海外向けサービスでユーザーに近いリージョンを選択
アベイラビリティゾーン（AZ）とは
アベイラビリティゾーン（AZ）は、リージョン内に存在する「独立したデータセンター群」です。
電源・冷却・ネットワークなどのインフラが物理的に分離されており、
1つの AZ が障害で落ちても、他の AZ が稼働し続けるように設計されています。
AWS の高可用性（HA）を支える最重要コンポーネントです。
AZ の特徴
- 1つのリージョンに 2〜6 個の AZ が存在する
- AZ 同士は専用の高速ネットワークで接続（レイテンシは数ミリ秒）
- 電源・ネットワーク・冷却が独立しているため障害に強い
- マルチ AZ 構成により高可用性を実現できる
よくある誤解
- AZ＝1つの建物ではない（複数のデータセンターで構成される）
- AZ 間は高速だが、リージョン間は高速ではない（数十〜数百 ms）
- AZ 障害は「起きない」わけではない（実際に過去に発生している）
実務での使いどころ
- Web サーバーを複数 AZ に配置してサービス停止を防ぐ
- RDS のマルチ AZ 構成で DB の耐障害性を高める
- Auto Scaling をマルチ AZ で動かし、障害時も自動復旧
エッジロケーションとは
エッジロケーションは、ユーザーに最も近い場所に配置された AWS のキャッシュ配信拠点です。
主に CloudFront（CDN） や Route53（DNS） が動作し、
静的コンテンツや DNS 応答を高速に返すことで、ユーザー体験を大幅に向上させます。
エッジロケーションの特徴
- 世界中に 600 箇所以上（2024 時点）と圧倒的に多い
- ユーザーに最も近い場所でキャッシュを返すためレイテンシが最小
- CloudFront のキャッシュヒットによりオリジンサーバーの負荷を軽減
- Route53 の DNS 応答もエッジで処理されるため高速
よくある誤解
- エッジロケーション＝リージョンではない（全く別の仕組み）
- エッジロケーションには EC2 や RDS を置けない
- エッジロケーションは「データセンター」ではなく、キャッシュ配信に特化した拠点
実務での使いどころ
- 静的サイト（画像・CSS・JS）の高速配信
- 動画配信やゲームアップデートなど大容量データの高速化
- グローバルユーザー向けサービスのレイテンシ改善
- DNS 応答を高速化して Web サイトの初回表示を早くする
CloudFront（CDN）とは
CloudFront は、AWS が提供するグローバルな CDN（コンテンツ配信ネットワーク）サービスです。
世界中のエッジロケーションにコンテンツをキャッシュし、
ユーザーに最も近い場所から高速に配信することでレイテンシを最小化します。
静的ファイルだけでなく、動的コンテンツや API の高速化にも利用できます。
CloudFront の特徴
- 世界中のエッジロケーションからキャッシュを返すため高速
- オリジンサーバー（S3 / ALB / EC2 など）の負荷を大幅に軽減
- HTTPS / WAF / OAC（旧 OAI）などセキュリティ機能が豊富
- キャッシュポリシーや TTL を細かく制御できる
- 動的コンテンツや API の高速化にも対応
よくある誤解
- CloudFront＝静的ファイル専用ではない（API や動的ページも高速化できる）
- CloudFront はリージョンではなく、エッジロケーションで動作する
- CloudFront を使うと必ずキャッシュされるわけではない（キャッシュポリシー次第）
- CloudFront は「S3 のおまけ」ではなく独立した CDN サービス
実務での使いどころ
- 画像・CSS・JS など静的ファイルの高速配信
- 動画配信や大容量データの高速化
- API のレスポンス高速化（キャッシュ or エッジ最適化）
- WAF と組み合わせてセキュリティを強化
- S3 をオリジンにして Web サイトを高速に配信
Local Zone とは
Local Zone は、AWS リージョンよりも「都市部に近い場所」に配置された低レイテンシ拠点です。
通常のリージョンは都市から離れた場所にありますが、
Local Zone はユーザーの近くに設置されており、
数ミリ秒レベルの超低レイテンシが必要なワークロードに向いています。
Local Zone の特徴
- ユーザーの近くにあるためレイテンシが非常に小さい
- EC2 / EBS / VPC など一部のサービスをローカルで利用可能
- メインのリージョンと接続して動作する「サテライト拠点」
- ゲーム、映像制作、AR/VR、医療などリアルタイム性が必要な用途に最適
よくある誤解
- Local Zone はリージョンではない（あくまでリージョンの延長）
- Local Zone だけで完結するわけではない（多くのサービスはリージョン側に依存）
- AZ とも異なる（AZ はリージョン内、Local Zone は都市部）
実務での使いどころ
- ゲームサーバーをユーザーの近くに置いて遅延を最小化
- 動画編集・VFX など大容量データを扱うワークロード
- 医療画像処理などリアルタイム性が求められる処理
- AR/VR、メタバースなど低レイテンシが必須のアプリケーション
Outposts とは
Outposts は、AWS のインフラ（EC2 / EBS / RDS など）をそのままオンプレミスに持ち込めるサービスです。
AWS が提供する専用ハードウェアを自社データセンターに設置し、
オンプレなのに AWS と同じ API・同じコンソールで操作できるという特徴があります。
データを外に出せない環境や、超低レイテンシが必要なケースで利用されます。
Outposts の特徴
- AWS が提供する物理ラックをオンプレに設置して利用
- EC2 / EBS / RDS など一部の AWS サービスをローカルで実行可能
- オンプレと AWS クラウドを一体化したハイブリッド構成を実現
- レイテンシが極めて小さく、データを外に出せない要件にも対応
よくある誤解
- Outposts＝オンプレ版 AWS 全部ではない（利用できるサービスは限定的）
- Outposts は「オンプレの代わり」ではなく「AWS の延長」
- 普通の Web アプリにはオーバースペック（金融・医療・工場向け）
実務での使いどころ
- データを外部に出せない金融・医療・公共機関
- 工場や店舗など、レイテンシが極めて重要な環境
- オンプレとクラウドを統一した運用をしたい場合
- クラウド移行の途中で段階的に AWS を導入したいケース
AWS のインフラ構造がこうなっている理由
AWS のグローバルインフラは、単に世界中にデータセンターを置いているわけではなく、
「可用性」「レイテンシ」「データ主権」「スケール」という4つの要件を満たすために最適化された構造になっています。
① 可用性を最大化するため（リージョン × AZ）
AWS は「障害が起きる前提」で設計されています。
そのため、1つの建物が落ちてもサービスが止まらないように、
複数の AZ を独立させて配置
- AZ は電源・冷却・ネットワークが独立
- AZ 間は高速ネットワークで接続
- マルチ AZ 構成で高可用性を実現
② レイテンシを最小化するため（Edge / Local Zone）
ユーザーに近い場所で処理するほど通信は速くなります。
そのため AWS は、リージョンよりさらに近い場所に
エッジロケーションや Local Zone を配置しています。
- CloudFront がエッジでキャッシュを返す → 表示が速い
- Local Zone が都市部にある → 数ミリ秒の低レイテンシ
③ データ主権に対応するため（リージョン分割）
国によって「データは国内に置くべき」という法律があります。
そのため AWS は国・地域ごとにリージョンを分けています。
- 日本 → 東京リージョン
- アメリカ → バージニア、オレゴンなど複数
- EU → フランクフルト、アイルランドなど
④ オンプレとの統合を可能にするため（Outposts）
金融・医療・工場など、データを外に出せない環境ではクラウドだけでは不十分です。
そこで AWS は Outposts を提供し、オンプレでも AWS を使えるようにしています。
まとめ
AWS のインフラ構造は、
「遠い → 近い → もっと近い → ほぼオンプレ」
という階層で整理されており、
これはすべて 可用性・レイテンシ・データ主権・スケール を満たすための設計です。
よくある誤解と注意点
AWS のグローバルインフラは用語が似ているため、
誤解しやすいポイントがいくつかあります。
SAA でも頻出なので、ここで一度整理しておきます。
① リージョンと AZ の誤解
- リージョン＝データセンターではない（複数の AZ の集合）
- AZ＝1つの建物ではない（複数のデータセンターで構成）
- リージョン間は高速ではない（数十〜数百 ms）
② エッジロケーションの誤解
- エッジロケーションに EC2 や RDS は置けない
- エッジロケーションはリージョンの一部ではない（別の仕組み）
- CloudFront のキャッシュは万能ではない（キャッシュポリシー次第）
③ CloudFront の誤解
- CloudFront＝静的ファイル専用ではない（API や動的ページも高速化）
- CloudFront を使っても必ず速くなるわけではない（キャッシュミス時は遅い）
- CloudFront は S3 の付属機能ではなく独立した CDN
④ Local Zone の誤解
- Local Zone はリージョンの代わりではない（補完的な存在）
- Local Zone だけで完結しない（多くのサービスはリージョン側に依存）
- AZ と Local Zone は別物（AZ はリージョン内、Local Zone は都市部）
⑤ Outposts の誤解
- Outposts＝オンプレ版 AWS 全部ではない（使えるサービスは限定的）
- Outposts はオンプレの完全代替ではない（用途は金融・医療・工場など）
- 普通の Web アプリにはオーバースペック
⑥ レイテンシに関する誤解
- AZ 間は高速だが、リージョン間は高速ではない
- エッジロケーションは最速だが、計算処理はできない
- Local Zone は低レイテンシだが、サービスは限定的
⑦ 可用性に関する誤解
- マルチ AZ にすれば絶対に落ちないわけではない
- リージョン障害は稀だがゼロではない
- バックアップは別リージョンに置くのが基本
これらの誤解を避けることで、
AWS のインフラ構造を正しく理解でき、
SAA の問題でも迷わなくなります。
実務での使いどころ（Webアプリ視点）
ここまで紹介した AWS のグローバルインフラは、
単なる知識ではなく Web アプリの実務で直接役立つものばかりです。
ここでは、実際のシステム設計でどう使うのかを整理します。
① 高可用性（HA）構成
Web アプリが「落ちない」ための基本戦略です。
- EC2 をマルチ AZ に配置して片方の障害に備える
- RDS マルチ AZで DB 障害時に自動フェイルオーバー
- ALB + Auto Scalingで自動復旧・自動スケール
- Redis（ElastiCache）は マルチ AZ レプリケーションで耐障害性を確保
② レイテンシ最適化（高速化）
ユーザー体験を向上させるための施策です。
- CloudFrontで静的ファイル（画像・CSS・JS）を高速配信
- API を エッジ最適化してレスポンス改善
- Local Zoneで都市部ユーザー向けの低遅延処理
- Route53 の レイテンシベースルーティングで最適なリージョンに誘導
③ ハイブリッド構成（オンプレ＋AWS）
企業の事情でオンプレが残る場合に有効です。
- Outpostsでオンプレに AWS を持ち込み、統一運用を実現
- データ主権が厳しい環境で AWS を利用するための選択肢
- 工場・医療・金融など、データを外に出せない業界で活用
④ グローバル展開
海外ユーザーがいるサービスで必須の設計です。
- ユーザーに近い リージョンを選択して高速化
- CloudFrontで世界中にキャッシュを展開
- Route53 の 地理的ルーティングで地域ごとに最適な配信
⑤ コスト最適化
インフラ費用を抑えつつ性能を維持するための工夫です。
- CloudFront のキャッシュで オリジンの負荷と通信量を削減
- AZ 障害対策をしつつ、必要な部分だけマルチ AZ にする
- Local Zone を使わず CloudFront で十分なケースも多い
Web アプリの実務では、
「どの距離で AWS を使うか」を意識するだけで
設計の質が一気に上がります。
まとめ
AWS のグローバルインフラは、一見すると用語が多くて複雑に見えますが、
「どの距離で AWS を使うか」という視点で整理すると一気に理解が進みます。
距離ベースで整理するとこうなる
- リージョン：地理的な大枠（国・地域単位）
- AZ：高可用性を実現するための独立したデータセンター群
- エッジロケーション：ユーザーに最も近いキャッシュ配信拠点
- CloudFront：エッジで高速配信する仕組み
- Local Zone：都市部に近い低レイテンシ拠点
- Outposts：オンプレに AWS を持ち込む仕組み
この構造が生まれた理由
- 可用性を最大化するため（リージョン × AZ）
- レイテンシを最小化するため（Edge / Local Zone）
- データ主権に対応するため（リージョン分割）
- オンプレとの統合を可能にするため（Outposts）
実務でのポイント
- Web アプリは基本的に マルチ AZ が前提
- 高速化には CloudFront が最も効果的
- 低レイテンシが必要なら Local Zone
- オンプレ統合が必要なら Outposts
インフラ構造のマトリクス（距離 × 目的）
| 距離 | コンポーネント | 主な目的 | 代表的な用途 |
|---|---|---|---|
| 最も遠い | リージョン | データ主権 / 災害対策 | 国・地域ごとのデータ配置、DR構成 |
| 遠い | AZ（アベイラビリティゾーン） | 高可用性（HA） | マルチ AZ 構成、RDS フェイルオーバー |
| 近い | エッジロケーション | キャッシュ / レイテンシ最適化 | CloudFront、Route53、静的配信 |
| もっと近い | Local Zone | 超低レイテンシ処理 | ゲーム、映像制作、医療画像処理 |
| ほぼオンプレ | Outposts | ハイブリッド / データ主権 | 金融・医療・工場などオンプレ必須環境 |
このマトリクスを見ると、AWS のインフラ構造が
「距離 × 目的」で綺麗に整理されていることがわかります。
SAA の理解にも、実務の設計にも役立つ視点です。
この記事が、あなたの AWS 学習や実務設計の助けになれば嬉しいです！
