第 9 章 高パフォーマンスなアーキテクチャの設計（24%）
ネットワークの設計
この章で学ぶこと
- 適切なユースケースを伴うエッジネットワーキングのサービス（CloudFront、Global Accelerator）
- ネットワークアーキテクチャの設計（サブネットの階層、ルーティング、IP アドレッシング）
- ロードバランシングの概念（Application Load Balancer）
- ネットワーク接続のオプション（AWS VPN、Direct Connect、AWS PrivateLink）
VPC を作るときに決めるのは CIDR ブロック（IP の範囲）だ。後から広げるのは面倒なので、最初に余裕を持たせる。
| 決めること | 押さえる数字・考え方 |
|---|---|
| VPC の CIDR | /16 〜 /28 の範囲で指定する。あとから追加の CIDR は足せる |
| サブネットの大きさ | 各サブネットで 5 個の IP が予約される（使えるのは「個数 − 5」） |
| 層の分け方 | パブリック（受ける）／プライベート（アプリ）／プライベート（DB）の 3 層が基本 |
| AZ の数 | 最低 2 つ、できれば 3 つにまたがらせる |
| オンプレとの重複 | CIDR が重なると繋げない。 将来の接続を考えて決める |
補足
予約される 5 個は、ネットワークアドレス、VPC ルーター、Amazon が提供する DNS、将来のための予約、ブロードキャストアドレスだ。/24（256 個）なら実際に使えるのは 251 個になる。小さすぎるサブネットを切ると、ASG が増やしたいときに IP が足りなくなる。
繋ぎ方は 2 つある。数が少ないならピアリング、増えるなら Transit Gateway。
| VPC ピアリング | AWS Transit Gateway | |
|---|---|---|
| 形 | 1 対 1 で繋ぐ | 中央のハブに集める |
| 推移性 | 無い。 A-B と B-C があっても A-C は通らない | ある。 ハブ経由で全部つながる |
| 数が増えると | 組み合わせが爆発する（N × (N−1) / 2 本） | 各 VPC から 1 本ずつ |
| オンプレとの接続 | できない | VPN や Direct Connect もまとめられる |
| CIDR の重複 | 不可 | 不可 |
| 料金 | データ転送のみ | アタッチメント課金＋データ処理料 |
試験では
「VPC が 3 つ以上」「オンプレも含めてまとめたい」は Transit Gateway。ピアリングが推移しないことを使った設問（A から C に届かない理由）も出る。
CloudFront と Global Accelerator はどちらもエッジを使うので混ざりやすい。だが役割がはっきり違う。キャッシュするかどうかだ。
| Amazon CloudFront | AWS Global Accelerator | |
|---|---|---|
| 何をするか | エッジにキャッシュして返す | AWS のバックボーンを通して最短で届ける |
| キャッシュ | する | しない |
| 扱えるもの | HTTP / HTTPS（静的も動的も） | TCP / UDP。HTTP 以外も |
| IP | 可変 | 固定のエニーキャスト IP が 2 つ |
| 向く場面 | 画像・動画・Web の配信 | ゲーム・IoT・VoIP・固定 IP が要る |
| 障害時 | オリジンを切り替え | 健全なリージョンへ速く切り替わる |
試験では
「静的コンテンツの配信を速くしたい」は CloudFront。「UDP のゲームトラフィック」「固定 IP が要る」「リージョン間のフェイルオーバーを速く」は Global Accelerator。キャッシュが効かない動的な通信を速くしたいなら Global Accelerator が候補になる。
補足
CloudFront から S3 を配るときは OAC（Origin Access Control） を使い、S3 バケットは公開しない。「S3 を公開せずに CloudFront 経由だけで配りたい」という設問の答えがこれ。また、署名付き URL / 署名付き Cookie で、期限付きの限定公開ができる。
第 4 章では疎結合の道具として見た。性能の観点では次の点が問われる。
| 要件 | 答え |
|---|---|
| 極端に多いリクエスト・低遅延 | NLB（L4 なので軽い） |
| 固定 IP・Elastic IP を割り当てたい | NLB |
| 送信元 IP をそのまま後ろへ渡したい | NLB（ALB は X-Forwarded-For ヘッダーで渡す） |
| URL のパスやホスト名で振り分けたい | ALB |
| WebSocket・HTTP/2 | ALB |
| サードパーティの検査装置を挟みたい | GWLB |
| やりたいこと | 使うもの | 押さえること |
|---|---|---|
| オンプレと安定した帯域で繋ぐ | Direct Connect | 1 / 10 / 100 Gbps。ホスト型はもっと細かい |
| すぐ・安く繋ぐ | Site-to-Site VPN | インターネット経由。帯域は揺れる |
| 自社サービスを相手の VPC に見せる | PrivateLink | ENI として出す。VPC 全体は見せない |
| AWS のサービスへ VPC 内から | VPC エンドポイント | S3 と DynamoDB はゲートウェイ型（無料） |
| 複数の VPC とオンプレをまとめる | Transit Gateway | ハブとして経路を集約する |
補足
VPC の中では ジャンボフレーム（MTU 9001） が使える。大きなデータを転送するときの効率が上がる。ただしインターネットへ出る経路では使えない。
遅延を詰める最後の手段は物理的な配置だ。4 つの選択肢があり、近づく順に並べられる。
| 選択肢 | どこに置かれるか | 向く場面 |
|---|---|---|
| リージョン | AWS のデータセンター | ふつうはこれ |
| AWS Local Zones | 大都市の近く | そのエリアで一桁ミリ秒が要る |
| AWS Outposts | 自社のデータセンターの中 | 法令やレイテンシーで持ち出せない |
| AWS Wavelength | 通信事業者の 5G ネットワークの中 | モバイル端末に極めて近い処理 |
試験では
「データを自社の建物から出せない」は Outposts。「特定の都市で一桁ミリ秒」は Local Zones。「5G の端末の近く」は Wavelength。この 3 つは要件の語がそのまま答えになる。
| 問題文に出る語 | 答えの方向 |
|---|---|
| 静的コンテンツ・動画を世界に配信 | Amazon CloudFront |
| S3 を公開せずに配りたい | CloudFront ＋ OAC |
| UDP・固定 IP・リージョン間の速い切り替え | AWS Global Accelerator |
| VPC が増えて経路が複雑 | AWS Transit Gateway |
| A から C に届かない（ピアリング） | 推移しない。TGW か直接ピアリング |
| 自社サービスを他社の VPC に見せる | AWS PrivateLink |
| 安定した帯域でオンプレと | AWS Direct Connect |
| 特定の都市で一桁ミリ秒 | AWS Local Zones |
| 建物からデータを出せない | AWS Outposts |
| IP が足りなくなった | サブネットの設計を見直す（予約 5 個に注意） |
シナリオ演習
世界中の利用者へ動画を配信している。オリジンは S3 で、転送料が月々の請求の大半を占めている。
補足
答え：CloudFront を前に置き、キャッシュの有効期間を伸ばす。S3 は公開せず OAC 経由にする。
AWS のオリジンから CloudFront への転送は無料で、CloudFront からインターネットへの単価は S3 から直接出すより安い。キャッシュに当たればオリジンまで取りに行かない。
シナリオ演習
オンラインゲームのサーバーを 3 つのリージョンで動かしている。通信は UDP で、クライアントには固定の接続先 IP を配りたい。
補足
答え：AWS Global Accelerator を使う。
CloudFront は HTTP / HTTPS 用でキャッシュが前提なので、UDP は扱えない。Global Accelerator は固定のエニーキャスト IP を持ち、健全なリージョンへ速く切り替わる。
この章のまとめ
- VPC の CIDR に指定できる範囲
- サブネットごとに予約される IP の数
- /24 のサブネットで実際に使える IP の数
- VPC ピアリングは推移するか
- VPC とオンプレをまとめるハブ
- CloudFront はキャッシュするか
この章の根拠
最終確認 2026-10-04 ／ 対応バージョン DEA 2026-05-04 改訂版