AWS PrivateLinkの真実：VPCエンドポイントとの関係性を徹底解説

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のルートテーブルにアクセスできないため、エンドポイントを直接利用することはできません。
• 完全無料

1. 歴史的経緯:
   • ゲートウェイ型エンドポイントは、インターフェース型エンドポイントよりも先に導入されました。
   • 当初はS3とDynamoDBへのプライベートアクセスを提供するために設計されました。
   • ゲートウェイ型はルートテーブルを使用して実装されており、DNSの成熟を待つ必要がありませんでした
   • インターフェース型エンドポイントはより新しい技術でAWS PrivateLinkを使用し、柔軟性が高いですが、コストがかかります。
2. S3は2021年2月から、DynamoDBは2024年3月からインターフェース型エンドポイントも利用可能になった。

2.2 ゲートウェイ型エンドポイントを検証

全体図：

2.2.1 事前準備

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用)

2. public subnetとprivate subnetそれぞれに1つのEC2インスタンス作成(新規作成する時に、同じkey-pairを選択する必要がある)

3. ローカル端末のみに秘密鍵を保持し、SSH Agent Forwardingによるbastionサーバー経由でprivate subnetにあるEC2にアクセス。詳細なやり方は以下の記事をご参考

2.2.2 VPCエンドポイントなしの状態でS3のバケットリストを取得

1. 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
   

2. 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のバケットリストを取得

1. 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
       

2. 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エンドポイントポリシー	ENIに割り当てるセキュリティグループ(細かい制御可能)
可用性	リージョン内のすべてのAZで自動的に高可用性	各AZに個別に作成する必要あり
オンオプレからのアクセス	VPC内からのみアクセス可能	可能
IPアドレス	不要	プライベートIPアドレスを使用
DNS設定	不要	必要
パフォーマンス	低レイテンシー	やや高いレイテンシー
セットアップの複雑さ	比較的シンプル	やや複雑
クロスリージョンアクセス	不可	可能
オンプレミス接続	不可能	可能(Direct ConnectやVPN経由)

5. S3とDynamoDBにおけるゲートウェイ型とインターフェース型エンドポイントの使い分け

S3は2021年2月から、DynamoDBは2024年3月からインターフェース型エンドポイントも利用可能になった。使い分けのベストプラクティスはいかになる：

1. コスト重視の場合はゲートウェイ型を選択:

   • ゲートウェイ型エンドポイント：完全無料
   • インターフェース型エンドポイント：時間単位の料金(通信しなくても課金) + データ転送量に応じた料金

2. VPC内からのアクセスのみの場合はゲートウェイ型:

   • VPC内のリソースからS3やDynamoDBにアクセスする場合、ゲートウェイ型で十分

3. オンプレミスや他のregionからのアクセスが必要な場合はインターフェース型:
   ゲートウェイ型はVPC外からのアクセスを許可しませんが、インターフェース型はオンプレミスや他のAWSリージョンからのアクセスが可能
   

   • リージョンをまたぐ接続：
     リージョン間でVPCピアリング接続を行う場合、インターフェイス型エンドポイントを選択する必要があります。
     
   • オンプレミスからのプライベートな接続：
     通信元がオンプレミス環境の場合、ゲートウェイ型エンドポイントは利用できません。オンプレミスとAWSの通信は専用線やVPNを経由し、インターフェイス型エンドポイントを選択することでプライベートな接続が可能になります。
     

6.PrivateLinkとインターフェースVPCエンドポイントの関係

1. AWS PrivateLinkの定義:

   • AWS PrivateLinkは単独のサービスメニューではありません。AWSコンソールの検索ボックスにPrivateLinkと入力しても直接的な結果は表示されません。
   • 実際には、AWS PrivateLinkは以下の要素を組み合わせた技術やアーキテクチャの総称：
     • インターフェースVPCエンドポイント（サービス利用側のVPC内で作成）
     • VPCエンドポイントサービス（サービス提供側のVPC内で作成）
   • VPCとサポートされているAWSサービス、他のAWSアカウントによってホストされているサービス、およびAWS Marketplaceのサービス間のプライベート接続を確立するために利用される。

2. PrivateLinkの構成要素:

   1. VPCから他のAWSアカウントによってホストされているサービスや、AWS上で稼働している第三者提供のSaaSサービスへの接続の場合：

      • インターフェースVPCエンドポイント（サービス利用側のVPC内で作成）
      • VPCエンドポイントサービス（サービス提供側のVPC内で作成）
        

   2. VPCからサポートされているAWSサービスへの接続の場合:

      • インターフェースVPCエンドポイントのみを使用
      • VPCエンドポイントサービスは不要
        

      AWSサービスへの接続では、AWSが既にサービス側のインフラストラクチャを管理しているため、VPCエンドポイントサービスを別途作成する必要がありません。AWSが提供するエンドポイントに直接接続することができます。

3. インターフェースVPCエンドポイントとの関係:

   • PrivateLinkがインターフェースVPCエンドポイントと同義ではありません。
   • インターフェースVPCエンドポイントはAWS PrivateLinkの一部であり、サービス利用側のVPC内に作成されるコンポーネントです。

4. VPCエンドポイントとの関係:

   • VPCエンドポイントには、インターフェース型、ゲートウェイ型、Gateway Load Balancer型の3種類があり、このうちAWS PrivateLinkを使用するのは以下の二種類です。
     • インターフェース型エンドポイント
     • Gateway Load Balancer型エンドポイント
   • ゲートウェイ型エンドポイント（S3やDynamoDBで使用）はAWS PrivateLinkを使用しません。
     ゲートウェイ型エンドポイントは、ルートテーブルのエントリを使用してトラフィックをルーティングします。これはENIを使用するPrivateLinkとは根本的に異なるアプローチです。

5. PrivateLinkのエンドポイントサービスに利用できるロードバランサー

• AWS PrivateLinkのエンドポイントサービスは、基本的にNetwork Load Balancer（NLB）のみがサポートされています。これは、AWSの仕様上、エンドポイントサービスはNLBを前提として設計されているためです。
  • 理由と背景(エンドポイントサービスの要件)：
    • 高いスループットと低遅延を実現するために、TCPレベルの負荷分散が必要です。
    • NLBはTCP/UDPのレベルで動作し、これに最適化されているため、エンドポイントサービスの前段に使われます。
    • ALB（Application Load Balancer）はレイヤー7（HTTP/HTTPS）の負荷分散を行うため、エンドポイントサービスの作成には対応していません。つまり、ALBはエンドポイントサービスのターゲットとしてはサポートされていません。
• NLBはTCP:80, 443でリッスン可能なので、REST APIの公開要件も満たせます。
• ただし、NLBのターゲットグループとしてALBを登録する新機能が提供されており、NLB経由でALBの公開が可能です。
• 構成例
  • ALBでREST API（HTTP/HTTPS）を公開
    • ALBのリスナー: 80（HTTP）、443（HTTPS）
  • NLBのターゲットグループにALBを登録
    • NLBのリスナー: TCP:80、TCP:443
    • ターゲットタイプ: ALB
  • NLBでPrivateLinkエンドポイントサービスを作成
  • 利用者はインターフェースVPCエンドポイント経由でNLBにアクセスし、ALBのAPIに到達