VPCエンドポイント（インターフェースエンドポイント）はVPCの中に1つあれば動作するという話

はじめに

インターフェースエンドポイント、使っていますか？

AWS のサービスエンドポイントと通信する場合、パブリックサブネットにインスタンスがある場合は、インターネットゲートウェイ経由で通信ができます。

しかし、プライベートサブネットにあるインスタンスは、インターネットへの疎通ができないため、VPC エンドポイント（インターフェースエンドポイント）経由でAWS のサービスエンドポイントと通信する必要があります。

筆者はサブネットごとに 1 つの VPC エンドポイントが必要だと考えていました。しかし、ドキュメントには以下の記載がありました。

インターフェイス VPC エンドポイント (AWS PrivateLink) - Amazon Virtual Private Cloud

サービスでサポートされている複数のアベイラビリティーゾーンに複数のサブネットを指定すると、アベイラビリティーゾーンの障害からインターフェイスエンドポイントをより確実に回復できます。

サブネットごとに 1 つの VPC エンドポイントを作ると、アベイラビリティゾーンの障害が発生してもより確実に回復ができるという記載内容から、VPC 内の 1 つのサブネットのみに VPC エンドポイントを関連付けても動作をするのではと考えました。ドキュメントにも以下の図示があり、VPC エンドポイントが存在するサブネットと異なるサブネットのインスタンスからも、VPC エンドポイント経由の通信ができると読み取れます。

そこで、実際に VPC 内に 1 つの VPC エンドポイントのみで問題なく通信ができるかを検証してみることにしました。

検証

検証には Systems Manager を使用することにします。

プライベートサブネットにある EC2 が VPC エンドポイント経由で、Systems Manager エンドポイントへ到達している状況を作ります。

また、プライベートサブネットにある EC2 へ Session Manager で接続できることも併せて確認します。

始めに、Systems Manager の動作要件に必要なインターフェースエンドポイントを 3 つ作成します。

ステップ 6: VPC エンドポイントの作成 - AWS Systems Manager

「インターフェイスエンドポイントの作成」の手順に従って、以下のインターフェイスエンドポイントを作成します。

com.amazonaws.region.ssm — Systems Manager サービスのエンドポイント。

com.amazonaws.region.ec2messages — Systems Manager は、このエンドポイントを使用して SSM Agent から Systems Manager サービスへの呼び出しを行います。

com.amazonaws.region.ssmmessages — このエンドポイントは、Session Manager を使用して安全なデータチャネルを経由しインスタンスに接続する場合にのみ必要です。詳細については、「AWS Systems Manager Session Manager」および「リファレンス: ec2messages、ssmmessages およびその他の API オペレーション」を参照してください。

ここでは、東京リージョンの ap-northeast-1c のプライベートサブネットに VPC エンドポイントを関連付けます。

東京リージョンの ap-northeast-1a のプライベートサブネットに EC2(Amazon Linux 2) を起動します。

最新の AWS 公式の AMI では、SSM Agent がプリインストールされているため、SSM Agent のインストールは不要です。

SSM Agent の ping の状態がオンラインであることを確認しました。

EC2 へ Session Manager で接続してみます。

sh-4.2$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/instance-id
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    56  100    56    0     0   4125      0 --:--:-- --:--:-- --:--:--  4307
*   Trying 169.254.169.254:80...
* Connected to 169.254.169.254 (169.254.169.254) port 80 (#0)
> GET /latest/meta-data/instance-id HTTP/1.1
> Host: 169.254.169.254
> User-Agent: curl/7.79.1
> Accept: */*
> X-aws-ec2-metadata-token: AQAE<metadatatoken>
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< X-Aws-Ec2-Metadata-Token-Ttl-Seconds: 21600
< Content-Type: text/plain
< Accept-Ranges: none
< Last-Modified: Thu, 17 Nov 2022 06:23:12 GMT
< Content-Length: 19
< Date: Thu, 17 Nov 2022 06:47:02 GMT
< Server: EC2ws
< Connection: close
<
* Closing connection 0
i-0a4EXAMPLEEXAMPLE

接続ができました！インスタンスメタデータも問題なく取得できるようです。

また、ssm.ap-northeast-1.amazonaws.comの名前解決結果もプライベート IP アドレスになっています。

sh-4.2$ dig ssm.ap-northeast-1.amazonaws.com +short
172.31.66.59

ネットワークインターフェースのコンソールでも、当該のプライベート IP アドレスは VPC エンドポイントであることを示しています。

以上のことから、VPC エンドポイントは VPC 内にひとつでも問題なく稼働することが確認できました。

何故 VPC 内にひとつでも動作するのか

サブネットのルートテーブルに関連します。

VPC エンドポイントのインターフェースエンドポイントは、サブネット内にひとつの ENI を作成し、プライベート IP アドレスを持ちます。

サブネットのルートテーブルでは、基本的に VPC 内の CIDR 範囲は local を送信先とするため、サブネットをまたいだ通信を行います。

そのため、VPC エンドポイントが他のサブネットにあっても、問題なく疎通ができる形になります。

改めて、この図と同様であることが分かります。

おわりに

2022/11/16 現在、東京リージョンの VPC エンドポイントは 1 つあたり 0.014USD/時間、また、最初の 1 PB は処理データ 1 GB あたり0.01 USDの料金が発生します。

各 AZ に VPC エンドポイントを作成する場合は、AZ 分の料金が発生します。

AZ 障害に備えたい場合、追加料金が発生することになりますので、ご要件に応じて VPC エンドポイントを作成ください。

参考資料

料金 - AWS PrivateLink | AWS