VPCエンドポイントと AWS PrivateLink
Gateway型とInterface型のVPCエンドポイント、AWS PrivateLink、ハイブリッド接続、エンドポイントポリシーを整理します。
VPCエンドポイントと AWS PrivateLink
VPC内のアプリケーションがAWSサービスを呼び出すとき、通常のインターネット経路を使わずにAWSネットワーク内で接続したいことがあります。VPCエンドポイントは、VPCと対応するサービスの間にプライベートな接続経路を作る機能です。アプリケーションから見た接続先や認証方法を保ちながら、インターネットゲートウェイやNATゲートウェイを通らない構成にできます。
AWSには用途別に複数のVPCエンドポイント機能があります。このページでは、AWSサービスへの接続でよく比較される Gateway型 と Interface型 を中心に扱います。両者ともパブリックインターネットを通らない接続を作れますが、VPC内での経路の作り方、接続できるサービス、ハイブリッド環境からの使い方、料金が異なります。
Gateway型：ルートテーブルでサービスへの経路を作る
Gateway型エンドポイントは、Amazon S3 と Amazon DynamoDB 向けに提供されます。VPC内にネットワークインターフェイスを作らず、指定したルートテーブルにサービス宛ての経路を追加します。AWSが管理するプレフィックスリストが宛先となり、そのサービスへの通信がエンドポイントを経由してAWSネットワーク内を進みます。サービスのIPアドレスを固定値としてルートに書く必要はありません。Gateway型はAWS PrivateLinkを使いません。
Gateway型は、対象のルートテーブルを使うVPC内のリソースがサービスへ接続するためのものです。エンドポイント自体は外部ネットワークに公開されず、オンプレミスからDirect ConnectやSite-to-Site VPNを通じてGateway型へ直接接続する構成には使えません。VPC内にプロキシを置き、オンプレミスのクライアントがそのプロキシに接続して、プロキシからGateway型経由でサービスへアクセスする方法はあります。
Gateway型エンドポイント自体に時間料金やデータ処理料金はありません。ただし、サービス側の利用料金や、別途発生するデータ転送料金まで無料になるわけではありません。利用するルートテーブルとサービスのリージョンが合っているか、実際の経路を確認してください。
Interface型：サブネットのENIをPrivateLinkにつなぐ
Interface型エンドポイントは、選択した各サブネットに Elastic Network Interface（ENI） を作成し、そのプライベートIPアドレスを接続点にします。ENIとAWSサービスまたはVPCエンドポイントサービスの間は AWS PrivateLink によって接続されます。利用者のVPC内には接続用のENIが作成されますが、接続先のサービス提供者側のVPCに、利用者が管理するエンドポイントを作るわけではありません。PrivateLinkを利用するサービス提供者は、提供者側でエンドポイントサービスを公開します。
Interface型は、多数のAWSサービスとPrivateLink対応サービスで利用できます。サービスの通常のDNS名をプライベートIPへ解決するプライベートDNSを有効にすると、アプリケーションの接続先を大きく変えずに通信をエンドポイントへ向けられます。名前解決設定、対象サービスの対応状況、VPC内のDNS設定を確認して構成します。
Interface型では、エンドポイントENIにセキュリティグループを関連付けられます。たとえば、承認済みのアプリケーションサブネットからのTLS通信だけを許可するなど、接続元をネットワークレベルで制限できます。選択したアベイラビリティーゾーンにENIを配置するため、利用するAZごとの配置、冗長性、サブネットのIPアドレス消費も設計に含めます。
Interface型には通常、エンドポイントENIの稼働時間と処理データ量に応じた料金がかかります。対象サービスやリージョンで料金条件が異なる場合があるため、導入時にはAWS PrivateLinkの料金表を確認します。
2種類の違いを選択に結びつける
| 比較点 | Gateway型 | Interface型 |
|---|---|---|
| 接続の仕組み | ルートテーブルにサービス宛ての経路を追加 | サブネットに作成したENIをAWS PrivateLinkへ接続 |
| サービス範囲 | Amazon S3、Amazon DynamoDB | 多数のAWSサービスとPrivateLink対応サービス |
| VPC内のネットワークインターフェイス | 作成しない | 選択したサブネットごとにENIを作成 |
| 主なネットワーク制御 | ルートテーブル、エンドポイントポリシー | ENIに関連付けるセキュリティグループ、エンドポイントポリシー |
| オンプレミスからの直接接続 | 対応しない。VPC内のプロキシを経由する構成は可能 | VPNまたはDirect ConnectでVPCへ接続し、ENIとDNSへ到達できるようにすれば利用可能 |
| エンドポイント料金 | エンドポイント料金なし | 通常、稼働時間と処理データ量に応じた料金あり |
Gateway型とInterface型のどちらを使うかは、サービスだけでは決まりません。VPC内のルーティングで十分ならGateway型が簡単で、エンドポイント料金もかかりません。オンプレミスからのプライベート接続、ENI単位のセキュリティグループ制御、Gateway型では提供されないサービスへの接続が必要なら、Interface型を検討します。
S3とDynamoDBでは2種類を選べる
S3とDynamoDBはGateway型だけでなく、Interface型エンドポイントにも対応しています。「S3とDynamoDBなら必ずGateway型」という理解では不十分です。
VPC内のワークロードだけが利用し、ルートテーブルで経路を管理するなら、追加のエンドポイント料金がないGateway型が有力です。一方、オンプレミスの利用者がVPNやDirect Connect経由で同じサービスへ直接プライベート接続する場合、Gateway型ではなくInterface型を使えます。S3またはDynamoDBへのVPC内通信にGateway型を使いつつ、オンプレミス向けにInterface型も用意する設計も可能です。DNSの向き先やルーティングを明確に分け、意図した経路を通ることを確認します。
PrivateLinkを用いるサービス連携では、別リージョンからの接続も検討対象になります。たとえばS3のInterface型エンドポイントは、VPNまたはDirect Connectでつないだオンプレミスのほか、VPC PeeringやTransit Gatewayで接続した別リージョンのVPCから利用できます。ただし、リージョン間接続の可否はサービスと接続方法の組み合わせに依存します。クロスリージョン接続を前提にする場合は、接続元・接続先の両方で対象サービスの対応状況を確認してください。
エンドポイントポリシーは経路を通じたアクセスを絞る
エンドポイントポリシーは、特定のVPCエンドポイントを通過するリクエストのうち、どのプリンシパルがどの操作をどのリソースに対して行えるかを制限するポリシーです。IAMポリシーと同じくJSON形式で記述します。多くのエンドポイントでは、明示的なポリシーを付けない場合、エンドポイント経由でのアクセスを広く許可する設定が初期状態です。エンドポイントポリシーを使って、許可する主体、操作、リソースを狭められます。
たとえば、プライベートサブネットのビルド用EC2が、S3の成果物バケットへビルド結果を保存するケースを考えます。アクセス許可は次の複数の層で確認します。
- EC2のIAMロールが対象バケットへの
s3:PutObjectを許可する。アプリケーションはロールの一時認証情報を使う。 - S3 Gateway型エンドポイントポリシーが、指定したロールによる対象バケットへの
s3:PutObjectを許可する。 - S3バケットポリシーが設定されている場合は、その許可・拒否や条件が要求を妨げないことを確認する。クロスアカウントアクセスではバケットポリシーによる許可も必要になる。経路を固定する要件があれば、
aws:SourceVpce条件を使って指定したエンドポイント経由の要求を許可し、別経路からの要求を制限する。
これらはそれぞれ異なる責任を持ちます。IAMロールはその認証主体がAWS APIで実行できる操作を定めます。エンドポイントポリシーはそのエンドポイントを通してよい操作を絞る追加条件です。バケットポリシーはS3リソース側の許可や経路条件を定めます。同一アカウントでは、アイデンティティベースの許可だけでアクセスできる場合もあります。クロスアカウントでは、要求元側の許可に加えて、バケットポリシーなどリソース側からの許可も必要です。いずれの場合も、適用される明示的な Deny があれば Allow があっても拒否されます。エンドポイントポリシーを追加しても、IAMポリシーや必要なバケットポリシーの確認を省略できません。
aws:SourceVpce をバケットポリシーで必須にすると、別のVPCエンドポイントやコンソールなど、指定した経路を通らないアクセスが拒否されることがあります。経路を固定する目的と、運用・管理に使うアクセス経路の両方を確認してから条件を設定します。
Gateway型とInterface型の設計上の背景
Gateway型はVPC内のネットワークインターフェイスを増やさず、ルートテーブルを使ってAWSネットワーク内のサービスへ転送します。S3やDynamoDBのように広く利用されるサービスでは、大量のVPC内トラフィックをシンプルな経路で処理でき、ENI用のプライベートIPアドレスを消費せず、エンドポイント料金も発生しないことが利点です。
このアーキテクチャ上の違いから、Gateway型は特定のサービスに向けた効率的な経路、Interface型はENIとPrivateLinkを使った幅広いサービスへの接続として整理できます。Gateway型がこの2サービスに限られる歴史的な理由を、単一の公式説明として断定することはできません。試験では、理由を推測するより「Gateway型はS3とDynamoDB」「Interface型はPrivateLinkによる広いサービス対応」「S3とDynamoDBは両方を選択可能」という現在の仕様を押さえることが重要です。
学習時の整理
- VPC内のS3またはDynamoDB通信をインターネット経由にせず、追加のエンドポイント料金を避けたい場合は、Gateway型を候補にする。
- VPNまたはDirect Connectで接続したオンプレミスから、対応するAWSサービスへ直接プライベート接続したい場合は、Interface型を候補にする。
- サービス側がPrivateLinkに対応し、エンドポイントENIに対するセキュリティグループ制御が必要なら、Interface型を検討する。
- S3/DynamoDBが両方式に対応する場合でも、トラフィックの送信元、名前解決、ルートテーブル、費用を合わせて方式を決める。
- 通信経路と認可は別に確認する。プライベート経路を使うこと自体はAPI操作の許可を与えない。
参考リンク
重要ポイント
- ▸VPCエンドポイントを使うと、VPCから対応するAWSサービスへインターネットを経由せずに接続できる
- ▸Gateway型はS3とDynamoDB向けで、ルートテーブルに経路を追加する。Interface型はサブネット内のENIを使い、AWS PrivateLinkで接続する
- ▸S3とDynamoDBはGateway型とInterface型の両方を選べる。オンプレミスからの直接利用やセキュリティグループ適用ではInterface型が候補になる
- ▸エンドポイントポリシーはエンドポイント経由で可能な操作を絞る追加の制御であり、IAMポリシーやリソースポリシーの代わりにはならない
- ▸Gateway型はエンドポイント料金がかからず、Interface型は時間単位とデータ処理量に応じた料金が発生する
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
VPC とネットワーク に関連するトピックを続けて確認できます。