1. 背景
VPCエンドポイントを紹介する記事で「インターフェース型エンドポイント (AWS PrivateLink)」のような表現や、「PrivateLinkとは、AWSへのAPIアクセスをインターネットを経由せずに行えるインターフェースタイプのVPCエンドポイントです。インターフェースタイプはPrivateLinkと呼ばれています」といった説明をよく目にしたことがあるのではないでしょうか。
このような説明により、PrivateLinkがインターフェースVPCエンドポイントと同義だと誤解してしまう方が多いのではないかと懸念されます。
本記事では、AWS VPCエンドポイントの種類、その使い分け、そしてVPCエンドポイントとPrivateLinkの関係について整理します。
AWS VPCエンドポイントには以下の3種類があります。
- ゲートウェイエンドポイント（Gateway Endpoint）
- インターフェースエンドポイント（Interface Endpoint）
- Gateway Load Balancer エンドポイント（GWLB Endpoint）
Gateway Load Balancer エンドポイントは、VPC内のトラフィックを Gateway Load Balancerにルーティングするためのエンドポイントです。これにより、セキュリティアプライアンスやその他のネットワークサービスを、スケーラブルかつ高可用性の方法で展開することが可能になります。
つまり、Gateway Load Balancer エンドポイントはGateway Load Balancerを利用するという前提の話で、他の2つのエンドポイントとは全く異なる性質を持っているため、詳細は別の記事で説明します。
PrivateLinkとVPCピアリングの使い分けは以下の記事をご参考ください。
2. ゲートウェイ型エンドポイント
2.1 ゲートウェイ型エンドポイントの仕組み
概要：
- ゲートウェイ型エンドポイントを使用すると、VPC内のリソース(プライベートサブネット内でプライベートIPアドレスを持っているリソース)はパブリックインターネットを経由せずに直接
S3やDynamoDBにアクセスできます。 - S3やDynamoDBへのトラフィックをAWSの内部ネットワークを通じて直接ルーティングするため、
NAT GatewayやパブリックIPアドレスは不要です。 - トラフィックはインターネットを経由せず、AWSのネットワーク内に留まるため、プライベートIPからパブリックIPへの変換は必要ありません。
特徴：
- 対象サービス：
S3とDynamoDBのみ - エンドポイントを作成するとVPCのルートテーブルに特別なルートが自動的に追加
- インターネットゲートウェイやVPNゲートウェイと同じように、ルーティングによりその条件にあった場合、ゲートウェイを通るという形になります。ゲートウェイ型のVPCエンドポイントを設定した場合、ルーティングにも変更が加えられます。
- VPC内のリソースからのみ利用可能、VPC外からの利用は不可能(アウトバンドのみ)
- VPC外のリソースは、VPCのルートテーブルにアクセスできないため、エンドポイントを直接利用することはできません。
- 完全無料
- 歴史的経緯:
- ゲートウェイ型エンドポイントは、インターフェース型エンドポイントよりも先に導入されました。
- 当初は
S3とDynamoDBへのプライベートアクセスを提供するために設計されました。 - ゲートウェイ型はルートテーブルを使用して実装されており、DNSの成熟を待つ必要がありませんでした
- インターフェース型エンドポイントはより新しい技術でAWS PrivateLinkを使用し、柔軟性が高いですが、コストがかかります。
-
S3は2021年2月から、DynamoDBは2024年3月からインターフェース型エンドポイントも利用可能になった。
2.2 ゲートウェイ型エンドポイントを検証
全体図：
2.2.1 事前準備
-
VPC作成
-
VPC and moreを選択
- わかりやすくするために、AZを一つだけに指定し、S3 Gateway型のVPC endpointは後ほど手動で作るため、こちらで一旦OFFにする
- 生成されるリソースのリスト：
- VPC: １個
- Subnet:
- public subnet用：1個
- private subnet用：１個
- Route table:
- public subnet用：1個
- private subnet用：１個
- Internet Gateway: １個(public subnet用)
-
-
public subnetとprivate subnetそれぞれに1つのEC2インスタンス作成(新規作成する時に、同じ
key-pairを選択する必要がある) -
ローカル端末のみに秘密鍵を保持し、
SSH Agent Forwardingによるbastionサーバー経由でprivate subnetにあるEC2にアクセス。詳細なやり方は以下の記事をご参考
2.2.2 VPCエンドポイントなしの状態でS3のバケットリストを取得
- bastion server(public subnet):
Internet Gateway経由でインターネットにアクセス可能だから、pingもできるし、S3のバケット一覧取得もできる[ec2-user@ip-10-0-20-223 ~]$ ping google.co.jp PING google.co.jp (142.251.42.131) 56(84) bytes of data. 64 bytes from nrt12s45-in-f3.1e100.net (142.251.42.131): icmp_seq=1 ttl=56 time=1.25 ms 64 bytes from nrt12s45-in-f3.1e100.net (142.251.42.131): icmp_seq=2 ttl=56 time=1.28 ms 64 bytes from nrt12s45-in-f3.1e100.net (142.251.42.131): icmp_seq=3 ttl=56 time=1.32 ms ^C --- google.co.jp ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 1.248/1.281/1.319/0.029 ms [ec2-user@ip-10-0-20-223 ~]$ aws s3 ls 2024-06-24 06:53:51 databricks-workspace-stack-bucket - private subnetのEC2から：
インターネットに直接アクセスできないから、当然pingもできないし、S3のバケット一覧取得もできない[ec2-user@ip-10-0-30-163 ~]$ ping google.co.jp PING google.co.jp (142.251.222.3) 56(84) bytes of data. ^C --- google.co.jp ping statistics --- 22 packets transmitted, 0 received, 100% packet loss, time 21810ms [ec2-user@ip-10-0-30-163 ~]$ aws s3 ls
2.2.3 ゲートウェイ型エンドポイント経由でS3のバケットリストを取得
- endpoint作成
-
S3用のprivate subnetためのgateway型endpointを選択
-
private subnetの
route tableを選択して、endpoint作成
-
作ったものを確認
-
private subnetの
route tableに以下のrouteが自動的に追加された
- Destiationをクリックすると、
Prifix listが表示される
-
Prifix listの中身：
-
こちらの
Prefix listはAWSによって管理され、自動的に更新されます。 -
Prefix listの名前はリージョン＋サービスで固定されています。例えば、東京リージョンのS3を利用しているすべてのユーザーはpl-61a54008というPrefix listを使用します。
-
リージョン固有：各AWSリージョンに特有のS3 IPアドレス範囲が含まれる。
-
以下のコマンドで東京リージョンのS3のパブリックIP一覧を取得できた。原因はまだ不明ですが、上記の
Prefix listよりも数個多いようです。~ % curl https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes[] | select(.region=="ap-northeast-1") | select(.service=="S3") | .ip_prefix' 52.219.68.0/22 52.219.162.0/23 52.219.16.0/22 52.219.195.0/24 3.5.152.0/21 52.219.0.0/20 52.219.20.0/24 52.219.136.0/22 52.219.201.0/24 52.219.172.0/22 52.219.200.0/24 52.219.152.0/22 52.219.150.0/23 52.219.196.0/22 35.72.164.240/28 35.73.115.0/28
-
private subnetの
-
-
private subnetのEC2からendpoint経由でS3のバケットリストが取得できた
[ec2-user@ip-10-0-30-163 ~]$ ping google.co.jp PING google.co.jp (142.251.42.131) 56(84) bytes of data. 64 bytes from nrt12s45-in-f3.1e100.net (142.251.42.131): icmp_seq=1 ttl=56 time=1.25 ms 64 bytes from nrt12s45-in-f3.1e100.net (142.251.42.131): icmp_seq=2 ttl=56 time=1.28 ms 64 bytes from nrt12s45-in-f3.1e100.net (142.251.42.131): icmp_seq=3 ttl=56 time=1.32 ms ^C --- google.co.jp ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 1.248/1.281/1.319/0.029 ms [ec2-user@ip-10-0-30-163 ~]$ aws s3 ls 2024-06-24 06:53:51 databricks-workspace-stack-bucket
3. インターフェース型エンドポイント
インターフェース型エンドポイントはElastic Network Interface (ENI) を介することで、インターネットを経由せずにAWSのプライベートネットワーク経由で直接AWSサービスにアクセスできるVPCエンドポイントの一種です。
インターフェース型エンドポイント中のインターフェースは、ENI を指しています。つまり、インターフェースVPCエンドポイントの正体はENIです。
ENIは、物理的な環境におけるNetwork Interface Card (NIC)に相当します。VPC内のリソースとAWSサービス間の通信を仲介する役割を果たします。
インターフェース型エンドポイントの仕組みやインターフェースVPCエンドポイントを利用してSystem Managerからprivate subnetにあるEC2インスタンスにアクセスするケースについては以下をご参考：
インターフェース型VPCエンドポイントのイメージとしては以下のような感じです。
- 作成時にENIのプライベートIPアドレスも指定可能
- ENIには、サブネットのアドレス範囲(CIDR内で空いているIP)からプライベートIPアドレスが割り当てられます。
- これにより、VPC内のリソースが固定のプライベートIPアドレスを使用してAWSサービスにアクセスできるようになります。
- IPを指定しない場合はAWS側でサブネットのCIDR内で空いているIPがランダムに付与される
4. VPCエンドポイントのまとめ
AWS のゲートウェイエンドポイントとインターフェースエンドポイントを総合的に比較した結果を以下の表にまとめました。
| 特徴 | ゲートウェイエンドポイント | インターフェースエンドポイント |
|---|---|---|
| サポートするサービス | S3とDynamoDBのみ |
S3、DynamoDBも含まれる多数のAWSサービスとパートナーサービス |
| 接続方式(正体) | ルートテーブルを使用 | ENIを使用 |
| AWS PrivateLink の使用 | 使用しない | 使用する |
| コスト | 完全無料 | 時間単位の料金 + データ通信量 |
| セキュリティ制御 | VPCエンドポイントポリシー | セキュリティグループ(細かい制御可能) |
| 可用性 | リージョン内のすべてのAZで自動的に高可用性 | 各AZに個別に作成する必要あり |
| 外部からのアクセス | VPC内からのみアクセス可能 | VPC外からもアクセス可能 |
| IPアドレス | 不要 | プライベートIPアドレスを使用 |
| DNS設定 | 不要 | 必要 |
| パフォーマンス | 低レイテンシー | やや高いレイテンシー |
| セットアップの複雑さ | 比較的シンプル | やや複雑 |
| クロスリージョンアクセス | 不可 | 可能 |
| オンプレミス接続 | 不可能 | 可能(Direct ConnectやVPN経由) |
5. S3とDynamoDBにおけるゲートウェイ型とインターフェース型エンドポイントの使い分け
S3は2021年2月から、DynamoDBは2024年3月からインターフェース型エンドポイントも利用可能になった。使い分けのベストプラクティスはいかになる：
-
コスト重視の場合はゲートウェイ型を選択:
- ゲートウェイ型エンドポイント：完全無料
- インターフェース型エンドポイント：時間単位の料金(通信しなくても課金) + データ転送量に応じた料金
-
VPC内からのアクセスのみの場合はゲートウェイ型:
- VPC内のリソースから
S3やDynamoDBにアクセスする場合、ゲートウェイ型で十分
- VPC内のリソースから
-
オンプレミスや他のregionからのアクセスが必要な場合はインターフェース型:
ゲートウェイ型はVPC外からのアクセスを許可しませんが、インターフェース型はオンプレミスや他のAWSリージョンからのアクセスが可能
- リージョンをまたぐ接続：
リージョン間でVPCピアリング接続を行う場合、インターフェイス型エンドポイントを選択する必要があります。
- オンプレミスからのプライベートな接続：
通信元がオンプレミス環境の場合、ゲートウェイ型エンドポイントは利用できません。オンプレミスとAWSの通信は専用線やVPNを経由し、インターフェイス型エンドポイントを選択することでプライベートな接続が可能になります。
- リージョンをまたぐ接続：
6.PrivateLinkとインターフェースVPCエンドポイントの関係
-
AWS
PrivateLinkの定義:-
AWS PrivateLinkは単独のサービスメニューではありません。AWSコンソールの検索ボックスにPrivateLinkと入力しても直接的な結果は表示されません。 - 実際には、AWS
PrivateLinkは以下の要素を組み合わせた技術やアーキテクチャの総称：- インターフェースVPCエンドポイント（サービス利用側のVPC内で作成）
- VPCエンドポイントサービス（サービス提供側のVPC内で作成）
- VPCとサポートされているAWSサービス、他のAWSアカウントによってホストされているサービス、およびAWS Marketplaceのサービス間のプライベート接続を確立するために利用される。
-
-
PrivateLinkの構成要素:-
VPCから他のAWSアカウントによってホストされているサービスや、AWS上で稼働している第三者提供のSaaSサービスへの接続の場合：
- インターフェースVPCエンドポイント（サービス利用側のVPC内で作成）
-
VPCエンドポイントサービス（サービス提供側のVPC内で作成）
-
VPCからサポートされているAWSサービスへの接続の場合:
- インターフェースVPCエンドポイントのみを使用
-
VPCエンドポイントサービスは不要
AWSサービスへの接続では、AWSが既にサービス側のインフラストラクチャを管理しているため、VPCエンドポイントサービスを別途作成する必要がありません。AWSが提供するエンドポイントに直接接続することができます。
-
-
インターフェースVPCエンドポイントとの関係:
-
PrivateLinkがインターフェースVPCエンドポイントと同義ではありません。 -
インターフェースVPCエンドポイントはAWS
PrivateLinkの一部であり、サービス利用側のVPC内に作成されるコンポーネントです。
-
-
VPCエンドポイントとの関係:
- VPCエンドポイントには、インターフェース型、ゲートウェイ型、Gateway Load Balancer型の3種類があり、このうちAWS
PrivateLinkを使用するのは以下の二種類です。- インターフェース型エンドポイント
- Gateway Load Balancer型エンドポイント
- ゲートウェイ型エンドポイント（
S3やDynamoDBで使用）はAWSPrivateLinkを使用しません。
ゲートウェイ型エンドポイントは、ルートテーブルのエントリを使用してトラフィックをルーティングします。これはENIを使用するPrivateLinkとは根本的に異なるアプローチです。
- VPCエンドポイントには、インターフェース型、ゲートウェイ型、Gateway Load Balancer型の3種類があり、このうちAWS