1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

JAWS-UG(AWS Users Group – Japan)Advent Calendar 2024

Day 16

リソースゲートウェイを使ってNLB無しでPrivateLinkを構築する

Last updated at Posted at 2024-12-15

はじめに

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に関連付けます。
image.png

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

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

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

ResourceGateway2.png

Resource Configurationの作成

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

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

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

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

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

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

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

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

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

疎通確認

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

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

ターゲットの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を投げたらちゃんと返ってきました。
疎通確認.png

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

おわりに

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

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

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

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

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

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

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

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?