Dev Study
AWSサービスの内部原理 コース

38. リクエストはどこに届くのか — エッジ最適化・リージョナル・プライベート

API Gatewayの3つのエンドポイントタイプは機能の違いではなく「DNSがどこを指すか」の違い — リクエストが最初に届く場所を図で追っていきます。

① エンドポイントタイプ=「DNSの指し先」の設計

クライアントAPIを呼ぶ
エンドポイントタイプで指し先が分岐
DNSこの名前はどこを指す?
CDNのエッジエッジ最適化
リージョンの正面リージョナル
VPC内プライベートIPプライベート
  • 土台は既習の3つ: DNS(名前解決とCNAME)/CDN(エッジPOPとオリジン)/ネットワーク(プライベートIPとENI)

APIを作ると {api-id}.execute-api.{リージョン}.amazonaws.com という正面玄関のホスト名が1本払い出される。エンドポイントタイプ3種の違いは機能ではなく、この名前がDNSで最終的にどこを指すか(リクエストが物理的にどこへ最初に届くか)の違い。

② エッジ最適化 — AWS管理のCloudFrontが前段に挟まる(REST APIの既定)

世界中のクライアント地理的にバラけた利用者
AWSの内部網に乗せて運ぶ
CloudFront エッジPOPAWSが管理・自動で前段に
ここで一枚レイヤーが挟まる
リージョンのAPI Gatewayオリジン(APIの実体がある場所)
  • 前段の「動かぬ証拠」: HTTPヘッダ名が正規化され Cookie のように先頭が大文字になる
  • 同じく証拠: CloudFrontがCookieをクッキー名の自然順にソートしてからオリジンへ転送する
  • カスタムドメインは全リージョン共通(グローバル)に効く

DNSをたどると名前はCloudFrontのエッジロケーション群を指す。クライアントは最寄りPOPまでの短い区間でTCP/TLSを確立できるため、地理的にバラけた利用者ほど接続確立が速い — CDNの発想そのもの。

③ リージョナル — 前段を外した「素の」リージョンエンドポイント

近くのクライアント同一リージョンのEC2など
CloudFront前段経由しない(外れている)
リージョンのAPI Gateway素のリージョンエンドポイント
  • 前段を手放すかわりに自分で組める: 自前CloudFrontを載せてキャッシュやWAFを自分の設計で配置
  • 複数リージョンに同じカスタムドメインでAPIを立て、Route 53のレイテンシールーティングで「今いちばん速いリージョン」へDNSレベルで振り分け
  • カスタムドメインはリージョン固有(全リージョン共通のエッジ最適化との対比)

DNSはCloudFrontを経由せず、そのリージョンのAPI Gatewayを直接指す。同一リージョンの近いクライアントならCloudFrontまでの往復という無駄が消え、ヘッダも整形されず送ったとおり素通し(as-is)。

④ プライベート — インターネットからは解決も到達もできない

VPC内のクライアント唯一の入口を持つ
インターネットのクライアント解決・到達とも不可
PrivateLink(AWS網の内側だけを通る)
インターフェイスVPCエンドポイント実体はサブネット内のENI+プライベートIP
API GatewayプライベートAPI
  • カスタムドメインを使う場合も、最終的にこのVPCエンドポイント経由の経路に解決される必要がある

唯一の経路は自分のVPC内に作るインターフェイスVPCエンドポイント。execute-api のDNS名がVPC内のENIのプライベートIPへ解決されるようになり、トラフィックはインターネットに一歩も出ない。

⑤ まとめ — 同じ1本のAPIでもDNSの指し先で世界が変わる

エッジ最適化DNS→グローバルなCDNのエッジ
リージョナルDNS→リージョンの正面
プライベートDNS→VPC内のプライベートIP
  • ヘッダ: エッジ最適化=正規化(Cookie大文字化・Cookieソート)/リージョナル=as-isで素通し
  • カスタムドメイン: エッジ最適化=全リージョン共通/リージョナル=リージョン固有/プライベート=VPCエンドポイント経由の解決が必須
  • 経路: エッジ最適化=最寄りPOP→AWS内部網/リージョナル=リージョン直行/プライベート=PrivateLinkでAWS網の内側のみ

エンドポイントタイプとは、突き詰めればDNSの指し先の設計。指し先の選択ひとつで、公開範囲もネットワーク経路も丸ごと変わる。

公式ドキュメントで詳しく ↗