AWS環境のセキュリティを強化：PrivateLinkとVPCピアリングの賢い使い分け

https://qiita.com/dennis_wang/items/d61f415d38d593583565

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

# 目次
1. [`PrivateLink` の概要](#1-aws-privatelink-の概要)
2. [`PrivateLink` の仕組み](#2-privatelink-の仕組み)
   2.1 [全体的な構成](#21-全体的な構成)
   2.2 [インターフェース型エンドポイント](#22-インターフェース型エンドポイント)
   2.3 [エンドポイントサービス](#23-エンドポイントサービス)
3. [主な利用シーン](#3-主な利用シーン)
   3.1 [プライベートサブネット内のリソースからAWSサービスへのアクセス](#31-プライベートサブネット内のリソースからawsサービスへのアクセス)
   3.2 [他のAWSアカウントによってホストされているサービスへのアクセス](#32-他のawsアカウントによってホストされているサービスへのアクセス)
   3.3 [AWS上で稼働している第三者提供のSaaSサービスとの`PrivateLink`接続](#33-aws上で稼働している第三者提供のsaasサービスとのprivatelink接続)
4. [詳細な設定手順](#4-詳細な設定手順)
   4.1 [プライベートサブネット内のリソースからAWSサービスへのアクセス](#41-プライベートサブネット内のリソースからawsサービスへのアクセス)
   4.2 [他のAWSアカウントによってホストされているサービスへのアクセス](#42-他のawsアカウントによってホストされているサービスへのアクセス)
5. [料金体系](#5-料金体系)
   5.1 [Consumer側](#51-consumer側)
   5.2 [Provider側](#52-provider側)
6. [制限事項と考慮点](#6-制限事項と考慮点)
7. [`PrivateLink`のベストプラクティス](#7-privatelink-のベストプラクティス)
   7.1 [Consumer側](#71-consumer側)
   7.2 [Provider側](#72-provider側)
8. [VPC ピアリングと `PrivateLink` の比較](#8-vpc-ピアリングと-privatelink-の比較)
9. [まとめ](#9-まとめ)
10. [Q/A](#10-qa)
11. [参考記事](#11-参考記事)

# 1. AWS `PrivateLink` の概要

- `PrivateLink` とは何か
  - AWS `PrivateLink`は、VPCとAWSのサービス、または他のVPC内のサービスを、プライベートに接続するためのAWSのネットワーキングサービスです。
  - <font color="red">インターネットを経由せずに、AWSのバックボーンネットワークを通じて安全に通信</font>を行うことができます。

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

https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html

# 2. `PrivateLink` の仕組み

## 2.1 全体的な構成
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/0d2d522b-3dd5-79d1-90b9-451c33ceb519.png)

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

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

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

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

VPCエンドポイントには、以下の3種類があります。
- インターフェース型
- ゲートウェイ型
- `Gateway Load Balancer`型
![image-16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/289b03a7-a1f0-fa2c-9afe-d184feb3f606.png)

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

https://dev.classmethod.jp/articles/aws-vpcendpoint-privatelink-beginner/

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

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

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

1. `Network Load Balancer` (NLB)
   - サービスプロバイダーのVPC内に設置
   - トラフィックの分散と負荷分散を担当
   - <font color="red">Internet NLBよりは`Internal NLB`の使用をお勧め</font>

1. VPCエンドポイントサービス
   - NLBに関連付けられて作成
   - サービスの可用性とスケーラビリティを確保

1. 許可設定
   - 特定のAWSアカウントやIAMユーザーにサービスへのアクセスを許可

# 3. 主な利用シーン

https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/use-case-examples.html


![image-11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/c6ec6f0f-2207-a9d5-4536-8e508b9e8228.png)


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

1. 構成要素：
   - インターフェースVPCエンドポイントのみ

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

    ![image-9.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/200cb10a-aa12-21dc-b13c-8826185ac135.png)

:::note info
インターフェースVPCエンドポイント使わず、`Internet Gateway(IGW)`を介したアクセス：
以下の図は、インスタンスが`IGW`を介してAWSサービスにアクセスする方法を示しています。パブリックサブネット内のインスタンスからAWSサービスへのトラフィックは、VPCのインターネットゲートウェイを経由してAWSサービスに送られます。プライベートサブネット内のインスタンスからAWSサービスへのトラフィックは、`NAT Gateway`を経由し、次に`IGW`を通ってAWSサービスに送られます。<font color="red">このトラフィックはIGWを通過しますが、AWSネットワークから外部に出ることはありません</font>。
 ![image-10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/00702d47-07b9-52f8-66d6-23feca11cf8b.png)
:::

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

1. 構成要素：
   - インターフェースVPCエンドポイント（サービス利用側のVPC内）
   - VPCエンドポイントサービス（サービス提供側のVPC内）

1. 利用シーン：
   - 他部署やパートナー企業のVPCで提供されているサービスへのアクセス
   - マイクロサービスアーキテクチャにおける、他のVPCに存在するサービスへのアクセス

![image-8.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/fa1b180f-f0fe-8c63-689b-678b3146e81e.png)


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

1. 構成要素：
   - インターフェースVPCエンドポイント：サービス利用側(エンドユーザー環境)のVPC内
   - VPCエンドポイントサービス：サービス提供側(SaaSプロバイダー環境)のVPC内

1. AWS Marketplaceとの関係：
   - <font color="red">AWS Marketplace経由での契約は必須ではありません</font>
   - SaaSプロバイダーが直接`PrivateLink`接続をサポートしている場合、Marketplace外でも接続可能

1. 実際の利用例：
   - [ログ分析SaaSプロバイダーの`Datadog`にAWS `PrivateLink`を使用して接続](https://qiita.com/GoogIeSensei/items/bcdc8b847f27713b3100)
     - `Datadog`は直接`PrivateLink`接続をサポートしています（Marketplace経由不要）
     - 現在、`us-east-1`リージョンでのみ`PrivateLink`をサポート
     - AWS `us-east-1`リージョンにVPCを作成し、`Datadog`サービス用のVPCエンドポイントを作成
     - 他のリージョンから`Datadog`に接続する場合、`us-east-1`のVPCと他のリージョンのVPCをピアリング
   ![image-13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/b8592251-80c5-f661-2d4e-32f8c410a3b4.png)


   - データベースサービスプロバイダーの`MongoDB Atlas`にAWS `PrivateLink`を使用して接続
     - `MongoDB Atlas`はAWS Marketplace経由でも直接契約でも`PrivateLink`接続が可能
   ![image-14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/e76b3ae2-ddd0-cae1-ed16-4f07c8d88f90.png)



   - 機械学習モデルのデプロイサービス:
     MLモデルをホストするSaaSに、顧客が`PrivateLink`を介して安全に接続し、推論リクエストを送信できる
   ![image-15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/e1f33f89-ad1c-3f21-f162-b9f50dd86402.png)


1. ハイブリッドクラウド環境でのオンプレミスとAWS間の接続
    - `Direct Connect`や`VPN`を使用してオンプレミス環境からAWSのマネージドサービスに安全にアクセス
    - ネットワークトラフィックをプライベートに保ちつつ、クラウドリソースを利用
   ![image-12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/c311bb4e-f4f7-8f29-1409-aa57992ba83c.png)

https://aws.amazon.com/jp/blogs/apn/connecting-applications-securely-to-a-mongodb-atlas-data-plane-with-aws-privatelink/

https://dev.classmethod.jp/articles/mongodb-atlas-aws-marketplace-subscribe/

https://aws.amazon.com/jp/blogs/networking-and-content-delivery/private-network-for-data-movement-in-generative-ai/


# 4. 詳細な設定手順
## 4.1 プライベートサブネット内のリソースからAWSサービスへのアクセス
インターフェースVPCエンドポイントを利用して`System Manager`から`private subnet`にある`EC2`インスタンスにアクセスするケースについては以下をご参考：

https://qiita.com/dennis_wang/items/02396659ba65ba0aa0e2#523-%E4%BB%95%E7%B5%84%E3%81%BF%E3%81%AE%E8%A7%A3%E8%AA%AC

## 4.2 他のAWSアカウントによってホストされているサービスへのアクセス
プロバイダー側の設定とコンシューマー側の設定が必要です。詳細は以下の記事をご参考ください。

https://dev.classmethod.jp/articles/aws-vpcendpoint-privatelink-beginner/


# 5. 料金体系

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

## 5.1 Consumer側

1. 時間料金:
   - 各VPCエンドポイントに対して、プロビジョニングされている時間ごとに課金されます。
     - <font color="red">通信しなくても課金され続けるため、必要なときだけ作成し、定期的に使用状況を確認し、不要なエンドポイントを削除することが重要です</font>

2. データ処理料金:
   - VPCエンドポイントを通過するデータ量に応じて課金されます。
   - 料金は処理されるデータ量に応じて段階的に変わります:
     - 最初の1 PB: 0.01 USD/GB
     - 次の4 PB: 0.006 USD/GB
     - 5 PB以上: 0.004 USD/GB

3. 注意点:
   - <font color="red">アベイラビリティーゾーン（AZ）ごとにエンドポイントを作成する場合、それぞれのエンドポイントに対して料金が発生</font>
   - 1 時間未満の VPC エンドポイント使用時間は、1 時間分として請求
   - データ処理料金は、同じリージョン内のすべてのインターフェースエンドポイントを通過するデータの合計に対して適用

4. コスト最適化:
   - <font color="red">不要なVPCエンドポイントは削除することでコストを削減できます。</font>
   - 大量のデータを処理する場合、段階的な料金体系により単価が下がります。

https://aws.amazon.com/jp/privatelink/pricing/

## 5.2 Provider側

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

# 6. 制限事項と考慮点

1. リージョン制限
   - <font color="red">基本的に、VPCエンドポイントは同じAWSリージョン内でのみ機能</font>します。
   - クロスリージョンのVPCエンドポイントは直接サポートされていません。
   - ただし、<font color="red">VPCピアリングや`Transit Gateway`を使用して、異なるリージョン間で`PrivateLink`を利用することは可能</font>
    :::note info
    <font color="red">S3マルチリージョンアクセスポイント</font>:
    Amazon S3のマルチリージョンアクセスポイントを使用すると、AWS `PrivateLink`を介して複数のリージョンにまたがるS3バケットにアクセスできます。これにより、単一のグローバルエンドポイントを通じて、異なるリージョンのS3リソースにプライベートにアクセスすることが可能になります。
1. サポートされるプロトコル
   - `TCP/IP`プロトコルのみがサポートされています。
   - `UDP`や`ICMP`などの他のプロトコルはサポートされていません。
   - `HTTPS`がデフォルトで使用され、推奨されています。

1. セキュリティグループの設定
   - 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側のサービスへの安全なアクセスが可能になります。セキュリティグループの設定は、必要最小限のアクセスのみを許可し、不要なトラフィックをブロックするように構成することが重要です。

https://dev.classmethod.jp/articles/tried-aws-privatelink-between-vpcs/

# 7. `PrivateLink` のベストプラクティス
AWS `PrivateLink`のベストプラクティスについて、ConsumerとProviderに分けて説明します。
![image-18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/9dc31944-7d61-0f03-1f67-a940d1bebe4b.png)

## 7.1 Consumer側

1. 可用性と冗長性の確保
   - 複数のアベイラビリティーゾーン（AZ）にVPCエンドポイントを作成する
   - 各AZで少なくとも1つのサブネットを指定する

1. セキュリティ強化のポイント
   - VPCエンドポイントにセキュリティグループを適用し、必要最小限のトラフィックのみを許可する
   - エンドポイントポリシーを使用して、特定のIAMプリンシパルやソースIPアドレスからのアクセスを制限する

1. コスト最適化の方法
   - 使用していないVPCエンドポイントを削除する

## 7.2 Provider側

1. 可用性と冗長性の確保
   - 複数のAZにターゲットを配置した`Network Load Balancer (NLB)`を使用する
   - 少なくとも2つのAZにそれぞれ1つのターゲットを維持する
   - ヘルスチェックを適切に設定し、障害のあるターゲットを迅速に検出する

1. セキュリティ強化のポイント
   - エンドポイントサービスへのアクセスを許可するAWSアカウントを慎重に管理する
   - サービスコンシューマーの接続リクエストを手動で承認するオプションを検討する

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

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

追加の説明：

1. VPCピアリング：
   - VPC全体を共有するため、広範囲のリソースにアクセス可能。
   - セキュリティグループとNACLを使用して、必要に応じてトラフィックを制限。
   - 大規模な環境では、セキュリティ設定の管理が複雑になる可能性がある。

2. PrivateLink：
   - 特定のサービスのみを開放するため、不要なネットワーク露出を最小限に抑える。
   - エンドポイントポリシーを使用して、サービスレベルでのアクセス制御が可能。
   - セキュリティグループでさらに細かい制御を追加できる。
   - 必要最小限のアクセスを提供するため、より高いセキュリティを実現。
   - 一方向の通信が前提となっています。<font color="red">双方向にするには、逆のルートも作成する必要があり、金額的には2倍の必要が必要です</font>
![image-17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/f7e8129e-6e36-d15e-1e08-83e2a9ec14dd.png)

https://qiita.com/Masayuki-Goto/items/636100a4862d626d732d#233-%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B33privatelink-%E7%B5%8C%E7%94%B1

# 9. まとめ

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


    - インターフェース型VPCエンドポイントと`NAT Gateway`は異なる用途に使用されるため、完全に置き換えることはできません。ただし、特定のAWSサービスへのアクセスについては、インターフェース型VPCエンドポイントを使用することで、`NAT Gateway`を経由せずにプライベートにアクセスすることが可能です。これにより、セキュリティを向上させ、インターネット経由の通信を減らすことができます。
    - 上記のシーンでは`Nat Gateway`が必要不可欠になり、コスト削減のために、新たにVPC エンドポイントを作らず、`Nat Gateway` + `IGW`を利用するパターンもあります。

https://zenn.dev/simpleform_blog/articles/f048edb9efd2b2


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

    マイクロサービスアーキテクチャの場合、AWS `PrivateLink`の使用をお勧めします。理由は以下の通りです：
    - セキュリティ強化：各マイクロサービスが必要とする特定のエンドポイントのみを公開できます。
    - サービス間の独立性維持：マイクロサービスの原則に沿って、サービス間の疎結合を保ちやすくなります。
    - 柔軟なスケーリング：新しいマイクロサービスの追加や既存サービスの変更が容易です。
    - CIDRの柔軟性：各マイクロサービスのVPCを独立して設計できます。
    - 将来の拡張性：他のAWSアカウントやサードパーティサービスとの統合が容易になります。

    ただし、パフォーマンスとコストを重視する場合や、マイクロサービス間で広範な通信が必要な場合は、VPCピアリングも検討する価値があります。最終的には、プロジェクトの具体的な要件、セキュリティポリシー、および運用方針に基づいて判断してください。

# 11. 参考記事

https://qiita.com/dennis_wang/items/e881f2d502b1a0addfbe

https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html

https://qiita.com/inoue_d/items/7495f90a95636cf4298e

https://aws.amazon.com/jp/blogs/psa/aws-privatelink-saas-whi/

https://dev.classmethod.jp/articles/aws-vpcendpoint-privatelink-beginner/

https://qiita.com/Masayuki-Goto/items/636100a4862d626d732d

https://qiita.com/mksamba/items/20903940b8b256ef2487

https://qiita.com/GoogIeSensei/items/bcdc8b847f27713b3100

https://awsmorocco.com/how-does-aws-privatelink-works-faddc730ed73