VPCエンドポイント(ゲートウェイ/インターフェース)の選び方

はじめに

こんにちは、山本です。
最近、業務でVPC詳細設計を行う機会がありました。その中でVPCエンドポイントの種類について悩み、色んなことを調査＆教えていただいたので記事でも取り上げようと思います。

VPCエンドポイントは「クラウド上の通信をインターネットに晒さずに完結させる」という役割を持っていることは色んな場面で学習する機会がありましたが、ゲートウェイ型/インターフェース型のエンドポイントの違いは何なのか、また要件に対してどちらを選ぶべきなのかを考えたことがあまりなく、今回の実案件の詳細設計を通してようやく理解が深まりました。

資格勉強のみだとそこまで考える機会は私にはなかったので、同じように資格対策をする中でエンドポイントの概念に悩まれてる方の手助けになれれば幸いです。

それぞれのエンドポイントの説明と相違点

ゲートウェイ型

ゲートウェイ型エンドポイントは最初に出現したVPCエンドポイントで、VPCのルートテーブルに宛先の経路を追加して通信を行う方式です。

ゲートウェイ型エンドポイントには以下の特徴があります。

NATやInternet Gatewayが不要(インターネットを介さない)
エンドポイント自体は料金が無料
透過的に公開DNS名でアクセス可能（s3..amazonaws.com など）
セキュリティはエンドポイントポリシーとバケット/テーブルのリソースポリシーで制限可能。

インターフェース型

インターフェース型エンドポイントは、サブネットに対してENI(Elastic Network Interface)がエンドポイント用に生成され、プライベートIPを用いて通信を行う方式です。

インターフェース型エンドポイントには以下の特徴があります。

多くのAWSサービスに対応している
Private DNSを有効化すると、公開ホスト名がVPC内からはプライベートIPに解決される
サブネットごとにエンドポイントENIが作成されるので、SG(SecurityGroup)でアクセス制御が可能

２つのエンドポイントの相違点

エンドポイントの相違点について、以下の表にまとめます。

観点	ゲートウェイ型	インターフェース型
対象	Amazon S3/DynamoDBのみ	多数のAWSサービス
経路	ルートテーブルへの登録	サブネットにENI作成
DNS	公開名のまま裏で迂回	Private DNSで解決
制御	エンドポイント/リソースポリシーが中心	SGで絞り込み + ポリシー
料金	エンドポイント自体が無料	時間＋データ処理課金
到達範囲	VPC内（オンプレ/Transit Gateway等は不可）	VPC/オンプレミス/クロスVPC

ゲートウェイ型エンドポイントが無料でインターフェース型エンドポイントが有料である原因は、ENIを使用するか否かという点にあります。
インターフェース型エンドポイントではENIをAZ毎に設置するので、管理インフラとしての料金と通過トラフィックに対しての料金が発生するという構図になっています。

しかし、インターフェース型はオンプレミス↔︎VPC間でも通信可能であることはかなり大きな強みなのではないかと個人的には感じました。

各エンドポイントのユースケース

ここでは、簡易的な例ではありますが各VPCエンドポイントのユースケースを紹介します。
より詳細にイメージするための手立てとして、ユースケースを意識することは重要だと思いますので、ぜひ参考にしてみてください。

サービス	利用シナリオ	最適なエンドポイント	ポイント
Amazon S3	大量・汎用アクセス	ゲートウェイ型	広範囲なワークロードを低コストで実現可能
DynamoDB	大量・汎用アクセス	ゲートウェイ型	広範囲なワークロードを低コストで実現可能
Amazon CloudWatch	厳密な制御が必要	インターフェース型	SGを適切に制御することで安全性を担保可能
AWS Bedrock	厳密な制御が必要	インターフェース型	SGを適切に制御することで安全性を担保可能
Amazon S3	オンプレミス・外部VPCから非インターネット転送	インターフェース型	Direct ConnectやVPCピアリング経由ではゲートウェイ型は非対応

ユースケースから読み取れる通り、エンドポイントを選定するときにはそもそもエンドポイントに対してAWSサービスが対応しているか否かはもちろんのこと、求められるセキュリティレベルや通信元の要件(オンプレミスかどうか等)についても選定する際のポイントになります。
また、インターフェースエンドポイントへの対応・非対応については公式ドキュメントより閲覧可能です。