VPC Lattice クロスアカウント接続に必要な要素を図解してみた
VPC Lattice を利用したクロスアカウント接続の構成を考える機会がありました。VPC Lattice の構成要素の理解に時間がかかったのでわかる範囲で絵に書いて整理しました。
VPC Lattice のクロスアカウント接続について
VPC Lattice は異なる AWS アカウント上の VPC 間の HTTP/HTTPS アクセスを簡単に実現できるサービスです。同じ AWS アカウント内でも利用可能ですが、本記事では主にクロスアカウント接続について触れます。
別アカウントにある VPC または、同アカウントの VPC 内にあるバックエンドの API を叩きたいようなユースケースにおいてはネットワーク構成を意識することなく構築できるのが利点です。VPC Lattice で経由で通信する VPC のネットワーク間は CIDR の範囲が重複していても問題ありません。
とくにアプリケーション開発者の方には嬉しい接続方法なのではないかと思います。
HTTP/HTTPS アクセスに限定すれば従来 VPC Peering 、PrivateLink や Trangit Gateway で設計していたところに加えて VPC Lattice も新たな接続候補となるサービスです。
クロスアカウント接続のユースケース
VPC Lattice のローンチパートナー Kong の事例が興味深かったので紹介します。
マルチアカウント構成でも本番、開発、ステージングの様な環境毎の構成が一般的だと思いますが、こちらの構成はマイクロサービス化が極まっておりバックエンドのサービス毎にアカウントを分離した構成をとっています。
構成図に私なりの簡単な説明を付けておきます。
- Kong Gateway というゲートウェイのシステムが1つの AWS アカウント上にあり、エンドユーザーからのリクエスト受け付ける
- バックエンドサービスは別々の AWS アカウントで稼働しており VPC Lattice 経由で各アカウントのバックエンドサービスへアクセスする
画像引用: Kong Enterprise & Kong Konnect with Amazon VPC Lattice | Kong Inc.
馴染みのある AWS のアイコンに置き換えてみるとこの様なイメージです。VPC Lattice は gRPC にも対応しているため、アプリケーションのサービス間通信向けのサービスであることがわかります。
昨今は AWS のマルチアカウント戦略を取ることが多くなってきましたけど、バックエンドのサービス単位でアカウントを分離しているのは興味深かかったです。ここまでのアカウント分割が必要になるのかは"何に重きを置くか"によりますが、HTTP/HTTPS で API を呼び出すだけであればネットワーク設計などの手間になる部分を VPC Lattice が抽象化してくれます。そのため、バックエンドのサービス単位の様に細かな粒度でマルチアカウント設計が必要なときには VPC Lattice が役立つことはユースケースを確認して理解できました。
VPC Lattice のクロスアカウント接続のユースケースを確認したところで、VPC Lattice のコンポーネントをもう少し詳しくみていきましょう。
クロスアカウント接続で必要な要素を学ぶ
VPC Lattice を構成するコンポーネントを理解するために簡単なクロスアカウント接続環境を作成してみてわかったことをまとめます。今回 VPC Lattice の認証機能までは検証できていないため、その部分の説明は除きます。認証についての説明は別の機会に検証して紹介したいと思います。
検証環境
VPC Lattice を利用して別アカウントにある Internal ALB へリクエストして、Internal ALB配下にある VPC Lambda からのレスポンスを受け取れるか検証しました。NAT Gateway は配置せず、インターネットから閉じられた環境にしています。EC2 から Internal ALB へテストでリクエストを送るために、VPC エンドポイントを利用してセッションマネージャーでリモート接続する構成です。
実際構成を作ってみて VPC Lattice の関連リソースを図に表すとこうなりました。簡単な説明は後述しますのでこんな感じという雰囲気だけ掴んでいただければ充分です。 VPC Lattice Service Networkか、VPC Lattice Service をどちらを共有してもクロスアカウント接続はできるのですが今回は VPC Lattice Service を共有するかたちで動作検証を行っています。
VPC Lattice のコンポーネント
VPC Lattice を構成するコンポーネントは3つあります。
- VPC Lattice Service Network
- VPC Lattice Service
- Target Group
各コンポーネントの役割を図解して紹介します。各コンポーネントの関係性の都合、内容を把握する順番は3番のターゲットグループからはじまり、最後にサービスネットワークを把握すると理解しやすいと思いますのでこの順番で用語解説を進めます。
VPC Lattice 関連用語
Target Group
VPC Lattice 経由してアクセスしたい対象のリソースの登録を行うコンポーネントです。
登録するとターゲットグループという名称で VPC Lattice 内で管理されます。現在アクセス対象として指定可能なリソースは EC2 インスタンス、Lambda、ALB と IP アドレスです。
設定項目はシンプルでアクセス対象のリソースと、プロトコル（HTTP or HTTPS）とポート番号（通常は80か、443）、それとプロトコルのバージョンを HTTP1、HTTP2、gRPC を選択するだけとなっています。
ターゲットグループ単体では機能せず後述する VPC Lattice Service と組み合わせて利用します。
VPC Lattice Service
VPC Lattice 経由でアクセスするときのアクセス先（ドメイン名）が VPC Lattice Serviceにあたり、ターゲットグループを VPC Lattice Service に登録して利用されます。
ターゲットグループで指定したリソース、ここの例では Internal ALB へ VPC Lattice 経由してアクセスを実現するためには VPC Lattice Service を1つ作成し、Internal ALB へのターゲットグループを登録します。
VPC Lattice Service に対して HTTPか、HTTPS のプロトコルと、任意のポートの組み合わせでリクエスト受け付けたとき、どのターゲットグループへリクエストを転送するのかルーティング設定を行うリスナーという設定があります。
作成した VPC Lattice Service 毎にドメイン名が割り当てられ、VPC Lattice を経由して Internal ALB へアクセスするときのリクエスト先が VPC Lattice Service のドメイン名（URL）になります。デフォルトは VPC Lattice Service から払い出されるドメイン名（hoge.vpc-lattice-svcs.ap-northeast-1.on.aws）ですが、独自のドメイン名（カスタムドメイン）を割り当てることもできます。
モニタリング設定
VPC Lattice Service に対するすべてのリクエストと、レスポンスのアクセスログを取得できます。
アクセスログの保存先は以下のいずれかに保存できます。
- CloudWatch Logs
- S3
- Kinesis Firehose
デフォルト設定はアクセスログの取得は無効になっています。
VPC Lattice Service アクセス設定（認証タイプ）
VPC Lattice Service に対するアクセス設定は、デフォルトの認証なしタイプと、認証と許可を設定できる AWS IAM タイプの2種類あります。
認証タイプの AWS IAM については未検証のため説明は控えます。
Edit access settings for the service - Amazon VPC Lattice
VPC Lattice Service Network
VPC Lattice Service Network は VPC と VPC Lattice Service の関連付けを行いリソース間の接続を中継してくれるハブです。
関連付けの制約事項
VPC と VPC Lattice Service Network の関連付けには制約があります。
- 1つの VPC は1つの VPC Lattice Network Service としか関連付けられません（1:1）
VPC Lattice Service との関連付けには制約はなく、複数の VPC Lattice Service Network と関連付けができます（1:n）
VPC Lattice Security Network のセキュリティグループ
VPC と関連付ける際にセキュリティグループを指定する必要があります。
VPC 内のリソースから VPC Lattice を経由する VPC Lattice Service へのアクセスを制限できます。
たとえば以下の様な構成で VPC Lattice を経由してバックエンドの API を提供する Internal ALB へ左側の ECS Farget のタスク（クライアント）からアクセスするとします。このとき2箇所のセキュリティグループで通信が許可されていないと Internal ALB へアクセスができないです。
一方はここで紹介した VPC Lattice Service Network のセキュリティグループ、もう片方は Internal ALB のセキュリティグループにインバウンルールに許可を追加しないといけないです。
このケースですと ALB 側で許可しないといけないソース IP にあたるものは VPC Lattice のマネージドプレフィックリストからになります。アクセス対象のリソース側のセキュリティグループの設定は見落としがちな気がします。
紛らわしいのですがセキュリティグループとは別に後述するアクセス設定（認証タイプ）の制限もあります。
モニタリング設定
VPC Lattice Service と同様です。VPC Lattice Service Networkに対するすべてのリクエストと、レスポンスのアクセスログを取得できます。
アクセスログの保存先は以下のいずれかに保存できます。
- CloudWatch Logs
- S3
- Kinesis Firehose
デフォルト設定はアクセスログの取得は無効になっています。
VPC Lattice Service Network アクセス設定（認証タイプ）
VPC Lattice Service 同様に VPC Lattice Service Network にもアクセス設定があります。デフォルトの認証なしタイプと、認証と許可を設定できる AWS IAM タイプの2種類あります。
認証タイプの AWS IAM については未検証のため説明は控えます。
Edit access settings for the service network - Amazon VPC Lattice
その他
ルートテーブルへルートが自動追加
VPC Lattice Service Network に関連付けられた VPC と、VPC Lattice Service に登録されたターゲットグループにあるリソースの VPC のルートテーブルには VPC Lattice 用のルートが自動的に追加されます。
VPC を関連付けた VPC のサブネットのルートテーブルの例
VPC Lattice Service に関連付けたターゲットグループ（Internal ALB）のある VPC のサブネットのルートテーブルの例
VPC はパブリックサブネット、プライベートサブネットがあり、パブリック用、プライベート用のルートテーブルを作成していました。ルートテーブルへのルート追加は VPC 内のすべてのサブネットに紐付いているルートテーブルへルートの追加されていました。
ネットワークを意識しなくて済む点はアプリケーション開発者からみると嬉しいのではないでしょうか。
クロスアカウント接続時の構成
Resource Access Manager は VPC Lattice のコンポーネントではありませんが、クロスアカウント接続時には VPC Lattice のリソースの共有をすることになります。
VPC Lattice で他アカウントへ共有可能なリソースは以下の2つです。
- VPC Lattice Service Network
- VPC Lattice Service
実際に共有したときの構成を検討してみます。
VPC Lattice Service Network を共有した場合
別のアカウントの VPC を関連付けるために VPC Lattice Service Network を共有する構成です。例示したシンプルな構成ですと VPC Lattice 関連リソースが1つのアカウントにまとまります。
仮に VPC lattice Service が他のアカウントにもある場合は、他のアカウントから VPC Lattice Service を VPC Lattice Service Network のあるアカウントへ共有してもらうことになります。その場合は VPC Lattice のリソースが1つのアカウントにすべてある構成ではなくなります。1つのアカウントに VPC Lattice リソースをすべて作成するのは管理上、好ましいの好ましないのかはさておきですけども。
VPC Lattice Service を共有した場合
VPC Lattice Service を他のアカウントへ共有して、他のアカウント側の VPC Lattice Service Network へ関連付けたパターンです。VPC Lattice Service が1つしかなくても VPC Lattice 関連リソースが複数アカウントに存在することになります。
1つの VPC は1つの VPC Lattice Service Network にしか関連付けられないという制約があります。今後拡張していった際に VPC Lattice Service Network が乱立するとと、VPC Lattice 経由で通信したいのにできないこともありうると思います。
構成を検討して思うこと
複数の VPC Lattice Service が複数のアカウントに存在するのかどうかでなにをどこへ共有すると管理しやすいのかが変わってくることがわかりました。
AWS ブログで紹介されている構成は VPC Lattice Service Network を独立した1つのアカウントで管理する構成をとっています。VPC と VPC Lattice Service Network の関連付けの制約上、VPC Lattice Service が複数のアカウントに存在するときはこの構成が管理しやすい感じがします。
VPC Lattice 経由でアクセスしたい API サービスのあるアカウントは？今後 VPC Lattice Service は同じアカウントで増えていくのか、他のアカウントで増えていくのか？このあたりの将来の構想を踏まえての設計は重要ですね。
初見では VPC Lattice Service Network を独立したアカウントに配置する利点がわからなかったのですが、自分で共有するリソースをあれこれ検討してみたところ「なるほど、気持ちはわかるぞ」と納得感がありました。
あとは VPC と Target Group のある VPC 間通信で CIDR が重複していても問題ないため、既存の VPC 間の通信の課題を解消できる可能性を秘めています。
VPC Lattice の登場により複数アカウント、複数の VPC、言い方は悪いですが無計画なネットワーク設計で量産された同じ CIDR の VPC も HTTP/HTTPS 通信であれば簡単に接続できるようになりました。一度学んでみると設計の幅が広がりますのでまとまった時間で手を動かしてみてはいかがでしょうか。
最後に VPC Lattice のクォータも把握しておきましょう。
