はじめに
下図構成図が示す端末 → EC2のリクエストおよびEC2 → 端末のレスポンスについて、ネットワーク的にどのように通信されているか正しく理解できているでしょうか。
私自身がルートテーブルの理解ではまった経験があるのでここに記録します。
私について
2026年1月からITエンジニア完全未経験でSESに転職しました。
前職は自動車業界に10年程度在籍していました。
保有資格は下記3つ
- AWS CLF
- AWS SAA
- Linuc レベル1
前職在籍中に時間を作って独学で学習し、1年ほどかけて取得しました。
いずれも試験問題を解くだけの知識としては保有しておりますが、実際にAWSマネジメントコンソールやターミナル上での操作をほとんどやったことがない所謂エアプ状態です。
私の頭の中
ルートテーブルについての疑問の始まりは先ほどの構成図において、端末からのリクエスト時にInternetGateway → EC2のルーティングがどのようにおこなわれるのかと考えたのがきっかけです。
端末から送信されるIPパケット情報が下記のとき
| 送信元IP | 宛先IP |
|---|---|
| 端末のグローバルIP | EC2のパブリックIP（AWS管理のグローバルIP） |
InternetGatewayに到達した段階でEC2のパブリックIPはプライベートIPに変換され、VPC作成時に自動生成される下記メインルートテーブルを確認し、IPパケット情報の宛先IPがVPCのCIDRとマッチするため、ターゲットであるlocalに通信がおこなわれ、EC2に到達する。
| 送信先 | ターゲット |
|---|---|
| VPCのCIDR | local |
と、思っていましたが間違ってました…
ルートは、サブネットまたはゲートウェイからのネットワークトラフィックの経路を決定します。
ルートテーブルの関連付け — ルートテーブルとサブネット、インターネットゲートウェイ、または仮想プライベートゲートウェイの間の関連付け。
サブネットルートテーブル — サブネットに関連付けられたルートテーブル。
ゲートウェイルートテーブル — インターネットゲートウェイまたは仮想プライベートゲートウェイに関連付けられたルートテーブル。
ルートテーブルは、インターネットゲートウェイまたは仮想プライベートゲートウェイに関連付けることができます。ルートテーブルがゲートウェイに関連付けられている場合、ゲートウェイルートテーブルと呼ばれます。ゲートウェイルートテーブルを作成して、VPC に入るトラフィックのルーティングパスを細かく制御できます。例えば、インターネットゲートウェイを介して VPC に入るトラフィックを VPC 内のミドルボックスアプライアンス (セキュリティアプライアンスなど) にリダイレクトして、そのトラフィックをインターセプトできます。
上記引用からわかるようにルートテーブルは2種類存在します。
普段私たちがよく使うルートテーブルはサブネットルートテーブルであって、ゲートウェイルートテーブルは少し特殊用途のようで、セキュリティアプライアンスはセキュリティ目的で通信経路の途中に配置されるリソースやサービスを指します。
したがって、通常運用ではサブネットにルートテーブルが関連付けられることはあっても、InternetGatewayにルートテーブルは関連付けられていないということです。
つまり、私の頭の中のInternetGatewayに到達した際にメインルートテーブルを確認するっていうのは見当違いということですね。
じゃあInternetGateway → EC2のルーティングは内部的にどうやっているのか？
結論
端末 → IGW → EC2はざっくり説明すると下記のようになります。
- 端末からEC2のパブリックIPに向けて通信する
- インターネット上のルーターたちが、そのIPの持ち主であるAWSネットワークまで運ぶ
- AWSネットワークの中でそのパブリックIPがどのENIに対応しているかが分かる
- InternetGatewayがその対応関係を使って、ENI（EC2のプライベートIP）へ通信する
- NACLやセキュリティグループのチェックを受けて、EC2に到達
もう少し詳しく
前提構成
- 端末のグローバルIP：
203.0.113.10 - EC2のパブリックIP：
54.10.20.30 - EC2のプライベートIP：
10.0.1.25 - EC2はパブリックサブネットにある
（ルートテーブルには送信先：0.0.0.0/0、ターゲット：InternetGateway）
段階1：端末は何に向けて通信しているのか
端末はブラウザ等からhttp://54.10.20.30にアクセスする。
（またはDNS解決によりパブリックIPが取得される。）
このとき生成されるIPパケットは以下の通り。
送信元IP：203.0.113.10（ユーザー側）
宛先IP：54.10.20.30（EC2のパブリックIP）
ここで重要なのは、外部から見えているのはパブリックIPのみであり、EC2のプライベートIP（例：10.0.1.25）は認識されない。
段階2：端末内のルーティング
端末は自身のルーティングテーブルを参照し、宛先IPがローカルネットワーク外であると判断する。
その結果、通信はデフォルトゲートウェイ（家庭用ルータや社内ルータ）へ転送される。
段階3：インターネット上のルーティング
インターネット上のルータはすべて宛先IP54.10.20.30を基準に転送をおこなう。
その結果、通信はAWSが管理するネットワークへ到達する。
ポイント：インターネットは「IPアドレスの所有者」まで配送するだけであり、VPC内部の構造は関知しない
段階4：AWSネットワークでの処理
AWSは自身が保有するパブリックIPレンジを管理しているため、宛先IP54.10.20.30がAWS管理領域であることを認識できる。
さらにAWS内部では以下の対応関係が管理されている。
- パブリックIP
- ENI（Elastic Network Interface）
- プライベートIP
段階5：InternetGatewayでの処理
Internet Gatewayの役割：VPCとインターネット間のトラフィック中継
InternetGatewayは通常、ルートテーブルを参照して宛先IPを決定せずに代わりに段階4の対応関係を使用し、宛先IP54.10.20.30から対応するENIを特定し、そのENIに紐づくEC2へ転送します。
段階6：パブリックIPとプライベートIPの変換
外部から見えるIPはパブリックIPだが、VPC内部ではプライベートIPが使用される。
そのためAWS内部ではパブリックIP宛の通信を、対応するプライベートIPへ転送します。
段階7：VPC内でのアクセス制御
EC2に到達する前にNetwork ACL、セキュリティグループのチャックがおこなわれる。
問題なければ、EC2にリクエストが到達します。
レスポンスはどうなる？
EC2レスポンスを返すときは逆向きになります。
EC2から見れば、下記IPパケットで出したいです。
送信元IP: 10.0.1.25
宛先IP: 203.0.113.10
EC2側が送信するのでサブネットに関連付いたルートテーブルを参照します。
例えば、ルートテーブルが下記なら宛先203.0.113.10は0.0.0.0/0に一致するのでInternetGatewayへ出します。
| 送信先 | ターゲット |
|---|---|
| VPCのCIDR | local |
| 0.0.0.0/0 | InternetGateway |
その後、InternetGatewayが今度はプライベート側から来た通信を対応するパブリックIPで外へ出していきます。
まとめ
VPC外（インターネットなど）からVPC内のプライベートIPアドレス宛に届く通信は、AWSのネットワーク基盤によって直接対象のネットワークインターフェイス（ENI）へ配送されます。この際、通常のサブネットルートテーブルの「ルート」は参照されません。
ただし、ゲートウェイルートテーブルは例外です。
これはVPCに入る通信を意図的に特定の場所へ転送するための機能です。
役割: インターネットゲートウェイや仮想プライベートゲートウェイにルートテーブルを直接関連付けることができます。
挙動: これを設定すると、VPC外から入ってきたトラフィックを、本来の宛先に届く前にセキュリティアプライアンス（Firewall等）などへ強制的にルーティングできます。
さいごに
実はこの記事を書き始めた段階ではゲートウェイルートテーブルという存在を知りませんでした
（SAAまぐれ取得）
存在をしらなかったけど、InternetGatewayはデフォルトでVPCのメインルートテーブルを参照していると誤った理解をしていました。
アウトプットすることで知らなかった知識の定着も図れるのでアウトプットは大事ですね。