← AWSサービスの内部原理 コース
115. 1つのリクエストはVPCの中で何度も審査される — DNS・ルート・NACL・SGを貫く旅の地図
プライベートサブネットのアプリが放つ3種類のリクエストが、VPCの中でどんな検問を何度もくぐって目的地に着き、そして帰ってくるのか——本編で組み立ててきた全部品を1枚の地図に置いて追っていきます。
① 出発点は同じ、行き先で分かれる三叉路 — まず名前を引く
アプリ(送信元)プライベートサブネットのECSタスク / VPC接続Lambda
送信元 = プライベートIP(例 10.0.1.37)問い合わせる名前で応答が変わる
Route 53 ResolverVPCのCIDR先頭+2(例 10.0.0.2)に常駐
Amazon DNS server。再帰クエリを受けて名前→IPを返す公開サービス名s3.リージョン.amazonaws.com
プレフィックスリストに載るAWSのIP帯 → 経路A外部の公開名api.example.com
公開DNSがグローバルIPを返す → 経路Bプライベートゾーンdb.internal
VPC内のプライベートIPを返す → 経路C- Resolverの居場所は「primary private IPV4 CIDR range provisioned to your VPC plus two」= VPC CIDRの先頭+2、および 169.254.169.253(IPv4)/ fd00:ec2::253(IPv6)。クエリはリンクローカルアドレス経由で運ばれ「are not visible on the network」。
- 「The Amazon Route 53 Resolver only supports recursive DNS queries.」
- プライベートホストゾーンの名前解決には enableDnsHostnames と enableDnsSupport の両方を true にする必要がある。
- 注意: 「You cannot filter traffic to or from the Amazon DNS server using network ACLs or security groups.」——DNSクエリ自体は後述の検問の対象外。
どの経路でも旅の一歩目は同じ「名前を引く」。Resolverは分散データベースDNSのリゾルバそのもので、VPC+2番地に常駐している。返ってきたIPが公開のAWS帯なのか・外部のグローバルIPなのか・VPC内のプライベートIPなのかで、この先の運命が三叉路に分かれる。
② 最初の審査はルートテーブル — 「最も具体的な行」が勝つ
パケットの宛先IPResolverが返したIP宛に送信
一致した行のターゲットへ
ルートテーブル宛先→ターゲットを一意に引く検索テーブル
サブネットに紐づくlocal10.0.0.0/16(VPC内宛)
最長一致で勝つ → 経路CゲートウェイEPpl-xxxx(S3プレフィックスリスト)
0.0.0.0/0に勝つ → 経路ANATゲートウェイ0.0.0.0/0(どれにも負けた宛先の受け皿)
→ 経路B- 「we direct traffic using the most specific route that matches the traffic. This is known as the longest prefix match.」(例: 10.10.2.15/32 は 10.10.2.0/24 に優先)
- 経路A: 「If there is a route that sends all internet traffic (0.0.0.0/0) to an internet gateway, the endpoint route takes precedence for traffic destined for the service ... in the current Region.」プレフィックスリストはリージョン固有なので、他リージョンのS3宛はIGWへ行く。
- ルートの優先順位: ①最長プレフィックス ②静的ルート ③プレフィックスリストルート ④伝播ルート。ただし「more specific routes always take priority irrespective of whether they are propagated routes, static routes, or routes that reference prefix lists.」——具体性が最優先。
- 静的ルートを使う対象(伝播ルートに勝つ側): internet gateway / NAT gateway / Network interface / Gateway VPC endpoint / VPC peering など。「the static route takes priority.」
- local ルートはVPC内通信のための既定ルート(「A default route for communication within the VPC」)で、VPC CIDR宛はVPC内で処理される。
ルートテーブルは「宛先IPで一番具体的な行を引く検索テーブル」。DynamoDB編でパーティションキーからハッシュで置き場所を引いたのと同じく、ここでもキー(宛先IP)から行き先(ターゲット)を一意に引く。0.0.0.0/0は「他のどの行にも負けた時だけ選ばれる、最も一般的な受け皿」。
③ 三経路の目的地までの道のり — 出ない道、AWS網内の道、2段変換の道
経路A: S3宛pl-xxxx → ゲートウェイEP
経路B: 外部API宛0.0.0.0/0 → NATゲートウェイ
経路C: RDS宛local → VPC内
それぞれの目的地へ
ゲートウェイEPS3/DynamoDB専用
IGWもNATも通らないNATゲートウェイ送信元をNATのプライベートIPへ変換
変換表に往路を記録直接ENIへ届く変換なし
S3に到達AWSネットワーク内で完結
IGWElastic IPへさらに変換
インターネットの向こうへRDSのENIVPCから出ない
- 経路A: 「Gateway VPC endpoints provide reliable connectivity to Amazon S3 and DynamoDB without requiring an internet gateway or a NAT device」。ゲートウェイエンドポイントはPrivateLinkを使わない別種。
- 経路B: プライベートサブネットは定義上IGWへのルートを持たない。「To enable instances in the private subnet to send traffic ... you would add a NAT device ... and route traffic in the private subnet to the NAT device.」NATは送信元アドレスを付け替える「変換表」。
- 経路Bの2段変換は公式の記述通り: 「Both private and public NAT gateways map the source private IPv4 address of the instances to the private IPv4 address of the NAT gateway, but in the case of a public NAT gateway, the internet gateway then maps the private IPv4 address of the public NAT gateway to the Elastic IP address associated with the NAT gateway.」——NATゲートウェイが自分のプライベートIPへ、その先のIGWがElastic IPへ変換する。
- 補足: 「While traffic to Amazon S3 or DynamoDB traverses the internet gateway, it does not leave the AWS network.」——ゲートウェイエンドポイントを使わずIGW経由にした場合でも、S3宛はAWS網の外に出ない。
- 経路C: local ルートにより、同一VPC内はプライベートIPで直接通信できる。
同じ「1つのアプリ」から出ても、行き先で通る部品数がまるで違う。S3宛は最短(AWS網内で完結)、外部API宛は最長(NAT→IGWと2段の変換を越える)、RDS宛はそもそもVPCから出ない。NATは、API Gateway編・S3編で見た「入口で名前や住所を付け替えるプロキシ」と同じ発想の「出口の変換表」。
④ どの経路にも共通の二重検問 — サブネット境界のNACLとENI手前のSG
往路のパケットアプリ → 外
通過 → ENIの手前で
NACLステートレス = 往路と復路を別々に審査
番号の若い順に評価し最初の一致で確定。AllowもDenyも書ける。例) 100: Allow 443/tcp out通過
SGステートフル = 往路を通せば復路は記憶で自動許可
全ルールを評価してから判断。Allowのみ。例) Outbound: 443/tcp to pl-xxxx目的地へ経路A / B / C それぞれの行き先
- Rule type: SG=「Allow rules only」/ NACL=「Allow and deny rules」
- Rule evaluation: SG=「Evaluates all rules before deciding whether to allow traffic」/ NACL=「Evaluates rules in ascending order until a match for the traffic is found」
- Return traffic: SG=「Automatically allowed (stateful)」/ NACL=「Must be explicitly allowed (stateless)」
- Level: SG=Instance level(ENI単位)/ NACL=Subnet level(サブネット単位)
- 経路AでSGはプレフィックスリストIDを宛先に指定できる(pl-xxxx TCP 443)。NACLはプレフィックスリストを参照できず(「You can't reference prefix lists in network ACL rules」)、サービスのCIDRを直に書く必要がある。
- 前述の通り、Amazon DNS server宛のトラフィックはNACL/SGでフィルタできない(①の名前引きはこの二重検問の対象外)。
ルートテーブルが「どこへ送るか(到達)」を決めた後、NACLとSGが「送っていいか(許可)」を二重に審査する。メッセージング編で「配信保証はどこに状態を持つかで決まる」と見たのと同じ問いがここにも現れる——NACLは状態を持たない(だから往復を別々に書く)、SGは状態を持つ(だから往路の記憶で復路を通す)。
⑤ 4つの「競合解決の規則」が1つの旅の中で全部使われる
ルートテーブル最長一致 — 具体が一般に勝つ
例: pl-xxxx(S3帯)が 0.0.0.0/0 に勝つ同宛先の2行静的ルートが伝播ルートに勝つ
ただし、より具体的な行があればそれが最優先NACL番号の若い順・最初の一致で確定
後ろの行は見ないSG全ルールを評価・許可があれば通す
順序は関係ない・Denyは存在しない- ①「the most specific route that matches ... longest prefix match」
- ②「If the destination of a propagated route is identical to the destination of a static route, the static route takes priority.」かつ「more specific routes always take priority irrespective of ... propagated routes, static routes, or routes that reference prefix lists.」
- ③「Evaluates rules in ascending order until a match for the traffic is found」
- ④「Evaluates all rules before deciding whether to allow traffic」+「Allow rules only」
4つの規則は一見バラバラだが、「複数の候補から1つの結論をどう選ぶか」という同じ問いへの4通りの答え。①②は「1つだけ選ぶ(検索)」、③は「最初に見つけたら止める(順序依存)」、④は「全部見てOKが1つでもあれば通す(順序非依存)」——CIDRが2進数の区画割りだからこそ「具体的=プレフィックスが長い」という比較が成り立ち、①の最長一致が意味を持つ。
⑥ 復路は「状態」に支えられて初めて帰ってくる — ステートレスとステートフルの役割分担
外部APIの応答復路。宛先 = NATゲートウェイのIP
サブネット境界へ
NATの変換表「このセッションの戻りは 10.0.1.37 宛だ」と復元
宛先をプライベートIPへ書き戻す往路で刻まれた状態その2
NACLステートレス — 状態を持たない
復路の許可を明示的に書いていないと落ちる。例) inbound 1024-65535/tcp Allow が別途必要通過
SGの追跡コネクション追跡「この往路は自分が通した」と記憶
復路インバウンドを自動で許可アプリに届く応答が帰ってきた
- SG:「Return traffic ── Automatically allowed (stateful)」——往路を通した接続の戻りは自動で許可。
- NACL:「Return traffic ── Must be explicitly allowed (stateless)」——戻りポート(エフェメラルポート)のインバウンド許可を別途書く必要がある。
- NATは送信元付け替えの変換表を持つゆえに、応答をどのプライベートIPへ戻すか復元できる。「When sending response traffic to the instances ... the NAT gateway translates the address back to the original source IP address.」
- 経路A(S3)・経路C(RDS)も、SGのステートフル性により応答の戻りは自動で通る。
- コースの軸で回収: CIDR=2進数の区画割り(だから「具体的」を長さで測れる)/ ルートテーブル=最長一致検索 / SG・NACL=ステートフル・ステートレスのパケットフィルタリング / NAT=送信元・宛先を書き換える変換表 / Resolver=分散データベースDNSのリゾルバ。マネージドVPCの中身も、IPアドレッシング・ルーティング・パケットフィルタリング・NAT・DNSという教科書のネットワーク基礎でできていた。
- キャッシュ編の総括が「速さの層」をブラウザからDB前段まで地図にしたのに対し、この回は同じ1リクエストを「到達と許可の層」で地図にした——可観測性編の相関IDでリクエストを追ったのと同じ視点を、今度はインフラの側から実践したことになる。
往路と復路は非対称。復路がちゃんと帰ってこられるのは、NATの変換表とSGのコネクション追跡という2つの「状態」が往路で刻まれたおかげ。状態を持たない部品(ルートテーブル・NACL)と状態を持つ部品(NAT・SG)の役割分担こそVPCの設計であり、DynamoDB編以来くり返してきた「状態を持つ場所を設計する」という問いの、ネットワーク版の答え。