はじめに

AWS PrivateLink(以下PrivateLink)はVPCエンドポイントからAWSのサービス・他のVPC内のアプリケーションに、パブリックインターネットを経由せずアクセスさえるネットワーキングサービスです。

PrivateLinkで接続される側(=サービスプロバイダー)のVPCでは、リクエスト元(=サービスコンシューマー)からのトラフィックをルーティングするため、NLBまたはGWLBをデプロイする必要がありました。
(サービスプロバイダーVPCの入口となるエンドポイントサービスに、NLBまたはGWLBを関連付ける)

re:Invent2024のアップデートでリソースエンドポイント & リソースゲートウェイが登場し、NLB/GWLB無しでPrivateLinkを張れるようになりました。
リソースゲートウェイ経由のアクセスをどうやって制限するのか気になったので、本記事では実際にリソースエンドポイントとリソースゲートウェイを構築して調べてみたいと思います。

リソースエンドポイントのドキュメント(英語版)

リソースゲートウェイのドキュメント(英語版)

リソースエンドポイントを使ったPrivateLinkの構成

今回はService Provider VPCにEC2を立て、Resource Gateway経由で通信させます。
Service Provider EC2のResource ConfigurationをResource EndpointとResource Gatewayに関連付けます。

リソースゲートウェイ経由のPrivateLinkの構築

リソースゲートウェイの作成

サービスプロバイダ側のVPCで作成します。設定項目はシンプルです。

Resource Configurationの作成

サービスプロバイダ側のアカウントで設定します。

ターゲット(DNS,IPなど)を1つ設定する場合はConfiguration TypeをResourceに指定します。Resource Groupに入れるリソースを作成する場合もResourceを指定します。

リソース共有の作成(サービスコンシューマがサービスプロバイダと別アカウントの場合)

Resource Access Managerからリソース共有を作成し、Resource Configurationと関連付けます。

VPC Lattice Resource Configurationsを選択していますが、
表記はVPC Lattice Resource Configurationとなっています。

RAMで共有リソースをResource Configurationに、共有プリンシパルに共有先のアカウントIDを入力します。(検証に使える別アカウントが無く、無理やり共有元と同じアカウントIDを入れているためエラーになっています、ステータスが失敗になってるの見た目がイマイチすぎますね、すみません…)

キャプチャだと自アカウントとは共有できないよ！って怒られてますが、こんな感じでResource Configurationを別アカウントに共有できそうです。

リソースエンドポイントの作成

リソースエンドポイントは他のインターフェイスVPCエンドポイントと同じように作成します。セキュリティグループも設定できます。

疎通確認

自アカウントのVPC同士ですが、サービスコンシューマVPC内のEC2からリソースゲートウェイ経由でサービスプロバイダVPC内のEC2にリクエストを投げてみました。

リソースエンドポイントのDNS名を確認します。

ターゲットのEC2には8080宛のリクエストにHello Worldを返す簡単なシェルスクリプトを仕込んでいます。

#!/bin/bash
PORT=8080
while true; do
  {
    echo -ne "HTTP/1.1 200 OK\nContent-Type: text/plain\n\nHello, World!\n";
  } | nc -l -p $PORT
done

リソースエンドポイント宛にcurlを投げたらちゃんと返ってきました。

こちらはリクエストを受けた側のEC2の出力です。塗りつぶしちゃってますが、
Host:リソースエンドポイントのDNS名となっています。

おわりに

NLB使わなくてもPrivateLink張れる、これは嬉しいアプデだ！と思いつつ
PrivateLinkで接続してくるアカウントを限定したり、リソースエンドポイントとの接続時に承認を必須にできるのかな？と思ったりもしました。

サービスプロバイダのリソースゲートウェイに紐づけたResource Configurationの共有設定でアクセスを許可するアカウントを指定できそうです。

リソースエンドポイントにエンドポイントポリシーは設定できなさそうなので、
あとはリソースエンドポイントへのアクセスをセキュリティグループで制御することでアクセス絞ることになりそうです。

リソースエンドポイントの作成時にResource Configurationを指定しますが、サービスコンシューマとサービスプロバイダが同じアカウントの場合はリソースエンドポイント作成後の承認は必要ありませんでした。(承認の画面は探した限り無い)

クロスアカウントの場合を確かめられていませんが、リソース設定が共有されている=接続を承認されている、という扱いになりそうです。

NLBを使ったサービスエンドポイントのようにVPCエンドポイントとサービスエンドポイントの接続時にサービスプロバイダ側での承認をする、といった考え方ではなく、Resource Configurationでリソースエンドポイント - リソースゲートウェイ - リソースを紐づけるというイメージかなと構築しながら思いました。

Resource ConfigurationはVPC Latticeの仕組みをかなり利用しているようなので、
より理解を深めるためにVPC Latticeをお勉強したほうがよさそうです。