[技術検証] VPC Lattice（格子）を使って検証してみました

概要

VPC Lattice（ラティス：格子）とは、一言で言うとVPCを跨いだALBでリバースプロキシするようなもの
VPC LatticeがついにGAしたため、その機能を検証する。
VPC格子って何？って方はVPC Lattice のよくある質問参照

目的・やりたいこと

1.こちらのAWSブログの検証内容でまず同一サービス間の異なるVPC間のEC2とLambdaのロードバランシングの練習
2.同じIPレンジを持っているVPCを跨げるか

対象となる技術

VPC Lattice
サービスネットワーク
サービス
ターゲットグループ

条件（導入にあたって前提事項）

通信用のインスタンスやLambda関数を用意する

注意事項

サポートされているプロトコルは、HTTP/1.1、HTTP/2、および gRPC で、TLS 対応サービス用の HTTPS を含む。

作業の流れ

概要図

事前準備

EC2（EC2-Aとします）

Linuxでpython環境を整備し、以下のスクリプトを実行して8080でWebサービスを待ち受ける。

from flask import Flask
app = Flask(__name__)

@app.route('/')
def index():
  return 'Hello from the instance'

@app.route('/<path>')
def somePath(path):
  return 'Hello from the instance at path "{}"'.format(path)

app.run(host='0.0.0.0', port=8080)

もう1つEC2（EC2-Bとします）

既存のEC2-Aとは別のVPCに同じプライベートサブネットアドレス帯のEC2 インスタンスEC2-Bを用意する。

Lambda関数

Node.js 18.x ランタイムを使用して以下の単純な関数を作成する。

exports.handler = async (event) => {
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from the function'),
    };
    return response;
};

ところがこれがトラップで、このまま保存しようとすると、Lambda関数の権限が足りないというエラーが出て保存できない。
Lambda で「The provided execution role does not have permissions to call CreateNetworkInterface on EC2」になったときの対処方法に従い、LambdaのロールにAWSLambdaVPCAccessExecutionRoleポリシーを直接追加して無事解決

次に、このLambda関数にアクセスすると以下エラーが

$ curl https://nozaki-service-0df31e742a9335c8f.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws
{"errorType":"ReferenceError","errorMessage":"exports is not defined in ES module scope","trace":["ReferenceError: exports is not defined in ES module scope","    at file:///var/task/index.mjs:1:1","    at ModuleJob.run (node:internal/modules/esm/module_job:194:25)"]}

こちらはexports is not defined in ES module scope AWS Lambdaに従い、index.jsの最初の「exports.handler」を「export const handler」に変えたら解消された。

検証1　同一サービス間の異なるVPC間のEC2とLambdaのロードバランシング

1.ターゲットグループの作成
EC2 インスタンス用と Lambda 関数用の 2 つのターゲットグループを作成します。ナビゲーションペインのVPC 格子から [ターゲットグループ]を選択し、次に[ターゲットグループの作成] を選択します。

最初のターゲットグループには、 [インスタンス]ターゲットタイプを選択し、名前を入力します。

インスタンスで実行されている Web アプリが使用するプロトコル ( HTTP ) とポート ( 8080 ) を選択します。インスタンスが実行されている VPC とプロトコルバージョン ( HTTP1 ) を選択します。
ここで、プロトコルはHTTP /HTTPSしか選択できませんでした。つまり利用できるサービスはL7のHTTP(S)に限られるということ

2．ターゲットの登録
リストから Web アプリが実行されているインスタンスを選択し、それを含めます。

この時、ちゃんと「Include as pending below」を選択し、下の「Review targets」にターゲットが表示されていることまで確認すること

するとプライベートサブネットのルーティングテーブルに、いつの間にかVpcLatticeの経路が追加されている

3．もう1つのターゲットグループの作成
同様に、Lambda 関数のターゲットグループを作成します。今回は一覧から関数を選択します。使用する関数バージョンまたは関数エイリアスを選択できます。$LATESTバージョンを使用します。

4．VPC Latticeサービスの作成
ターゲットグループの準備ができたので、VPC格子ナビゲーションペインで[サービス]を選択し、次に[サービスの作成] を選択します。名前を入力します。

5．認証タイプを選択
[なし]を選択すると、サービスネットワークはクライアントアクセスを認証せず、認証ポリシーが存在する場合は使用されません。
[AWS IAM]を選択すると、 [ポリシーテンプレートの適用]ドロップダウンから、認証済みアクセスと非認証アクセスの両方を許可するテンプレートを選択できます。

6．サービスのルーティングを定義
Add listenerを選択します。プロトコルについては、HTTPSを使用してリッスンするようにサービスを構成します。デフォルトアクションでは、リクエストの 3 分の 2 ( Weight 2 ) をインスタンスターゲットグループに送信し、3 分の 1 ( Weight 1 ) を関数ターゲットグループに送信することを選択します。

7． 2 つのルールを追加
最初のルール ( Priority 1 ) は、パスが /to-instance インスタンスターゲットグループにあるすべてのリクエストを送信します。
2 番目のルール ( Priority 2 ) は、パスが /to-function 機能ターゲットグループにあるすべてのトラフィックを送信します。

8．サービスを 1 つ以上のサービスネットワークに関連付けるよう求められます。まだサービスネットワークを作成していないため、ここではこの手順をスキップして[次へ]を選択します。構成を確認し、サービスを作成します。

9．VPC格子サービスネットワークの作成
サービスネットワークを作成して、使用するサービスとVPCを関連付けできるようにします。ナビゲーションペインから[Service network]を選択し、次に[Create service network] を選択します。サービスネットワークの名前を入力します。

10．Associate servicesで、作成したばかりのサービスを選択します。

11．VPC 関連付けで、Web アプリが実行されるインスタンスで使用される VPC を選択します。これは、Web アプリがサービスネットワークに関連付けられた他のサービスを呼び出すことができるため、将来的に役立ちます。
次に、いくつかのテストを実行するために使用する別の EC2 インスタンスがある 2 番目の VPC を選択します。

12．サービスの関連付けのリストからサービスのドメイン名を書き留めます。

13．VPC格子を使用したサービスへのアクセスのテスト
サービスの [Routing]タブを見て、リスナーがさまざまなターゲットグループへのルーティングをどのように処理しているかのサマリを確認

14．nozaki-vpc2で EC2 インスタンスにログインし、curlを使用してサービスドメイン名を呼び出します。予想どおり、インスタンスから2/3の応答が得られ、関数から1/3の応答が得られました。

$ curl https://nozaki-service-0df31e742a9335c8f.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws
Hello from the instance

$ curl https://nozaki-service-0df31e742a9335c8f.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws
Hello from the instance

$ curl https://nozaki-service-0df31e742a9335c8f.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws
"Hello from the function"

/to-instanceパスと/to-functionパスを呼び出すと、追加のルールによってリクエストがインスタンスと関数にそれぞれ転送されます。

$ curl https://nozaki-service-0df31e742a9335c8f.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws/to-instance
Hello from the instance at path "to-instance"

$ curl https://nozaki-service-0df31e742a9335c8f.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws/to-function
"Hello from the function"

検証2　同じIPレンジを持っているVPCを跨げるか

ここでは、EC2-Aと全く同じサブネットアドレス帯（10.0.16.0/20）で立てたEC2-Bから、まず普通にEC2-AにVPC Lattice経由でアクセスできるかを検証

すると無事アクセスできました。

$ curl https://nozaki-service-0d7968.vpc-lattice-svcs.ap-northeast-1.on.aws
Hello from the instance

次に、EC2-Bもターゲットに登録してVPC Lattice配下として、同じ通信ができるかを検証します。

1．ターゲットグループの作成
EC2-Bインスタンス用のターゲットグループを作成します。ナビゲーションペインのVPC 格子から [ターゲットグループ]を選択し、次に[ターゲットグループの作成] を選択します。

2．ターゲットの登録
リストからEC2-Bインスタンスを選択し、それを含めます。

3．サービスの作成
ターゲットグループの準備ができたので、VPC格子ナビゲーションペインで[サービス]を選択し、次に[サービスの作成] を選択します。

4．認証タイプを選択
[なし]を選択

5．サービスのルーティングを定義
Add listenerを選択します。プロトコルについては、HTTPSを使用してリッスンするようにサービスを構成します。デフォルトアクションでは、リクエストの全てをEC2-Bターゲットグループに送信することを選択します。

6．サービスをサービスネットワークに関連付け
既存のサービスネットワークnozaki-servicenetworkに関連付けます。

7．テスト
試しにWebアクセス実行するも、なぜかService Unavailable・・

$ curl https://nozaki-service2-022281e341ce39d64.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws
Service Unavailable

と思ったらEC2-Bのセキュリティグループ8080を10.0.0.0/16に制限していた。これを0.0.0.0に開放したらすんなりアクセスできたので、どうも実際はVPC Lattice独自のアドレス帯でアクセスしてるっぽい

curl https://nozaki-service2-022281e341ce39d64.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws
Hello from the instance

逆に今度はEC2-BからEC2-Aにアクセスしてみたがこれも成功。これで双方向通信できた。

所要時間

検証1：3時間（作り込みでハマったため。設定自体は1時間）
検証2：3時間（作り込みでハマったため。設定自体は1時間）

ユースケース

気になる用途としては、ネットワーク関係なくリバースプロキシWeb接続させたいってのが一番多くなるかとは思います。
他は以下

サービスを大規模に接続する
ネットワークを複雑にすることなく、VPC やアカウント全体で数千のサービスを接続します。
きめ細かいアクセス許可を適用する
サービス間のセキュリティを強化し、一元化されたアクセスコントロール、認証、およびコンテキスト固有の承認により、ゼロトラストアーキテクチャをサポートします。
高度なトラフィックコントロールを実装する
リクエストレベルのルーティングや、ブルー/グリーンおよび canary デプロイ向けの重み付けされたターゲットなど、きめ細かなトラフィックコントロールを適用します。
サービス間のインタラクションを観察する
リクエストタイプ、トラフィック量、エラー、応答時間などについて、サービス間の通信をモニタリングおよびトラブルシューティングします。

アクセスログの確認

サービスネットワークでアクセスログを有効にして、CloudWatchロググループに送信するようにしてみました。

すると以下のアクセスログを確認

{
    "startTime": "2023-04-06T01:32:42Z",
    "requestMethod": "GET",
    "requestPath": "/",
    "protocol": "HTTP/2",
    "responseCode": 200,
    "bytesReceived": 129,
    "bytesSent": 310,
    "duration": 5,
    "userAgent": "curl/7.87.0",
    "hostHeader": "nozaki-service2-022281e341ce39d64.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws",
    "targetIpPort": "10.0.22.207:8080",
    "targetGroupArn": "arn:aws:vpc-lattice:ap-northeast-1:532152701269:targetgroup/tg-0f3e7aac066e30485",
    "sourceIpPort": "10.0.18.254:42012",
    "serverNameIndication": "nozaki-service2-022281e341ce39d64.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws",
    "sourceVpcId": "vpc-0928c520838be8e3d",
    "destinationVpcId": "vpc-080ebe62e02793d0d",
    "serviceArn": "arn:aws:vpc-lattice:ap-northeast-1:532152701269:service/svc-022281e341ce39d64",
    "serviceNetworkArn": "arn:aws:vpc-lattice:ap-northeast-1:532152701269:servicenetwork/sn-00962b0558ee611cf",
    "requestToTargetDuration": 2,
    "responseFromTargetDuration": 0,
    "sslCipher": "ECDHE-RSA-AES128-GCM-SHA256",
    "tlsVersion": "TLSv1.2",
    "resolvedUser": "-",
    "authDeniedReason": "-"
}

IPはあくまでエンドのIPが表示されている。
一方受信側では、以下のVpcLatticeのIP（169.254.171.0/24）で受信していた。

169.254.171.193 - - [06/Apr/2023 01:40:00] "GET / HTTP/1.1" 200 -
169.254.171.194 - - [06/Apr/2023 01:40:07] "GET / HTTP/1.1" 200 -
169.254.171.192 - - [06/Apr/2023 01:40:08] "GET / HTTP/1.1" 200 -
169.254.171.193 - - [06/Apr/2023 01:40:10] "GET / HTTP/1.1" 200 -
169.254.171.194 - - [06/Apr/2023 01:40:17] "GET / HTTP/1.1" 200 -
169.254.171.192 - - [06/Apr/2023 01:40:18] "GET / HTTP/1.1" 200 -
169.254.171.193 - - [06/Apr/2023 01:40:20] "GET / HTTP/1.1" 200 -
169.254.171.194 - - [06/Apr/2023 01:40:27] "GET / HTTP/1.1" 200 -

気になる料金は

VPC Latticeのコストは、次の3つの要素によって決まります。
https://aws.amazon.com/jp/vpc/lattice/pricing/

プロビジョニングされたサービスの数（0.0325 USD/h）

サービス：インスタンス、コンテナ、またはサーバーレスコンピューティングで実行される特定のタスクまたは機能を提供する、独立してデプロイ可能なソフトウェアの単位
例）
1 か月は 730 時間であると仮定
2個のサービスと仮定
2 個のサービス×0.0325 USD/h×730 時間＝6,168円/月

各サービスとの間のトラフィックのデータ処理料金（0.0325 USD/GB）

各サービスを通じて転送されるデータ量＝サービスが受け取る各HTTPリクエストのデータ量＋サービスがクライアントに送信する対応するHTTPレスポンスのデータ量
例）
1 か月あたり 100 GBと仮定
2 個のサービス×0.0325 USD/GB×100 GB＝845円/月

各サービスが受け取るリクエストの数（0.13 USD/100万リクエスト）
1 か月あたり100万リクエストと仮定
1 時間あたり最初の 300,000 件のリクエストは無料のため、実質リクエスト料金＝1 か月あたり 0 USD

以上合計＝6,168円/月＋845円/月≒7,000円/月
2ALB＋2Private Link＝81.36 USD≒10,500円/月であるため、最小構成の場合はALBとPrivate Linkを組み合わせより安い

[技術検証] VPC Lattice（格子）を使って検証してみました

概要

目的・やりたいこと

対象となる技術

条件（導入にあたって前提事項）

注意事項

作業の流れ

概要図

事前準備

検証1　同一サービス間の異なるVPC間のEC2とLambdaのロードバランシング

検証2　同じIPレンジを持っているVPCを跨げるか

所要時間

ユースケース

アクセスログの確認

気になる料金は

AWSの生成AI活用事例集GenUを使い倒す

アイレット新卒シリーズ Vol.65 25卒内定者向けオフィスツアー実施レポート

【AWS re:Invent 2024】Amazon Linux AL2023 and beyond

cron の代わりに systemd timer を使ってみた

Arduinoを初めて使う時のセットアップと実例集

[技術検証] VPC Lattice（格子）を使って検証してみました

概要

目的・やりたいこと

対象となる技術

条件（導入にあたって前提事項）

注意事項

作業の流れ

概要図

事前準備

検証1 同一サービス間の異なるVPC間のEC2とLambdaのロードバランシング

検証2 同じIPレンジを持っているVPCを跨げるか

所要時間

ユースケース

アクセスログの確認

気になる料金は

関連記事Related Articles

ALB + VPC 対応版 Lambdaのメモ

マネージドプレフィックスリストでCloudFront経由のアクセスのみに制限しよう

[技術検証]Ingress VPCとEgress VPCを一つにできるか

AWS CLIにてALBにセキュリティグループを設定する際の仕様について

Direct Connect経由なFusion-ioとRDSはどっちが速いのかを繋いで、ベンチマークしてみた。

検証1　同一サービス間の異なるVPC間のEC2とLambdaのロードバランシング

検証2　同じIPレンジを持っているVPCを跨げるか