当エントリは弊社AWS事業本部による『AWS 入門ブログリレー 2024』の23日目のエントリです。
このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。
AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2024 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。
では、さっそくいってみましょう。今回のテーマは『Amazon VPC Lattice』です。
VPC Latticeの概要
VPC LatticeはVPC向けのリバースプロキシサービスで、VPCを跨いだ通信を可能にするサービスです。
HTTP、HTTPS、gRPCに対応しており、利用側のVPCと提供側のVPCのCIDRが重複していてもアクセスができるようになっています。
またクロスアカウントでの接続も構築することができます。但しリージョンを跨ぐ通信に関してはLatticeでは対応できませんのでAWS Transit Gatewayなどの他サービスをご検討ください。
VPC Latticeの主要コンポーネント
主要なコンポーネントとしてはサービスネットワーク、サービス、ターゲットグループの3つになります。
これらのコンポーネントを関連づけることによってサービスネットワークに関連付けたVPC内のリソースからターゲットグループにあるリソースに対してアクセスを行えるようになります。ターゲットグループにあるリソースからサービスネットワークに関連付けたVPC内のリソースに対してリクエストを送ることはできず一方向の通信となっています。
サービスネットワーク
まずサービスネットワークから見ていきたいと思います。
サービスネットワークはVPCとサービスを結びつけるハブの役割を果たします。
サービスネットワーク1つあたりVPCとサービスそれぞれ500個まで関連付けることが可能です。（引き上げ可能なソフトリミット）
一方VPCからは1つのサービスネットワークにしか関連付けを行えません。VPCに対して複数のサービスネットワークを関連付けることはできませんので、1つのサービスネットワークに必要なサービスを関連づけるようにしてください。
また後述するサキュリティの設定、ログの設定を行うことができます。
サービス
続いてサービスを見ていきます。
VPC内のリソースからアクセス対象となるリソースがこのサービスになります。アクセスを行う際はこのサービスに設定されるドメインに対してアクセスを行うこととなります。サービスはALBとよく似たリソースとなっており、リスナーを定義しルールに従ってそれぞれのアクションに振り分けを行います。但しALBと異なる点として、アクションには後述するターゲットグループか404の固定レスポンスのみしか設定を行うことができません。
このドメインについては、サービスの作成時に限りますがカスタムドメインの設定が可能です。
カスタムドメインの設定方法に関しては以下ブログがわかりやすかったのでご参照ください。
デフォルトドメインを利用する場合においても、Latticeによって生成された証明書を利用することができますので、特に意識することなくHTTPS通信が可能になっています。
またサービスネットワークと同様に後述するサキュリティの設定、ログの設定行うことができます。
ターゲットグループ
最後にターゲットグループを見ていきます。
ターゲットグループではサービスのリスナーに設定する転送ルールのアクション先を設定していきます。
この辺りもALBとよく似た仕組みとなっております。
ターゲットグループの対象にできるリソースは以下になります。
- インスタンス
- IP
- Lambda
- Internal ALB
詳細の条件に関しては以下のドキュメントをご参照ください。
プロトコルバージョンとしては以下から選択できます。
- HTTP/1.1
- HTTP/2
- gRPC
ターゲットグループに登録を行ったリソースに関しては、通信を行うプロトコルに対してセキュリティグループのインバウンドルールの許可が必要になります。
この際にインバウンドルールの許可は、通信元となるリソースに対してではなくLatticeのプレフィックスリストに対して許可が必要になりますので注意が必要です。
セキュリティグループの設定に関しては以下のブログで解説されておりますので、ご参照ください。
セキュリティについて
Latticeのセキュリティについてですが、多層で制御を行えるようになっております。
ドキュメントでも以下のように言及されています。
VPC Lattice は、複数のネットワークレイヤーに防御戦略を実装するために使用できるフレームワークを提供します。最初のレイヤーはサービスと VPC の関連付けです。VPC とサービスとの関連付けがなければ、クライアントはサービスにアクセスできません。2 番目のレイヤーでは、VPC とサービスネットワーク間の関連付けにセキュリティグループをアタッチできます。3 番目と 4 番目のレイヤーは認証ポリシーで、サービスネットワークレベルおよびサービスレベルで個別に適用できます。
これらレイヤーについてそれぞれ説明します。
サービスとVPCの関連付け
まず最初のレイヤーと位置付けられているサービスとVPCの関連付けについて確認していきたいと思います。
このサービスとVPCの関連付けについてですが、サービスネットワークで設定できる内容となっております。この内容について確認していきます。
まずVPCとサービスネットワークが関連付けられていなければ、VPC内のリソースからターゲットグループに設定されているリソースにはアクセスを行えません。
同様にサービスネットワークとサービスが関連付けられていなければ、VPC内のリソースからターゲットグループに設定されているリソースにはアクセスを行えません。
このように関連付けをしないという選択をすることによって、接続経路を絞り込むことができます。
1対1の例では分かりにくいので、1対2で考えてみます。
今回の利用者側VPCからサービスAの配下に設定されているターゲットグループAのリソースにのみ経路が必要であるといった場合には、サービスネットワークとサービスAのみに関連付けを設定することでサービスBの配下に設定されているターゲットグループBにはアクセスできないといった形で経路の絞り込みが可能です。
この関連付けをするしないを選択することによって、簡単に接続先を限定することができます。
セキュリティグループ
サービスネットワークとVPCとの関連付け毎にセキュリティグループの設定を行うことが可能です。
セキュリティグループを設定することでVPC内でLatticeにアクセスできるリソースの絞りこみが行えます。
サービスネットワークとVPC間でのアクセスの制御となるので、サービス毎のアクセス制御ができないことに注意してください。
認証ポリシー
認証ポリシーとしてIAM認証をサービスネットワークとサービスのそれぞれに設定を行うことができます。
サービスネットワークとサービスのどちらにも設定しておくことができますし、片方のみに配置することもできます。サービスネットワークとサービスのどちらにも設定した場合、どちらの認証も許可されることで通信が許可されます。
すなわちどちらかの認証に失敗した場合は通信が許可されません。
片方のみに設定した場合は、設定されていない箇所は自動的に全て許可されるため設定したポリシーが許可されれば通信が許可されます。
ポリシーの設定に関しては、サービスネットワークにはガードレールのみを設定しサービス毎に細かい制御ルールを定義することが推奨されております。
またIAM認証を利用することで、サービスとVPCの関連付けやセキュリティグループで実現できなかった以下のような細かい制御を実現することが可能です。
IAM認証を行う際は基本的にクライアント側でSigV4署名を行う必要があります。詳細な条件については以下をご参照ください。
IAM認証の設定については以下ブログで検証しておりますのでご参照ください。
セキュリティを踏まえたLatticeの設計方針例
先ほど紹介したセキュリティの各レイヤーを踏まえた上での設計方針例を2つご紹介させていただきます。
サービスとVPCの関連付けを活かした設計例
まずサービスとVPCの関連付けを活かした設計例をご紹介します。
VPC内の特定のリソースにのみ特定のサービスへアクセスを行うなどの要件がある場合にはこちらの設計では実現できませんので、IAM認証を活かした設計例をご参照ください。
こちらの設計では共用をあまり行わない小さなサービスネットワークを目指すことになります。
以下のように基本的にVPCと1対1となるようにサービスネットワークを作成していきます。そのVPCからアクセスを行う必要のあるサービスに紐付けを行うことでアクセスを制御していきます。
またVPC内のリソースでLatticeにアクセスの制御が必要な時はセキュリティグループを活用することができます。
- メリット
- 経路の限定が関連付けのみとなるので容易で分かりやすい
- IAM認証の設定による、署名の付与などのアプリ側の改修が不要
- デメリット
- サービスネットワークを数多く作成することになるので、責任分界点を決めにくい
- アクセスする側のVPC内の各リソースから特定のサービスに対してのみアクセス可能にするなどの細かい制御ができない
IAM認証を活かした設計例
次にIAM認証を活かした設計例を活かした設計例をご紹介します。
こちらの設計では共用を行う大きなサービスネットワークを目指すことになります。
以下のようにサービスネットワークはネットワーク管理アカウントに配置してハブのように利用します。サービス毎にポリシーを設定しアクセスの制御を行います。
- メリット
- サービスネットワークを集中管理することができ、責任分界点を明確にしやすい
- 特定のリソースにのみ特定のサービスのアクセスを許可するなど細やかな制御ができる
- デメリット
- 一部のリソースの指定方法を除きSigV4署名を行う必要がある
- 大規模になればなるほどサービス側に定義する、IAM認証のポリシーが複雑になる
ログについて
ログの取得はサービスネットワークとサービスにて設定が可能です。
配信先はS3、CloudWatch Logs、Kinesis Data Firehoseの3つから選択することができます。
組織内でS3バケットにログ集約する方法については以下ブログで検証しておりますのでご参照ください。
ログで取得できる項目はサービスネットワークでもサービスでも同一となっておりまして以下項目が取得できます。
{
"hostHeader": "example.com",
"sslCipher": "-",
"serviceNetworkArn": "arn:aws:vpc-lattice:us-west-2:123456789012:servicenetwork/svn-1a2b3c4d",
"resolvedUser": "Unknown",
"authDeniedReason": "null",
"requestMethod": "GET",
"targetGroupArn": "arn:aws:vpc-lattice:us-west-2:123456789012:targetgroup/tg-1a2b3c4d",
"tlsVersion": "-",
"userAgent": "-",
"serverNameIndication": "-",
"destinationVpcId": "vpc-0abcdef1234567890",
"sourceIpPort": "178.0.181.150:80",
"targetIpPort": "131.31.44.176:80",
"serviceArn": "arn:aws:vpc-lattice:us-west-2:123456789012:service/svc-1a2b3c4d",
"sourceVpcId": "vpc-0abcdef1234567890",
"requestPath": "/billing",
"startTime": "2023-07-28T20:48:45Z",
"protocol": "HTTP/1.1",
"responseCode": 200,
"bytesReceived": 42,
"bytesSent": 42,
"duration": 375,
"requestToTargetDuration": 1,
"responseFromTargetDuration": 1,
"grpcResponseCode": 1
}クロスアカウントの接続に関して
VPC LatticeはRAMを利用して、サービスネットワークもしくはサービスを共有することによってクロスアカウントで接続を確立することができます。
LatticeのリソースをRAMで共有する際には。設定している内容などは変更することができず関連付けのみ権限を許可ができるようになっております。
関連付けの範囲について、それぞれ異なりますので整理します。
サービスを共有する場合
サービスの共有を行う場合については、以下のアクションが設定可能です。
- vpc-lattice:CreateServiceNetworkServiceAssociation（サービスネットワークとサービスの関連付け）
サービスの共有を行う場合においてはサービスネットワークとの関連付けのみが可能となっております。
サービスとクロスアカウントでのターゲットグループの登録は行うことができませんので、サービスとターゲットグループは同じアカウント内に存在させる必要があります。
サービスネットワークを共有する場合
サービスネットワークの共有を行う場合、以下のアクションが設定可能です。
- vpc-lattice:CreateServiceNetworkServiceAssociation（サービスネットワークとサービスの関連付け）
- vpc-lattice:CreateServiceNetworkVpcAssociation（サービスネットワークとVPCの関連付け）
サービスネットワークを共有する場合においては、サービスとの関連付けとVPCの関連付けが可能となります。
デフォルトの設定であるマネージド型アクセス許可を利用するとこの2つのアクションを許可することとなります。
サービスネットワークを共有する場合においては、２種類の関連付けが行えますので想定外の関連付けが行われないように注意が必要です。特にサービスを関連付ける想定でサービスネットワークの共有を行なっている場合についてはカスタマー管理アクセス許可を設定してサービスの関連付けのみを許可するように設定することを推奨します。
想定しないVPCの関連付けを許可することとなりサービスネットワークもしくはサービスにおいて適切にIAM認証を設定していない場合、関連付けを行ったVPCからサービスネットワークに関連付けされている各サービスにアクセスが可能となってしまいます。
カスタマー管理アクセス許可については以下ブログでまとめておりますのでご参照ください。
料金
2024年4月16日現在の東京リージョンの料金を記載します。最新の料金は以下をご確認ください。
料金は構築されているサービスの数とサービスが処理したデータ量とリクエスト数に応じて発生します。
固定部分
固定の料金として、サービスが構築されている時間に応じて課金されます。
東京リージョンでは、0.0325USD/hの料金が発生します。
１ヶ月（30日）継続して構築を行うと23.4USDの費用が発生します。
サービスネットワークは構築に応じた料金は発生しません。
変動部分
変動部分の料金として、サービスが処理したデータ量とリクエスト数によって課金されます。
サービスが処理したデータ量はサービスが受け取るリクエストのデータ量と、サービスが送信するレスポンスのデータ量を加算した値が課金の対象となります。
東京リージョンでは、0.0325USD/GBの料金が発生します。
100GBのデータ量をサービスで処理すると、3.25USDの費用が発生します。
リクエスト数はサービスの受け取ったリクエスト数が課金の対象となります。1時間あたり30万リクエストまでは無料となっておりますので、1時間あたり30万リクエストを超過すると課金が発生します。
東京リージョンでは、0.13USD/100万リクエスト料金が発生します。
1時間で130万のリクエストがある場合には、0.13USDの費用が発生します。
終わりに
以上、『AWS 入門ブログリレー 2024』の2日目のエントリ『Amazon VPC Lattice』編でした。 次回、4/17は弊社おのやんによる「Amazon EC2 Auto Scaling」編の予定です！
1
