前回の記事ではVPCピアリングについて詳細な分析を行いました。本記事では、AWS PrivateLinkに焦点を当て、その特徴と利点を深く掘り下げていきます。さらに、VPCピアリングとAWS PrivateLinkの比較を通じて、それぞれの技術がどのようなシナリオで最適かを明らかにします。この分析により、AWSネットワーキングソリューションの選択において、より適切な判断ができるようになるでしょう。

目次

PrivateLink の概要
PrivateLink の仕組み
2.1 全体的な構成
2.2 インターフェース型エンドポイント
2.3 エンドポイントサービス
主な利用シーン
3.1 プライベートサブネット内のリソースからAWSサービスへのアクセス
3.2 他のAWSアカウントによってホストされているサービスへのアクセス
3.3 AWS上で稼働している第三者提供のSaaSサービスとのPrivateLink接続
詳細な設定手順
4.1 プライベートサブネット内のリソースからAWSサービスへのアクセス
4.2 他のAWSアカウントによってホストされているサービスへのアクセス
料金体系
5.1 Consumer側
5.2 Provider側
制限事項と考慮点
PrivateLinkのベストプラクティス
7.1 Consumer側
7.2 Provider側
VPC ピアリングと PrivateLink の比較
まとめ
Q/A
参考記事

1. AWS `PrivateLink` の概要

PrivateLink とは何か
- AWS PrivateLinkは、VPCとAWSのサービス、または他のVPC内のサービスを、プライベートに接続するためのAWSのネットワーキングサービスです。
- インターネットを経由せずに、AWSのバックボーンネットワークを通じて安全に通信を行うことができます。
PrivateLink の主な特徴と利点
- プライベート接続：パブリックインターネットを経由せずに、VPC内からAWSサービスやパートナーサービスにアクセスできます。
- セキュリティの向上：トラフィックがAWSネットワーク内に閉じているため、外部からの攻撃リスクが低減されます。
- スケーラビリティ：AWSが自動的にスケーリングを行うため、高可用性と耐久性が確保されます。
- 柔軟性：異なるアカウント間でのサービス提供が可能です。同一リージョン内での利用に限定されます。
- コスト効率：データ転送量に応じた料金体系で、専用線やVPNよりも低コストで運用できる場合があります。

2. `PrivateLink` の仕組み

2.1 全体的な構成

AWS PrivateLinkは単独のサービスメニューではありません。AWSコンソールの検索ボックスにPrivateLinkと入力しても直接的な結果は表示されません。
実際には、AWS PrivateLinkは以下の要素を組み合わせた技術やアーキテクチャの総称：
- VPCエンドポイント（サービス利用側のVPC内で作成）
  1. インターフェース型VPCエンドポイント
    - AWSサービスやVPCエンドポイントサービスに接続
  2. Gateway Load Balancer型VPCエンドポイント
    - セキュリティためのトラフィックの検査や変換などのサービスに使用
  - 本記事ではインターフェース型VPCエンドポイントに焦点を当てます
- VPCエンドポイントサービス（サービス提供側のVPC内で作成）

2.2 インターフェース型エンドポイント

インターフェース型エンドポイントは、以下の特徴を持つVPCエンドポイントの一種です。

Elastic Network Interface (ENI) を使用
- インターフェース型エンドポイントの「インターフェース」はENIを指す
- インターフェースVPCエンドポイントの本質はENI
- 物理環境のNetwork Interface Card (NIC)に相当し、VPC内リソースとAWSサービス間の通信を仲介
AWSのプライベートネットワークを利用し、インターネットを経由しない
AWSマネージドサービスやAWS上で稼働している第三者提供のSaaSに直接アクセス可能
- AWS PrivateLinkは、AWS内部のネットワークを使用してサービスに接続します。そのため、接続先のサービスはAWS上で稼働している必要があります。
- 一部のSaaSプロバイダーは、複数のクラウドプラットフォームでサービスを提供しており、AWS上でも同じサービスを展開している場合があります。その場合、AWS上で稼働しているバージョンにはAWS PrivateLinkで接続できる。

VPCエンドポイントには、以下の3種類があります。

インターフェース型
ゲートウェイ型
Gateway Load Balancer型

このうちAWS PrivateLinkを使用するのは以下の二種類のみです。本記事はインターフェース型VPCエンドポイントにフォーカスします。

インターフェース型
Gateway Load Balancer型

2.3 エンドポイントサービス

エンドポイントサービスは、AWS PrivateLinkの重要な構成要素の1つです。これは、サービスプロバイダーがAWS PrivateLinkを通じて自社のサービスを他のAWSアカウントに提供するために使用します。

エンドポイントサービスの主な構成要素：

Network Load Balancer (NLB)
- サービスプロバイダーのVPC内に設置
- トラフィックの分散と負荷分散を担当
- Internet NLBよりはInternal NLBの使用をお勧め
VPCエンドポイントサービス
- NLBに関連付けられて作成
- サービスの可用性とスケーラビリティを確保
許可設定
- 特定のAWSアカウントやIAMユーザーにサービスへのアクセスを許可

3. 主な利用シーン

3.1 プライベートサブネット内のリソースからAWSサービスへのアクセス

構成要素：
- インターフェースVPCエンドポイントのみ
特徴：
- Internet GatewayやNAT Gatewayを経由せずに直接アクセス可能、セキュリティの向上とネットワーク構成の簡素化
- VPCエンドポイントサービスは不要(AWSが既にサービス側のインフラを管理するため、AWSが提供するエンドポイントに直接接続可能)

インターフェースVPCエンドポイント使わず、Internet Gateway(IGW)を介したアクセス：
以下の図は、インスタンスがIGWを介してAWSサービスにアクセスする方法を示しています。パブリックサブネット内のインスタンスからAWSサービスへのトラフィックは、VPCのインターネットゲートウェイを経由してAWSサービスに送られます。プライベートサブネット内のインスタンスからAWSサービスへのトラフィックは、NAT Gatewayを経由し、次にIGWを通ってAWSサービスに送られます。このトラフィックはIGWを通過しますが、AWSネットワークから外部に出ることはありません。

3.2 他のAWSアカウントによってホストされているサービスへのアクセス

構成要素：
- インターフェースVPCエンドポイント（サービス利用側のVPC内）
- VPCエンドポイントサービス（サービス提供側のVPC内）
利用シーン：
- 他部署やパートナー企業のVPCで提供されているサービスへのアクセス
- マイクロサービスアーキテクチャにおける、他のVPCに存在するサービスへのアクセス

3.3 AWS上で稼働している第三者提供のSaaSサービスとの`PrivateLink`接続

構成要素：
- インターフェースVPCエンドポイント：サービス利用側(エンドユーザー環境)のVPC内
- VPCエンドポイントサービス：サービス提供側(SaaSプロバイダー環境)のVPC内
AWS Marketplaceとの関係：
- AWS Marketplace経由での契約は必須ではありません
- SaaSプロバイダーが直接PrivateLink接続をサポートしている場合、Marketplace外でも接続可能
実際の利用例：
- ログ分析SaaSプロバイダーのDatadogにAWS PrivateLinkを使用して接続
  - Datadogは直接PrivateLink接続をサポートしています（Marketplace経由不要）
  - 現在、us-east-1リージョンでのみPrivateLinkをサポート
  - AWS us-east-1リージョンにVPCを作成し、Datadogサービス用のVPCエンドポイントを作成
  - 他のリージョンからDatadogに接続する場合、us-east-1のVPCと他のリージョンのVPCをピアリング
- データベースサービスプロバイダーのMongoDB AtlasにAWS PrivateLinkを使用して接続
  - MongoDB AtlasはAWS Marketplace経由でも直接契約でもPrivateLink接続が可能
- 機械学習モデルのデプロイサービス:
  MLモデルをホストするSaaSに、顧客がPrivateLinkを介して安全に接続し、推論リクエストを送信できる
ハイブリッドクラウド環境でのオンプレミスとAWS間の接続
- Direct ConnectやVPNを使用してオンプレミス環境からAWSのマネージドサービスに安全にアクセス
- ネットワークトラフィックをプライベートに保ちつつ、クラウドリソースを利用

4. 詳細な設定手順

4.1 プライベートサブネット内のリソースからAWSサービスへのアクセス

インターフェースVPCエンドポイントを利用してSystem Managerからprivate subnetにあるEC2インスタンスにアクセスするケースについては以下をご参考：

4.2 他のAWSアカウントによってホストされているサービスへのアクセス

プロバイダー側の設定とコンシューマー側の設定が必要です。詳細は以下の記事をご参考ください。

5. 料金体系

インターフェース型VPCエンドポイントの料金体系は以下のようになっています。

5.1 Consumer側

時間料金:
- 各VPCエンドポイントに対して、プロビジョニングされている時間ごとに課金されます。
  - 通信しなくても課金され続けるため、必要なときだけ作成し、定期的に使用状況を確認し、不要なエンドポイントを削除することが重要です
データ処理料金:
- VPCエンドポイントを通過するデータ量に応じて課金されます。
- 料金は処理されるデータ量に応じて段階的に変わります:
  - 最初の1 PB: 0.01 USD/GB
  - 次の4 PB: 0.006 USD/GB
  - 5 PB以上: 0.004 USD/GB
注意点:
- アベイラビリティーゾーン（AZ）ごとにエンドポイントを作成する場合、それぞれのエンドポイントに対して料金が発生
- 1 時間未満の VPC エンドポイント使用時間は、1 時間分として請求
- データ処理料金は、同じリージョン内のすべてのインターフェースエンドポイントを通過するデータの合計に対して適用
コスト最適化:
- 不要なVPCエンドポイントは削除することでコストを削減できます。
- 大量のデータを処理する場合、段階的な料金体系により単価が下がります。

5.2 Provider側

Network Load Balancer (NLB) 料金：
- サービスを提供するためにNLBを使用する必要があります。
VPCエンドポイントサービス料金：
明確な課金の有無を記述したドキュメントは見つかりませんでした。一般的に考えると、無料である可能性が高いと推測されます。
データ転送料金：
- Provider側にはデータ転送料金は発生しません。
- 主なデータ処理料金はConsumer側が支払い、Provider側には追加のデータ転送料金は発生しません。Provider側は主にサービスの提供に関連するインフラストラクチャーコスト（NLB等）を負担します。

6. 制限事項と考慮点

リージョン制限
- 基本的に、VPCエンドポイントは同じAWSリージョン内でのみ機能します。
- クロスリージョンのVPCエンドポイントは直接サポートされていません。
- ただし、VPCピアリングやTransit Gatewayを使用して、異なるリージョン間でPrivateLinkを利用することは可能
S3マルチリージョンアクセスポイント:
Amazon S3のマルチリージョンアクセスポイントを使用すると、AWS PrivateLinkを介して複数のリージョンにまたがるS3バケットにアクセスできます。これにより、単一のグローバルエンドポイントを通じて、異なるリージョンのS3リソースにプライベートにアクセスすることが可能になります。
サポートされるプロトコル
- TCP/IPプロトコルのみがサポートされています。
- UDPやICMPなどの他のプロトコルはサポートされていません。
- HTTPSがデフォルトで使用され、推奨されています。
セキュリティグループの設定
- Consumer側（VPCエンドポイントを作成する側）：
  - セキュリティグループのインバウンドルールで、以下を許可します：
    - プロトコル：TCP
    - ポート：サービスが使用するポート（多くの場合443）
    - ソース：　以下の３つのいずれか
      - Consumer VPC内の特定のリソース（EC2インスタンスなど）のセキュリティグループ：該当セキュリティグループをattachしたリソースからのアクセスのみを許可
      - 該当VPCエンドポイント所属するsubnetのCIDR：該当subnet内のリソースからのアクセスを許可
      - VPCのCIDR：VPC内のすべてのリソースからのアクセスを許可
- Provider側（エンドポイントサービスを提供する側）：
  - Internet NLBよりはInternal NLBの使用をお勧め
  - Network Load Balancer (NLB) 用のセキュリティグループのインバウンドルールで、以下を許可します：
    - プロトコル：TCP
    - ポート：サービスが使用するポート
    - ソース：0.0.0.0/0（すべてのVPCエンドポイントからのトラフィックを許可）
  - NLBの背後にあるEC2インスタンスなどのリソース用のセキュリティグループで、NLBからのインバウンドトラフィックを許可します：
    - プロトコル：TCP
    - ポート：アプリケーションが使用するポート
    - ソース：NLBのセキュリティグループ

これらの設定により、Consumer側からProvider側のサービスへの安全なアクセスが可能になります。セキュリティグループの設定は、必要最小限のアクセスのみを許可し、不要なトラフィックをブロックするように構成することが重要です。

7. `PrivateLink` のベストプラクティス

AWS PrivateLinkのベストプラクティスについて、ConsumerとProviderに分けて説明します。

7.1 Consumer側

可用性と冗長性の確保
- 複数のアベイラビリティーゾーン（AZ）にVPCエンドポイントを作成する
- 各AZで少なくとも1つのサブネットを指定する
セキュリティ強化のポイント
- VPCエンドポイントにセキュリティグループを適用し、必要最小限のトラフィックのみを許可する
- エンドポイントポリシーを使用して、特定のIAMプリンシパルやソースIPアドレスからのアクセスを制限する
コスト最適化の方法
- 使用していないVPCエンドポイントを削除する

7.2 Provider側

可用性と冗長性の確保
- 複数のAZにターゲットを配置したNetwork Load Balancer (NLB)を使用する
- 少なくとも2つのAZにそれぞれ1つのターゲットを維持する
- ヘルスチェックを適切に設定し、障害のあるターゲットを迅速に検出する
セキュリティ強化のポイント
- エンドポイントサービスへのアクセスを許可するAWSアカウントを慎重に管理する
- サービスコンシューマーの接続リクエストを手動で承認するオプションを検討する

8. VPC ピアリングと PrivateLink の比較

比較ポイント	VPCピアリング	PrivateLink
接続範囲	VPC全体を共有	特定のサービスのみを開放
クロスリージョン/クロスアカウント対応可否	- クロスアカウント対応 - クロスリージョン対応	- クロスアカウント対応 - クロスリージョン対応していない(S3は例外)
ネットワーク構成	- `CIDR`重複不可 - ルーティング設定が必須	- `CIDR`重複許容 - DNS解決が必要
安定性	- 非常に安定、単一障害点がない	- 安定しているが、NLBの状態に依存
主な制御方法	- セキュリティグループ - NACL	- エンドポイントポリシー - セキュリティグループ
接続の方向性	設定次第、双方向も単方向も両方可能	単方向のみ（ConsumerからProviderへ）
パフォーマンス	- 非常に低レイテンシー(AWSのバックボーンネットワークを直接使用) - 高帯域幅(制限は主にEC2インスタンスのネットワークインターフェイス性能)	- レイテンシーはVPCピアリングよりわずかに高い(`NLB`を経由するため) - 帯域幅は`NLB`の性能に依存
コスト	データ転送料のみ(VPCピアリング接続自体無料)	- 各VPCエンドポイントに対する時間料金 - データ処理料金 - サービス提供側にも`NLB`の料金が発生
制限事項	最大接続数の制限(接続数に制限があり、多数のVPC接続には不向き)	スケーラビリティが制限される場合
実装の容易さ	設定は比較的簡単だが、`CIDR`計画に注意必須	設定は少し複雑だが、一部のAWSサービスで簡素化可能
ユースケース	- 大規模なマイクロサービスアーキテクチャ - 特定サービスの共有（ライセンス管理、監視システムなど） - データ分析環境の分離 - 小規模な組織間の限定的な接続	- AWSマネージドサービスへのセキュアなアクセス - 他のAWSアカウントによってホストされているサービスへのアクセス - サードパーティのSaaSへのアクセス

追加の説明：

VPCピアリング：
- VPC全体を共有するため、広範囲のリソースにアクセス可能。
- セキュリティグループとNACLを使用して、必要に応じてトラフィックを制限。
- 大規模な環境では、セキュリティ設定の管理が複雑になる可能性がある。
PrivateLink：
- 特定のサービスのみを開放するため、不要なネットワーク露出を最小限に抑える。
- エンドポイントポリシーを使用して、サービスレベルでのアクセス制御が可能。
- セキュリティグループでさらに細かい制御を追加できる。
- 必要最小限のアクセスを提供するため、より高いセキュリティを実現。
- 一方向の通信が前提となっています。双方向にするには、逆のルートも作成する必要があり、金額的には2倍の必要が必要です

9. まとめ

10. Q/A

インタフェース型のエンドポイントは完全にNAT Gatewayに置き換えられるか?
- インターフェース型VPCエンドポイントは特定のAWSサービスやPrivateLink対応できるサードパーティのSaaSへアクセスするのに対し、NAT Gatewayはインターネット上の任意のリソースにアクセスできます。
- NAT Gatewayを使用してプライベートサブネットからインターネットにアクセスする具体的な例
  1. セキュリティパッチの適用:プライベートサブネット内のLinux EC2インスタンスが、最新のセキュリティパッチをダウンロードして適用する必要がある場合。例えば、yum update や apt-get upgrade コマンドを実行する際に、NAT Gatewayを経由してパッチサーバーにアクセス
  2. アプリケーションの自動更新:プライベートサブネット内で動作するアプリケーション（例：Webサーバー）が、自動更新機能を使用して最新バージョンをダウンロードする場合。NAT Gatewayを通じて、アプリケーションの公式リポジトリにアクセスします。
  3. 決済ゲートウェイAPIやGoogle MapsやMapbox等の外部地図サービスAPIやユーザーにプッシュ通知を送信するためにAmazon SNS（Simple Notification Service）など外部APIの利用
  4. データベースレプリケーション:プライベートサブネット内のデータベースサーバーが、オンプレミス環境にあるマスターデータベースとデータを同期する必要がある場合はNAT Gatewayを経由して、オンプレミス環境のデータベースサーバーにアクセス
    これらの例では、NAT Gatewayがプライベートサブネット内のリソースとインターネット間の「橋渡し」の役割を果たし、セキュリティを維持しながら必要な外部通信を可能にしています
- インターフェース型VPCエンドポイントとNAT Gatewayは異なる用途に使用されるため、完全に置き換えることはできません。ただし、特定のAWSサービスへのアクセスについては、インターフェース型VPCエンドポイントを使用することで、NAT Gatewayを経由せずにプライベートにアクセスすることが可能です。これにより、セキュリティを向上させ、インターネット経由の通信を減らすことができます。
- 上記のシーンではNat Gatewayが必要不可欠になり、コスト削減のために、新たにVPC エンドポイントを作らず、Nat Gateway + IGWを利用するパターンもあります。

マイクロサービスアーキテクチャを採用し、各マイクロサービスを異なるVPCに分割している場合、VPCピアリングとAWS PrivateLinkのどちらを選択するか?

マイクロサービスアーキテクチャの場合、AWS PrivateLinkの使用をお勧めします。理由は以下の通りです：
- セキュリティ強化：各マイクロサービスが必要とする特定のエンドポイントのみを公開できます。
- サービス間の独立性維持：マイクロサービスの原則に沿って、サービス間の疎結合を保ちやすくなります。
- 柔軟なスケーリング：新しいマイクロサービスの追加や既存サービスの変更が容易です。
- CIDRの柔軟性：各マイクロサービスのVPCを独立して設計できます。
- 将来の拡張性：他のAWSアカウントやサードパーティサービスとの統合が容易になります。
ただし、パフォーマンスとコストを重視する場合や、マイクロサービス間で広範な通信が必要な場合は、VPCピアリングも検討する価値があります。最終的には、プロジェクトの具体的な要件、セキュリティポリシー、および運用方針に基づいて判断してください。

11. 参考記事