[レポート] Amazon VPC Lattice architecture patterns and best practices #NET326 #AWSreInvent

僕たちはまだAWS Latticeの可能性を正しく理解していなかったのかもしれない

AWS re:Invent 2023

#AWS

#Amazon VPC

#VPC Lattice

丸毛篤史

2023.12.22

re:Invent 2023にて「NET326 Amazon VPC Lattice architecture patterns and best practices」を聴講したので以下のとおりレポートします。

セッション概要

概要

Amazon VPC Lattice is an application networking service that simplifies connecting, securing, and monitoring service-to-service communication. You can use VPC Lattice to facilitate cross-account and cross-VPC connectivity, as well as application layer load balancing for your workloads in a consistent way regardless of the underlying compute type—instances, containers, and serverless. In this session, get a general overview of VPC Lattice, learn about the latest features and functionality, discover pro tips and tricks to adopt best practices, and explore top architecture patterns organizations use to simplify application connectivity, security, and load balancing.

Amazon VPC Latticeは、サービス間通信の接続、保護、監視を簡素化するアプリケーションネットワーキングサービスです。VPC Latticeを使用することで、インスタンス、コンテナ、サーバーレスなど、基礎となるコンピュートタイプに関係なく、一貫した方法でワークロードのアプリケーション層のロードバランシングだけでなく、クロスアカウントおよびクロスVPC接続を促進することができます。本セッションでは、VPC Latticeの概要、最新機能と特徴、ベストプラクティスを採用するためのプロフェッショナルなヒントとトリックを学び、アプリケーションの接続性、セキュリティ、ロードバランシングを簡素化するために組織が使用するトップアーキテクチャパターンを探ります。

スピーカー

Justin Davies
- (AWS) Principal Product Manaer, EC2 Networking

レポート

VPC Latticeの目的とメリット

開発者がVPCなどのネットワークを意識することなく、アプリケーションをより速く構築できるようにする
管理者は開発者がより速く、安全に作業を進められるためのガードレールとしてネットワークを単純化する
- VPCやアカウントの境界を超えてアプリケーションを接続
- IPv4、IPv6の混在環境
- ゼロトラストアーキテクチャパターンとアプリケーションレイヤーのセキュリティを採用する
- ネットワークレベルとアプリケーションレベルの両方の可視性

VPC Latticeの主要なコンポーネント

コンポーネント	役割
サービス	アプリケーションの論理的なフロントエンドで、リスナー、ルール、ターゲットグループで構成される
サービスネットワーク	サービスのグループ化メカニズムで、VPCに関連付けることで接続性を有効にする
認証ポリシー	サービスネットワークやサービスに適用できるIAMリソースポリシーで、認証と認可を制御する
サービスディレクトリ	アカウント内で作成されたサービスや共有されたサービスの一覧を表示する

サービス

重み付けによってターゲットグループを振り分ける事ができるためBlue/Greenデプロイにも利用できる。また、図には示されていないが異なるVPCをターゲットグループに含めることができるのは非常に便利そうです。Kubernetesのアップグレードに活用しているユースケースもあるとのこと。

サービスネットワーク

サービスをグループ化するための抽象化レイヤー。サービスネットワーク内のサービスが相互通信できるわけではない。

認証ポリシー

サービスネットワーク上のIAMリソースポリシーであり、サービスとサービスネットワークに適用できる。

基本的にサービスネットワーク上でトラフィックを許可するポリシーを作成し、サービス上で別のポリシーを作成する。サービスネットワーク上で許可されていても、サービス上で許可されていなければ通信することはできない。

サービスネットワーク上に複雑なポリシーを配置しないことがベストプラクティス。ガードレールであり、多層防御であるため、人が読んですぐに理解できるポリシーにしておくことが望ましい。詳細なポリシーはサービス上に配置する。タグやリクエストするメソッド、クエリ文字列、パラメータの値といった内容を条件に指定できる。

サービスディレクトリ

アカウントで作成したサービスの単なるリスト。

VPC Latticeの機能と新機能

コア機能

VPC間、アカウント間の接続性
- CIDRの重複や、IPv4でもIPv6でもお構いなし
- AWS RAMによるアカウント間での共有
HTTP1.1, HTTP2.0, HTTPS, gRPCをサポート
パス, ヘッダー, メソッド, 重みでターゲットグループへの通信を分岐
IAMおよびセキュリティグループによるアクセス制御
インスタンス, Lambda, ALB, IPアドレスをターゲットタイプとしてサポート
- AWS Gateway API コントローラを利用することでネイティブEKSをサポート
- ALB/NLBを経由することでECSサービスでも利用可能

新機能

リージョン追加
- 現在、11リージョンで利用可能
- 東京リージョンで使えます、大阪リージョンは未だです
RAMを使用して個別のサービスを他のアカウントに共有可能
Shared VPCをサポート
VPCレベルのコンプライアンスとして以下をカバー
- SOC2, PCI, HIPAA, HITRUST, IRAPなど
Lambdaの新しいイベント構造をサポート
ID ヘッダーの伝播
AWS Gateway API コントローラのGA

カスタマーマネージドパーミッション

リソースを共有する際に、共有先のアカウントができるアクションを制限する機能。サービスネットワークにサービスを配置したり、VPCに関連付けたりすることを許可または拒否するなどの制御するのに、共有先のIAMロールやポリシーを変更する必要がない。

VPC Latticeの一般的な質問と回答

トラフィックの流れ

サービスのDNS名を生成
エンドポイントは常にVPC link-local アドレスになる
- link-localはサービスネットワークに関連付けられたVPCのみアクセス可能
トラフィックは自動的にVPC Latticeに送られる
- NACLおよびセキュリティグループでトラフィックが許可されていることが必要
サービスおよびサービスネットワークの認証ポリシーで許可されているかを検証する
リスナーおよびルールに基づく経路をターゲットグループにリクエストする
リクエストは健全なターゲットへ自動的に送られる

料金

セッションではバージニア料金でしたが、レポートでは東京リージョンに置き換えています。

時間料金 $0.0325/時間
- アタッチメント料金、エンドポイント料金はありません
- 10,000VPCと関連付けても、関連付けそのものは無料
処理データ料金 $0.0326/GB
リクエスト料金 $0.13/100万リクエスト

VPCは複数のサービスネットワークを使用できるか？

「いいえ」、ですがその必要がありません。サービスは複数のサービスネットワークに配置できるので、VPCではなくサービスとして複数のサービスネットワークに配置することで実現できる。

VPC Latticeはマイクロサービス専用か？

「いいえ」、モノリスでも利用可能ですし、モノリスからマイクロサービスへと部分的に移行するようなストラングラーフィグパターンにも利用可能。

VPC Latticeはサービスメッシュか？

サービスメッシュはコントロールプレーン（Istio, LinkerD, App Meshなど）とデータプレーン（Envoy, LinkerD, Nginxなど）です。VPC Latticeはサービスメッシュではないが、一部の機能は同じ。VPC LatticeはVPCに直接組み込まれており、コントロールプレーンとデータプレーンの両方がマネージドサービスです。サイドカープロキシはオプションで必須でありません。インスタンス、コンテナ、サーバーレスのすべてのワークロードで動作する。

アーキテクチャパターン

スモールスタート

単なるロードバランサー、単なるプロキシと同等。複雑さを軽減することで小規模ユーザーにも役立ちます。

マルチVPC

基本的に何も変わらない。VPC間の接続を導入する必要がないため、サブネットのルーティングが正しいかどうかということを心配する必要もない。

IPアドレス重複およびIPv6移行

IPアドレスについて考える必要はありません。一部のサービスでIPv6に移行する場合でも、IPv4との通信を心配する必要はありません。

Ingress

一元化されたVPCにELBやプロキシ、Network Firewall、WAFを配置し、VPC LatticeをIngressとして制御できます。グローバルアクセラレータを使って、マルチリージョンのIngressを実現することも出来る。

Serverless Ingress

API GatewayとLambdaプロキシを使ってサーバレスなIngressも実現できます。Lambdaプロキシではヘッダーの操作や認証などを行い、インターネットゲートウェイを持たないVPCでもIngressが出来ます。

所感

このセッションで初めてVPC Latticeに触れたのですが、非常に強力で柔軟なネットワークサービスであり、いろんなユースケースに対応できることが解るセッションでした。VPCピアリング、Trangit Gateway等のVPC間接続が無くとも、VPC Lattice経由でリクエストできたり、ターゲットグループとして複数のVPCに振り分けできるなど。利用方法次第で可能性を感じるサービスであることをあらためて認識することができました。

まだまだGAされたばかりのサービスですので、今後の発展も追いかけたいですね。