はじめに

どうも shihopower です!

今日はインターフェース VPC エンドポイントを使った通信の仕組みについてお話しします。

SAP の対策をしていると、「AWS サービスへの通信をインターネット上に公開したくない」という要件に対する正解として、インターフェース VPC エンドポイントが出てきます。「はいはい、PrivateLink ね」で済ませることもできるのですが、いつも言っている通り、丸暗記した知識はどうせすぐ忘れます。

そこで今回は、「なぜインターフェース VPC エンドポイントを使うとインターネットを通らずに AWS サービスへアクセスできるのか」を、DNS の挙動とルーティングの観点から腹落ちするレベルまで掘り下げてみました。

同じく SAP・SAA を学習中の方や、PrivateLink の仕組みをふんわりとしか理解できていない方の参考になれば嬉しいです。

1. 前提整理:そもそも AWS サービスはどこにあるのか

最初に押さえておきたい大事な前提があります。

SQS、KMS、SNS、Secrets Manager といった AWS のマネージドサービスは、ユーザーの VPC の中には存在しません。これらは AWS が自分たちのネットワーク上で運用している共有サービスで、ユーザーからは sqs.ap-northeast-1.amazonaws.com のようなパブリックエンドポイント経由でアクセスする「外部サービス」という位置づけです。

EC2 や RDS のように「自分の VPC の中に建てるリソース」とは性質が違うので、ここを混同すると後の話が分かりにくくなります。

つまり何もしなければ、EC2 から SQS への通信は VPC の外側にあるパブリックなエンドポイントに向かう ことになります。これが「インターネットを通る」と言われる所以です。

2. インターフェース VPC エンドポイントとは

AWS の公式ドキュメントを引用すると、インターフェース VPC エンドポイントは次のように説明されています。

インターフェイスエンドポイントは、インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続なしで API にプライベートにアクセスできるテクノロジーである AWS PrivateLink を利用しています。VPC のインスタンスはパブリック IP アドレスがなくても API と通信できます。

ポイントは 2 つです。

AWS PrivateLink という技術が裏で動いている
インターネットゲートウェイも NAT も使わずに AWS サービスにアクセスできる

ではどうやってそれを実現しているのか、というのが次章のテーマです。

3. 仕組みの中核:ENI とプライベート IP、そして DNS

インターフェース VPC エンドポイントの仕組みは、ENI と DNS という 2 つの要素で成り立っています。

その前に、全体像をイメージで掴んでおきましょう。

3-0. 比喩で掴む全体像

インターフェース VPC エンドポイントを作っても、SQS 本体が VPC の中にコピーされたり移動してきたりするわけではありません。SQS は依然として AWS 側のネットワークで動いています。

イメージとしては、本社が遠くにある会社に対して、自分のオフィスビルの中に「その会社専用の受付窓口」を設置してもらう ようなものです。

窓口自体は自分のビルの中 にあるので、外に出ずに窓口まで行ける(= VPC 内のプライベート IP で完結する)
でも窓口の向こうには 専用の直通回線 があって、それを通じて本社とやり取りされる(= PrivateLink のバックボーンで SQS まで届く)

「窓口は手元に、本体は遠くに」というのが、インターフェース VPC エンドポイントの本質的なイメージです。

これを技術的に支えているのが、次に説明する ENI と DNS の 2 つです。

3-1. ENI(エンドポイント用のネットワークインターフェイス)

エンドポイントを作成すると、指定したサブネットの中に 専用の ENI が作られ、そのサブネットのアドレス範囲から プライベート IP アドレス が割り当てられます。

この ENI は AWS の公式ドキュメントでは「リクエスタマネージドネットワークインターフェイス」と呼ばれており、ユーザーのアカウントから見ることはできますが、自分で管理することはできない特殊な ENI です。

先ほどの比喩で言えば、この ENI が 「VPC 内に置かれた受付窓口」 そのものに当たります。

3-2. プライベート DNS

エンドポイント作成時に「プライベート DNS 名」を有効にすると、AWS サービスのパブリックなホスト名(例: sqs.ap-northeast-1.amazonaws.com)に対する DNS 解決の答えが、VPC 内の ENI のプライベート IP に書き換わります。

公式ドキュメントの表現を借りると:

コンシューマーがサービスのパブリック DNS 名にリクエストを送信すると、プライベート DNS サーバーがそのリクエストをエンドポイントネットワークインターフェイスの IP アドレスに解決します。

つまりアプリ側のコードは一切変えずに、名前解決の結果だけが差し替わるという仕組みです。

比喩で言えば、「本社の住所を尋ねたら、自動的にビル内の窓口の場所を案内してくれる」 ようなイメージですね。アプリは何も知らずに、いつも通り「本社まで行きたい」と言うだけで、勝手に近くの窓口に案内されるわけです。

4. なぜインターネットを通らないのか

ここまでの話を踏まえると、「インターネットを通らない」理由が論理的に説明できます。

EC2 から SQS にアクセスする際の流れを追ってみましょう。

EC2 のアプリが sqs.ap-northeast-1.amazonaws.com を DNS で解決する
プライベート DNS により、答えは VPC 内の ENI のプライベート IP(例: 10.0.1.45)になる
アプリはそのプライベート IP に対して HTTPS リクエストを送る
ルートテーブルを見ると、宛先 10.0.1.45 は VPC 内なので local ルート にマッチする
パケットは ENI に到達する
ENI の先は AWS PrivateLink のバックボーンに繋がっており、そこを通って SQS まで届く

ここで重要なのは 4 番目 です。パケットの宛先がそもそも VPC 内のプライベート IP なので、0.0.0.0/0 のデフォルトルートにはマッチせず、Internet Gateway も NAT Gateway も使われません。

ルーティング的に「外」に出る必要がないので、物理的にインターネットを経由しない、というのが答えになります。

5. 図解で比較:エンドポイントあり vs なし

文章だけだと分かりにくいので、エンドポイントあり/なしの両方を図で比較してみます。

5-1. インターフェース VPC エンドポイントを使わない場合

[EC2: 10.0.1.10]
      │
      │ ① DNS クエリ: 「sqs.ap-northeast-1.amazonaws.com は?」
      │ ← 答え: 52.119.x.x (パブリック IP)
      │
      │ ② パケット送信(宛先: 52.119.x.x ← グローバル IP)
      ▼
┌──────────── VPC (10.0.0.0/16) ────────────────┐
│                                                │
│  ルートテーブルを確認:                          │
│    10.0.0.0/16 → local                         │
│    0.0.0.0/0   → NAT Gateway(または IGW)    │
│                                                │
│  宛先 52.119.x.x は VPC 内に該当なし           │
│   → デフォルトルートにマッチ                   │
│                                                │
│  [プライベートサブネット]                      │
│    └─ [NAT Gateway]                            │
│            │                                   │
│  [パブリックサブネット]                        │
│    └─ [Internet Gateway] ←──────┐             │
└──────────────────────────────────┼─────────────┘
                                   │
                                   ▼
                           🌐 インターネット
                                   │
                                   ▼
                  [AWS の SQS パブリックエンドポイント]

5-2. インターフェース VPC エンドポイントを使う場合

[EC2: 10.0.1.10]
      │
      │ ① DNS クエリ: 「sqs.ap-northeast-1.amazonaws.com は?」
      │ ← 答え: 10.0.1.45 (VPC 内のプライベート IP!)
      │   ※プライベート DNS が有効な場合
      │
      │ ② パケット送信(宛先: 10.0.1.45)
      ▼
┌──────────── VPC (10.0.0.0/16) ────────────────┐
│                                                │
│  ルートテーブルを確認:                          │
│    10.0.0.0/16 → local  ← こっちにマッチ!    │
│    0.0.0.0/0   → NAT Gateway(使われない)    │
│                                                │
│  [ENI: 10.0.1.45]                              │
│   (インターフェース VPC エンドポイント)       │
│        │                                       │
└────────┼───────────────────────────────────────┘
         │
         │ AWS PrivateLink バックボーン
         │ (インターネットを経由しない AWS 内部網)
         ▼
   [AWS の SQS サービス]

  ❌ IGW 不要
  ❌ NAT Gateway 不要
  ❌ インターネットを通らない

5-3. 違いを表で整理

項目	使わない場合	使う場合
DNS の答え	パブリック IP(例: 52.119.x.x)	VPC 内プライベート IP(例: 10.0.1.45)
パケットの宛先	VPC の外	VPC の中
マッチするルート	`0.0.0.0/0` → IGW/NAT	`10.0.0.0/16` → local
通過する出口	IGW、NAT Gateway	なし(VPC 内で完結)
インターネット経由	する	しない
必要なリソース	IGW または NAT Gateway	インターフェース VPC エンドポイント

違いの根っこは 「DNS の答えが何か」 に集約されます。アプリ側のホスト名指定は両ケースで全く同じです。AWS は DNS 解決の結果だけを差し替えることで経路を変えている のがエレガントなところで、これが「アプリ無修正でプライベート経路に切り替えられる」理由でもあります。

6. 補足:ゲートウェイ型 VPC エンドポイントとの違い

ここまで読むと「VPC エンドポイント = ENI でプライベート IP を持つもの」というイメージになりますが、実は VPC エンドポイントには もう一種類 あります。それがゲートウェイ型 VPC エンドポイントです。

6-1. ゲートウェイ型の特徴

ゲートウェイ型は S3 と DynamoDB の 2 つだけ が対応している特殊なエンドポイントです。インターフェース型とは全く違う仕組みで動いています。

観点	インターフェース型	ゲートウェイ型
対応サービス	多数(SQS、KMS、SNS、Secrets Manager など)	S3 と DynamoDB のみ
内部技術	AWS PrivateLink	ルートテーブルへのルート追加(プレフィックスリスト)
VPC 内の実体	ENI(プライベート IP を持つ)	なし(ENI は作られない)
アクセス制御	セキュリティグループ + エンドポイントポリシー	エンドポイントポリシーのみ
料金	時間課金 + データ処理料金	無料
オンプレからの利用	可能(Direct Connect/VPN 経由でも使える)	不可(同じ VPC 内からのみ)

6-2. ゲートウェイ型はどう動くのか

ゲートウェイ型を作成すると、関連付けたルートテーブルに S3 や DynamoDB のプレフィックスリスト宛のルート が自動的に追加されます。EC2 から S3 への通信は、このルートに従って ENI を介さず直接 AWS の内部網へ流れる、という仕組みです。

ENI を使わないので、プライベート IP も割り当てられませんし、セキュリティグループでの制御もできません。代わりに料金が無料というメリットがあります。

6-3. どちらを使うべきか

S3 についてはインターフェース型とゲートウェイ型の両方が選べますが、基本は ゲートウェイ型が安くて十分 です。ただし「オンプレからプライベートに S3 にアクセスしたい」といった要件がある場合はインターフェース型を選ぶ、というのが定石です。

「同じ名前でも別物」という認識を持っておくと、SAP の試験問題でも惑わされずに済みます。

7. まとめ

インターフェース VPC エンドポイントの仕組みを一言で表すと、「窓口は VPC 内、本体は AWS 内部網の奥」 というイメージになります。

本社(SQS や KMS などの AWS サービス本体)は遠くにありますが、自分のオフィスビル(VPC)の中にその会社専用の受付窓口(ENI)を置いてもらうことで、外に出ずに用事を済ませられる。窓口の向こうには専用の直通回線(PrivateLink のバックボーン)が引かれていて、そこを通じて本社とやり取りされる。これがインターフェース VPC エンドポイントの本質です。

押さえるべきポイントを整理すると:

SQS や KMS などの AWS サービスは VPC の外にある(これが大前提)
インターフェース VPC エンドポイントを作ると、VPC 内に ENI(専用の窓口) が置かれる
プライベート DNS により、AWS サービスのホスト名が ENI のプライベート IP に解決 される
パケットの宛先が VPC 内 IP になるので、ルートテーブルが local ルートにマッチして IGW/NAT を通らない
結果として、トラフィックは AWS PrivateLink のバックボーン経由で SQS まで届き、インターネットを一切通らない

そして注意点として、S3 と DynamoDB だけはゲートウェイ型という別の仕組みもある ことを覚えておくと、試験でも実務でも迷いません。

「PrivateLink で繋がっています」とサラッと暗記するより、「VPC 内の窓口にアクセスしているだけだから、外に出る必要がない」 と理解しておく方が遥かに忘れにくいです。SAP 受験者の皆さん、一緒に頑張りましょう!

参考リンク