VPCエンドポイント、NATGatewayまとめ

始めに

自社で運用しているシステムでVPCエンドポイントが乱立していて、無駄なコストが発生してしまっていました。
NAT Gatewayを置いているので、プライベートサブネットにあるECSから各AWSサービスへのアクセスを実現させるという意味では、VPCエンドポイントは必須ではなく、全てのVPCエンドポイントを消して、NAT Gateway経由で全て通信するという選択肢も当初はありました。
セキュリティ、コスト面、運用面での最適化を図る上で、知らないことがたくさんあったので整理します。

コスト面から見たVPCエンドポイントとNAT Gateway

まず、VPCエンドポイントはGateway型とInterface型の２種類があります。
S3とDynamoDBへのVPCエンドポイントはゲートウェイ型で、それ以外のVPCエンドポイントはインタフェース型で、ゲートウェイ型は無料というのはよく聞く話だと思います。

コストは以下の表にまとめてみました。

サービス名	設置費	通信費	接続先のサービス
Gatewayエンドポイント	無料	無料	S3とDynamoDBのみ
Interfaceエンドポイント	$7.2/月	$0.01/GB	色々
NAT Gateway	$32.4/月	$0.045/GB	何でもOK

Gatewayエンドポイントは完全無料なので、S3やDynamoDBへの経路であれば、コスト面で考えると使わない手はないです。

InterfaceエンドポイントとNAT Gatewayを比較すると、設置費、通信費両方ともNAT Gatewayの方が高いですが、エンドポイントは接続先サービス一つにつき、1つ必要なのに対し、NAT Gatewayは1台でどのサービスに対しても接続できます。
仮に通信費を考えないようにすると、5個以上Interfaceエンドポイントを置くのであれば、NAT Gateway１台の方が割安です。
また、システム要件的にNAT Gatewayが必要な場合もそれなりにあると思うので、その場合は実質NAT Gatewayの固定費は0と考えられるのでInterfaceエンドポイントがコスト的に無駄に見えてきます。

実際にコスト面で最適化を図る場合には、各Interfaceエンドポイントでどれくらいの通信費が発生しているのか計算する作業も必要になりそうです。
あとは、Gatewayエンドポイント以外は基本的に各AZごとに一つ配置するのでその辺も踏まえてコストは計算しないといけませんね。

結論としては、通信費次第ではあるが、コスト面で見ると、Interfaceエンドポイントを一切使わないという手もあり得るということです。

セキュリティ面から見たVPCエンドポイントとNAT Gateway

VPCエンドポイントはプライベート接続を可能にしますが、NAT Gatewayはパブリック接続となります。なので、セキュリティ面で考えれば、VPCエンドポイント一択です。
ただ、パブリック接続になるものの、NAT Gateway経由での外部アクセスも安全性が高いものなので、コスト次第ではVPCエンドポイント一択というわけでもないと思います。

これは、私用のメモですが、S3パブリックアクセスブロックONにしている場合でも、NAT Gateway経由(パブリックアクセス)でアクセスできます。
S3パブリックアクセスブロックはIAM認証に基づいたものなので、ネットワーク的にパブリックかプライベートなのかという話ではないようです。

運用面から見たVPCエンドポイントとNAT Gateway

Gatewayエンドポイントは設置すれば終わりですが、Interfaceエンドポイントは適切にセキュリティグループを設定する必要があります。あまりないかもしれませんが、VPC内で新たなサブネットを立てる度にセキュリティグループの設定変更が必要で面倒です。(NAT Gatewayもサブネットのルートテーブルの修正が必要ですが、Interfaceエンドポイントは複数あることが多いし、サブネット自体の設定を変更するわけではないので忘れそうです。)
なので、運用だけで考えるのであれば、Interfaceエンドポイントは使いたくないといった感じでしょうか。

結論

上記を踏まえて、ほとんどの環境では、基本的にVPCエンドポイントを使用し、Interfaceエンドポイントは各AZごとに配置するで問題ないと思います。
すごい当たり前な結論になってしまいましたが、知らないことも結構あったので整理してよかったです。

PS GatewayエンドポイントとInterfaceエンドポイントの内部的な仕組みの違い

Gatewayエンドポイントはルートテーブルに追加するだけ。
●ネットワークレベルでの動作

1. アプリがs3.amazonaws.comにアクセス
2. VPCルーターがルートテーブル確認
3. S3のIPアドレス範囲 → Gateway Endpointに転送
4. AWS内部ネットワーク経由でS3に到達

Interfaceエンドポイントの実体はENI。
ENI自体はパブリックでもプライベートでもどちらでも置けるが、パブリックにおくメリットはないので、プライベートサブネットに置かれる。ENIのIPアドレスはプライベートサブネット内の具体的なIPとなる。
各ENIにはSGがついているので、そこでアクセス制御をすることになる。

●ネットワークレベルでの動作

1. アプリがs3.amazonaws.comにアクセス
2. VPC内DNSがInterface EndpointのENI IPに解決
3. ENIに対してHTTPS通信
4. ENI経由でAWS PrivateLinkネットワークに転送
5. 対象AWSサービスに到達

NAT Gatewayが既に置かれているVPC内にInterfaceエンドポイントを後から追加した場合、プライベートDNSがInterfaceエンドポイントに切り替わります。

例えば、既にNAT Gatewayが配置されているVPC環境でECR用のVPCエンドポイントを追加したケースを考えてみます。
今まではNAT Gateway経由でECSタスクはECRイメージを取得しに行っていましたが、ECR用VPCエンドポイントが追加されたことでプライベートDNSがECR用エンドポイントに切り替わるので、今後、ECRへのアクセスはECR用VPCエンドポイント経由で取得されることになります。ここでもし、このVPCエンドポイントのSGのインバウンドルールで対象となるECSタスクが配置されているサブネットからの通信を許可していないと、ECRイメージが取得できなくなってしまいます。(VPCエンドポイントが使えないときに、NAT Gateway経由でとってくるといったことはしてくれません)

プライベートDNS：VPC内でAWSサービスの標準ドメイン名をInterface Endpointに自動解決する仕組み。VPC間でInterfaceエンドポイントを共有したい場合などを除いて、基本は有効にしておくべき。

-プライベートDNSの有効時/無効時の挙動-
●有効時
アプリケーションからs3.us-east-1.amazonaws.comにアクセス
↓
VPC内部DNSがs3.us-east-1.amazonaws.comからInterface EndpointのENI IPを名前解決する。
※これによりプライベートなS3アクセスが実現される。

●無効時
アプリケーションからs3.us-east-1.amazonaws.comにアクセス
↓
VPC内部DNSがs3.us-east-1.amazonaws.comのパブリックIPを名前解決する。
※インターネット経由でアクセスが実現する。

プライベートDNSとVPCエンドポイントが合わさって初めてプライベート接続が実現するということですね。