Amazon VPC Latticeを簡易アーキテクチャで解像度を上げてみる

本記事は、[AWS Jr.Champions Adventcalendar 2024](https://qiita.com/advent-calendar/2024/japan-aws-jr-champions) の16日目の記事です。

# はじめに

こんにちは。
Amazon VPCサービスはアップデートが盛んに行われており、最新のre:Inventのセッションでは、たくさんのコンポーネントがあるアーキテクチャが展開されました。

re:Invent 2024セッション "Amazon VPC: Advanced design and what’s new (NET301)"
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/420620/6cf18cd4-b2d0-5b28-64cb-a7cbd0bef2f4.png)
- [YouTubeリンク](https://youtu.be/7qaSfmnFiI0?si=iNRGI5Zu-_Mz7ho6) (2024/12/16閲覧可)
- [PDFリンク](https://reinvent.awsevents.com/content/dam/reinvent/2024/slides/net/NET301_Amazon-VPC-Advanced-design-and-whats-new.pdf) (2024/12/16閲覧可)

Private Link・Trangit Gateway・Cloud WANなどなどたくさんありますね笑
今回はその中でも、2023年3月31日にGAされたVPC Latticeに注目します。

https://aws.amazon.com/jp/about-aws/whats-new/2023/03/general-availability-amazon-vpc-lattice/

# VPC Latticeとは？

> Amazon VPC Latticeは、アプリケーションのサービスの接続・保護、モニタリングに使用する、フルマネージド型アプリケーションネットワーキングサービスです。VPC Latticeは、単一の仮想プライベート (VPC)、または1つ以上のアカウントの複数のVPCで使用できます。
>
>[AWS公式サイトより引用。](https://docs.aws.amazon.com/ja_jp/vpc-lattice/latest/ug/what-is-vpc-lattice.html)

各VPCをマイクロサービスと置き換えて、レガシーサービスからの接続課題を解決ソリューションであることが読み取れます。

# 構築するアーキテクチャ

今回の内容では、下記のアーキテクチャを構築しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/420620/64c17b77-d2b4-460a-0a01-9f63a2c4fb1d.png)

:::note info
特にお伝えしたい構成の特徴4選
- Client VPC, Target VPC-A/VPC-Bの**CIDR重複**を許容 (アカウント跨ぎ可）
- EC2のほかにEKS/ECS・Lambdaを許容
- CloudWatch/S3へのログ出力可
- 各ターゲットレベルでセキュリティ設定可 (IAMの一次認証コードも可)
:::

### 主要なコンポーネント
※実際に作成する場合は、Target Group⇒Service⇒ListenerRule⇒Service NetWorkで作成される順番がWorkShopでは提示されていました。

- Service Network
    - 論理的なアプリケーション層ネットワークの境界
    - VPCやアカウントを跨いでクライアントとサービスを接続
- Service
    - 単一のアプリケーションユニット (今回の場合は`virtual-server-group/lambda-group`の2つで作成しました)
- Listener Rule (Sericeの中で作成)
    - メソッドコンディション・パスコンディション・ヘッダーコンディションを選択可 (今回の場合は`virtual-target-group`のServiceで複数のTarget Groupがあるので、メソッド属性で区切りました)
    - 各ターゲットグループへの重みづけも可能
- Target Group
    - Instance, IP addresses, Lambda function, Application Load Balancerが選択できる (EC2のターゲットグループと同じ)、今回の場合は`Target-VPC-A/Target-VPC-B/Lambda`で3つ作成

最終的にVPC Latticeのリソースページは下記の内容で構築されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/420620/2d3536e9-6368-3f80-3f03-75b86625987c.png)

1. Serivce Association: Serviceの接続を設定する箇所
2. VPC associations: Client VPCを設定する箇所
3. Domain name: （VPC Latticeの大きな特徴）各Serviceにドメインが割り振られる。Target側はアップデートをしても、Client側では設定を変える必要はない
※Service Networkでバージョンによる、重みなどは設定する必要はあるかも

### いざ、接続！
- 事前準備
    - Client VPCのEC2にSSM Session Managerで接続
    - TargetのService
        - Lambda Gruopは、初期設定の`{statusCode: 200, body: "Hello from Lambda!}"`を返却想定
        - Virtual Server Groupは、Apacheを起動させており、HTMLを返却想定

:::note warn
HTTP/S・リンクローカルアドレス`169.254.0.0/16`をService NetworkのClient VPC設定時に関連付けるセキュリティグループないしEC2やALBは、許容しておく必要があります。
もしくはマネージドプレフィックスとして、`com.amazonaws.region.[ipv6].vpc-lattice`を選択する。セキュリティグループでプルダウンで出てきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/420620/d19ebfda-3833-e508-a758-50d9d4a4e9dd.png)
:::

- Lambda編
    - VPC Latticeで出力されたドメインから`curl`を実施すると返却
    ※`curl -v`を付け足すことでIPv4の`169.254.171.161`のリンクローカルアドレスに変換されている様子が確認できました

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/420620/f779709d-28eb-1a4a-ab00-031a1d19385d.png)

- Virtual Server編
    - Lambdaと同様に、VPC Latticeで出力されたドメインから`curl`を実施すると返却
    - 同じServiceでリスナールールをメソッド属性でターゲットグループを分けたため、同じURLでもEC2単独とALB配下に振り分けることを確認
    
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/420620/48c9be3b-09d9-0910-ab02-971de6bbfa21.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/420620/d118512b-312f-cce2-e28c-e7789dd7b784.png)

# 最後に
今回はVPC Latticeについて、簡易的なアーキテクチャを用いてサービスの解像度上げを試みました。これまでにもそれぞれのVPCを接続するソリューションは提供されていましたが、VPC Latticeは各VPCをマイクロサービスとして利用するためにCIDRの重複を気にしなくてよい点・ドメインで接続できる点などから、各VPCをマイクロサービス化して共有する取っ掛かりにできると思いました。

こちらの内容が理解の一助になれれば幸いです！最後まで読んでいただき、ありがとうございました！

### 参考URL
https://catalog.workshops.aws/handsonwithvpclattice/en-US