週2VPC

2026-08-09（日）VPC（ネットワークの土台）

この記事の目次
  1. 予習ポイント
  2. 図解イメージ（言葉で説明）
  3. 視聴後に自分でチェックしたい項目

1. 【予習ポイント】

  • VPCピアリングの絶対ルール「推移的ルーティングの禁止」 [p.40, p.51-52]
    • 要点: 2つのVPC間をパブリックインターネットを経由せずにプライベートIPアドレスで直接接続する機能ですが [p.40]、「A ⇔ B」および「B ⇔ C」が繋がっていても、「A ⇔ C」の通信（Bを中継した通信）は物理的に一切行えません [p.40, p.51-52]。繋ぎたい場合は「A ⇔ C」を直接ピアリングする必要があります [p.40]。
  • VPCフローログによる通信の「可視化」とトラブルシューティング [p.41, p.245]
    • 要点: VPC内のネットワークインターフェイス（ENI）を通過するトラフィック（送信元/宛先IP、ポート、パケット数、許可/拒否など）をIPレベルで記録する監査・監視機能です [p.41]。「なぜかEC2にWebアクセスできない」という障害時、セキュリティグループで拒否（REJECT）されていないかを特定するために必須となります [p.41, p.245]。
  • オンプレミス接続：DX（専用線）、VPN（仮想トンネル）、Transit Gateway（中央ハブ）の使い分け [p.42, p.44, p.46]
    • 要点: 接続方法を天秤にかける基準は「通信の安定性・帯域幅」と「接続数（複雑さ）」です。
      • AWS Direct Connect (DX): インターネットを通らない物理的な専用線。極めて高い帯域幅、低遅延、通信の完全な安定性が必要な基幹システム移行に適合 [p.42]。
      • AWS Site-to-Site VPN: インターネット上に暗号化トンネルを作る。安価かつ数時間で即時接続したい場合、またはDX開通までの暫定バックアップとして適合 [p.42, p.44]。
      • AWS Transit Gateway: VPCやVPN、DXの接続数が3つ以上に増え、ネットワークがスパゲッティ状態（メッシュ状）になるのを防ぐため、中央で接続をスマートに一元集約するルートハブ [p.46-47, p.52]。

2. 【図解イメージ（言葉で説明）】

「AWSクラウド大国」と「オンプレミス本島」を結ぶ巨大物流網

  • VPCピアリング ＝ 「ビル間を直結するプライベート空中渡り廊下」 [p.40]
    • 一般の道路（インターネット）に降りることなく、2つのビル（VPC-AとVPC-B）の間を直通で台車（データパケット）を往復させられる専用の通路です [p.40]。ただし、この廊下は「隣のビル」にしか行けません。ビルBの廊下を勝手に通り抜けて、その先のビルCへ荷物を運ぶような「通り抜け（推移的ルーティング）」は警備上の仕様で固く禁じられています [p.40, p.51-52]。
  • VPCフローログ ＝ 「各オフィスの玄関ドアに設置された入退館センサーカメラ」 [p.41]
    • 廊下や部屋の入り口（仮想NIC：ENI）を通過しようとしたすべての荷物の「送り主」「宛先」「中身の種類（ポート）」を無言でレコーディングし続けるカメラです [p.41]。荷物が無事に「通過（ACCEPT）」したか、警備員（セキュリティグループ）に「門前払い（REJECT）」されたかもすべて記録台帳（CloudWatch Logs等）に書き出します [p.41, p.245]。
  • Site-to-Site VPN ＝ 「公道（高速道路）の中に設けた、自社専用の防弾トンネル」 [p.44]
    • オンプレミス本島から海を渡ってAWS大国まで、一般人も走る公共の高速道路（インターネット）を利用しますが、データを頑丈な装甲車に閉じ込め、周囲から中身を一切覗かれない防弾仕様のトンネル（暗号化カプセル）を作って安全に物資を運びます [p.44]。
  • Direct Connect ＝ 「本島と大国を海底で直結する、自社専用のプライベート貨物鉄道」 [p.42]
    • 一般の公共道路は一切使わず、海を越えて自社オフィスからAWSデータセンターまで、他人が絶対に入り込めない「完全物理占有のレール（専用線）」を敷いて直接荷物列車を走らせます [p.42]。渋滞（ネットワーク混雑）が絶対に起きず、時間通り（超低遅延）に大量の荷物を輸送できます [p.42]。
  • Transit Gateway ＝ 「ハブ＆スポークを束ねる、大国の中央巨大ジャンクションターミナル駅」 [p.46]
    • 各オフィスビル（VPC）やオンプレミス本島からの路線（VPN、DX）が何十本も増えてくると、路線同士を個別に繋ぐのは配線ミスのもとです。そこで、街の中心に超巨大な統合ジャンクション駅を置き、すべての電車（通信）を一度この駅に集約させて、スマートにそれぞれの行き先（ビルや本島）へと乗り換え・転送処理をさせます [p.46-47]。

3. 【視聴後に自分でチェックしたい項目】

  • ⬜︎ チェック1: VPCフローログの「2大出力先」と使い分け [p.245]
    • 有効化の手順を見た後、ログの転送先として「Amazon S3」と「CloudWatch Logs」が選べる理由（検索や即時アラートはCloudWatch、長期の格安保管はS3）を意識して確認できたか？
  • ⬜︎ チェック2: ルートテーブルに記述する「ピアリング宛先」の書き方 [p.35, p.40, p.51]
    • VPCピアリングを機能させるために、双方のサブネットの「ルートテーブル」に、対向先VPCのアドレス（CIDR）とターゲットとして pcx-xxxxxx（ピアリング接続ID）を互いに書き込む必要がある仕組みをイメージできたか？
  • ⬜︎ チェック3: 接続数（VPC数）が増えた際、なぜTransit Gatewayが必須になるか [p.46-47, p.52]
    • 「接続数が少なければVPCピアリングや個別VPNで安価に直結」し、「接続数が増加してスケールアップしたらTransit Gatewayでハブ＆スポーク型（スター型トポロジー）に切り替える」という、アーキテクチャのトレードオフを論理的に説明できるか？
  • ⬜︎ チェック4: Direct Connectの障害に備えた「Site-to-Site VPN」の冗長化設計パターン [p.42, p.44]
    • Direct Connectという高価で信頼性の高い専用線があるにもかかわらず、なぜ安価なインターネットVPNを「バックアップ用の冗長ルート」としてあえて並列マッピングしておくのか、そのコストと可用性のバランス（信頼性の設計原則）を理解できたか？