Amazon VPC Lattice

Amazon VPC Lattice は、複数の VPC やアカウントにまたがるアプリケーション同士の通信を、ネットワークの低レベルな設計を意識せずに接続・認可・観測できるようにするアプリケーションネットワーキングのサービスです。サービスという論理的な単位を中心に据え、それらを束ねるサービスネットワークを通じて、開発者とネットワーク管理者の双方が扱いやすい形でサービス間連携を実現します。

解決する課題

マイクロサービスやコンテナ、サーバーレスが普及するにつれ、アプリケーションは多数の小さなサービスに分割され、それらが複数の VPC やアカウントに分散して配置されるようになりました。従来のネットワーク構成では、これらをつなぐために次のような苦労がありました。

• VPC ピアリングや Transit Gateway で広く相互接続すると、IP アドレス範囲の重複に悩まされ、必要以上に広い到達性を許してしまう。
• サービスごとにロードバランサーやターゲットグループ、リスナールールを個別に設計・運用する必要があり、構成が肥大化する。
• アクセス制御がネットワーク層のセキュリティグループ中心になり、誰がどのサービスを呼べるかという認可を、アプリケーションのアイデンティティに基づいてきめ細かく管理しにくい。
• どのサービスがどのサービスを呼んでいるかという通信の可視化が難しく、トラブルシュートに時間がかかる。

VPC Lattice は、接続したい単位を「サービス」として抽象化し、それらをサービスネットワークにまとめて結びつけることでこれらを解決します。利用側はネットワークの詳細を意識せずにサービス名で相手を呼び出せ、管理側は認可ポリシーと観測を一元的に統制できます。

主要概念と用語

• サービス: 公開・利用される論理的なアプリケーション単位。リスナーとルールを持ち、背後にターゲットグループを紐づけて実体へトラフィックを振り分ける。独立した完全修飾ドメイン名が割り当てられる。
• サービスネットワーク: 複数のサービスと VPC を束ねる論理的なグループ。サービスを関連付けて公開し、VPC を関連付けることでその VPC 内のクライアントから利用できるようにする。認証ポリシーや監視をこの単位で集約できる。
• サービスディレクトリ: 自分が利用できるサービスやサービスネットワークの一覧を確認できる入口。アカウントをまたいで共有されたものも見える。
• ターゲットグループ: トラフィックの宛先となる実体の集合。EC2 インスタンス、IP アドレス、Lambda 関数、Application Load Balancer などを宛先として登録できる。
• リスナーとルール: サービスが受け付けるプロトコルとポート、およびパスやヘッダーに基づく転送ルールを定義する。これによりパスベースのルーティングなどを実現する。
• 認証ポリシー: サービスネットワークまたはサービスに付与する IAM ベースのポリシー。どのプリンシパルがどの操作を呼べるかをリクエスト単位で制御する。
• VPC の関連付け: クライアント側の VPC をサービスネットワークに結びつける操作。これによりその VPC からサービス群へ到達できるようになる。

仕様・制限・クォータ

VPC Lattice を設計するうえで把握しておきたい性質は次のとおりです。具体的な上限値はリージョンや時期で変わりうるため、定性的に理解し、正確な数値は公式ドキュメントとサービスクォータの画面で確認してください。

• サービスにはサービス専用の完全修飾ドメイン名が割り当てられ、クライアントはその名前を使って呼び出す。独自のカスタムドメイン名を割り当てることもできる。
• ターゲットには EC2 インスタンス、IP アドレス、Lambda 関数、Application Load Balancer を登録でき、サーバーレスからコンテナ、仮想サーバーまで混在した宛先を同じ枠組みで扱える。
• 主に HTTP や HTTPS、gRPC といったアプリケーション層のプロトコルを対象とする。任意の TCP や UDP を素通しする汎用的なネットワーク中継とは目的が異なる。
• 1 つのサービスネットワークに関連付けられるサービス数や VPC 数、アカウントあたりのサービスネットワーク数などにはアカウント単位のクォータがある。大規模構成では事前に見積もる。
• サービスネットワークと VPC、サービスの関連付けは、同一リージョン内で行うのが基本となる。
• アカウントをまたいだ共有には AWS Resource Access Manager を利用し、サービスネットワークやサービスを他アカウントへ共有して関連付けられる。

内部の仕組み

VPC Lattice の中心にあるのは、サービスとサービスネットワークという二つの抽象です。

サービスを提供する側は、実体となる EC2 インスタンスや Lambda 関数、IP アドレスをターゲットグループに登録し、サービスにリスナーとルールを定義します。これにより、受け付けるプロトコルやパスベースの転送が決まります。作成したサービスはサービスネットワークに関連付けて公開します。

利用する側は、自分の VPC をそのサービスネットワークに関連付けます。すると、その VPC 内のクライアントは、サービスに割り当てられたドメイン名に対して通常のアプリケーション通信を行うだけで、相手のサービスへ到達できます。トラフィックはマネージドなデータプレーンによって運ばれ、利用者はロードバランサーやルートテーブル、ピアリングといった低レベルな構成を自分で組む必要がありません。VPC やアカウントの境界を越えても、サービス名を入口とする一貫した接続体験が保たれます。

この経路では、サービスネットワークやサービスに付与した認証ポリシーが評価され、呼び出し元のプリンシパルがそのサービスを呼んでよいかがリクエストごとに判定されます。あわせて、サービスネットワーク単位でアクセスログやメトリクスが収集されるため、どのクライアントがどのサービスをどれだけ呼んだかを観測できます。接続・認可・観測という三つの関心事が、同じサービスネットワークという面の上で統一的に扱われるのが、このサービスの本質です。

設計パターン / ベストプラクティス

• サービスネットワークを統制の境界として使う: チームや環境、用途ごとにサービスネットワークを分け、その単位で認証ポリシーと観測を集約する。これにより、どのサービス群がどのポリシーで守られているかを把握しやすくする。
• アカウント横断は Resource Access Manager で共有する: 複数アカウントにまたがる組織では、サービスネットワークを共有して各アカウントの VPC を関連付け、組織全体で一貫したサービス連携を実現する。
• 異種の実体を同じ枠組みでつなぐ: EC2、Lambda、コンテナ背後の Application Load Balancer を同じサービスの宛先として混在させ、移行や段階的な置き換えを通信側の変更なしで進める。
• IP 重複に悩まない設計に寄せる: VPC ピアリングで広くつなぐ代わりに、必要なサービスだけをサービスネットワーク経由で持ち込み、CIDR の重複や過剰な到達性を避ける。
• ゼロトラストに近づける: ネットワーク層の到達性だけに頼らず、認証ポリシーでアプリケーションのアイデンティティに基づく認可をかけ、最小権限のサービス間呼び出しにする。

運用・監視

• アクセスログの活用: サービスネットワークやサービスのアクセスログを有効にし、CloudWatch Logs や S3 などへ出力する。どのクライアントがどのサービスを呼んだかを記録し、トラブルシュートや監査に役立てる。
• メトリクスとアラーム: リクエスト数やエラー、応答時間に関するメトリクスを CloudWatch で監視し、異常時にアラームを上げる。サービス単位での健全性を継続的に把握する。
• 接続性の確認: VPC の関連付けやサービスの関連付けの状態を確認し、到達できない事象が関連付けの不足や認証ポリシーの拒否のどちらに起因するかを切り分ける。
• 構成のコード化: サービス、ターゲットグループ、リスナー、認証ポリシー、関連付けを Infrastructure as Code で管理し、意図しない公開範囲やポリシーの変更を検知できるようにする。

コスト

VPC Lattice の料金は、おおむね次の要素で構成されます。具体的な単価はリージョンや時期で変動するため、最新の料金ページで確認してください。

• サービスの稼働料金: 作成したサービスの数や稼働時間に応じた料金が発生する。
• データ処理料金: サービスネットワークを通過して処理されたリクエストやデータ量に応じた料金がかかる。
• 設計上の考慮: 使われていないサービスやサービスネットワークを放置すると、地味なコスト要因になりやすい。一方で、サービスごとに個別のロードバランサーを多数運用していた構成を集約できれば、全体としての運用負荷とコストを下げられる場合がある。

セキュリティ

• IAM ベースの認可: サービスネットワークやサービスに認証ポリシーを付与し、どのプリンシパルがどのサービスをどのメソッドで呼べるかをリクエスト単位で制御する。これが VPC Lattice のセキュリティの中核である。
• 認証方式の選択: 認証なし、または IAM による認証を選べる。IAM 認証では署名付きリクエストとして呼び出し元のアイデンティティを検証する。
• 多層防御: 認証ポリシーによるアプリ層の認可に加え、関連付ける VPC やセキュリティグループによるネットワーク層の制御を組み合わせ、到達性と認可の両面で絞り込む。
• アカウント間共有の統制: Resource Access Manager で共有する範囲を明示し、意図しないアカウントからの関連付けを防ぐ。
• 転送中の暗号化: アプリケーション層の TLS など、転送中の暗号化を適切に設定し、経路を保護する。

Well-Architected の観点

運用上の優秀性の柱とセキュリティの柱の観点が中心です。運用面では、接続・認可・観測をサービスネットワークという単一の面で扱えるため、サービスが増えても運用の複雑さを抑えやすく、可視化によって問題の切り分けが速くなります。セキュリティ面では、IAM ベースの認証ポリシーによってアプリケーションのアイデンティティに基づく最小権限の認可を実現でき、ネットワーク層の到達性だけに依存しないゼロトラストに近い設計へ寄せられます。あわせて、信頼性の柱の観点では異種の宛先を同じ枠組みで扱える柔軟性が、コスト最適化の柱の観点では個別ロードバランサーの集約と未使用構成の棚卸しが関係します。

試験で問われるポイント

関連サービス・比較

サービス単位の接続という点で AWS PrivateLink としばしば比較されます。閉域でのサービス提供・利用に主眼があるなら PrivateLink、複数 VPC やアカウントにまたがるサービス群の接続・認可・観測を一元化したいなら VPC Lattice が向きます。

ハンズオン / CLI例

次は、サービスネットワークを作成し、サービスを関連付け、クライアント側 VPC を関連付ける基本的な流れの例です。識別子やリージョンは自分の環境の値に置き換えてください。

# サービスネットワークを作成する。認証方式は IAM を指定する
aws vpc-lattice create-service-network \
  --name my-service-network \
  --auth-type AWS_IAM

# サービスを作成する。後でリスナーやターゲットグループを紐づける
aws vpc-lattice create-service \
  --name my-service \
  --auth-type AWS_IAM

# サービスをサービスネットワークに関連付けて公開する
aws vpc-lattice create-service-network-service-association \
  --service-network-identifier sn-0123456789abcdef0 \
  --service-identifier svc-0123456789abcdef0

# クライアント側 VPC をサービスネットワークに関連付ける
aws vpc-lattice create-service-network-vpc-association \
  --service-network-identifier sn-0123456789abcdef0 \
  --vpc-identifier vpc-0123456789abcdef0 \
  --security-group-ids sg-0123456789abcdef0

# 関連付けの状態を確認する
aws vpc-lattice list-service-network-vpc-associations \
  --service-network-identifier sn-0123456789abcdef0