Private Subnet 環境でECS Fargateを動かすためのネットワーク(NATGateway/VPCエンドポイント)

はじめに

こんにちは、ネットワークスペシャリストの小見です。
今回は、Private Subnet環境でECS Fargate（以降ECS）を動かすためのネットワークサービスと料金を調べましたのでまとめていきます。

参考にさせて頂いた記事
https://dev.classmethod.jp/articles/vpc-endpoints-for-ecs-2022/
https://future-architect.github.io/articles/20210618a/

問題点と解決策

問題点

Private Subnet環境でECSを起動しようとすると、以下のような問題点が発生します。

• ECSがECRからイメージをpull出来ない。
• Systems Managerから秘匿情報の取得が出来ない。
• ECS Execが出来ない。
• ECSからS3にアクセス出来ない。
• 外部APIにアクセス出来ない。
• CloudWatchLogsにログを送信出来ない。
• etc

解決策

Private Subnetから外部にアクセス出来るようにするために、以下2つのサービスが存在します。

NATGateway

メリット

オールマイティーなサービスです。
とりあえずこれだけ設定していれば前述した問題点は全て解決します。
AWSの外に出る通信は、これを選択するしか現状自分は知りません。
※NATインスタンスは、本番環境に適しないと思いますので、除外しております。

デメリット

お値段が高いです。

起動しているだけで、以下の料金がかかります。
USD 0.062/時間
※マルチAZの場合AZ数だけ必要になります。

また、NATGatewayを行き来する通信量に対して以下料金がかかります。
USD 0.062/GB

意外と高額ですので、考慮せずにNAT Gatewayだけにしてしまって悲劇の惨状になっていた記事をいくつか拝見しました。

VPCエンドポイント

メリット

NATGatewayと比べてお安めです。

起動しているだけで、以下の料金がかかります。
USD 0.014/時間
約1/4の料金
※マルチAZの場合AZ数だけ必要になります。

通信量に関しては以下料金がかかります。
USD 0.01/GB
約1/6の料金

デメリット

AWSへのサービスだけしか出来ず、AWS外のネットワークへはサポートしておりません。

1つ設定すれば良いわけではなく、AWSのサービス毎や、サービス内でもエンドポイントが分かれており複数設定する必要がある場合があり、起動料金が高くなることが考えられます。

全体図

ということで、ざっくり2つを組み合わせた構成のイメージです。

ただ、見てわかる通りVPCエンドポイントが乱立しております。
これでは、折角安くするためにVPCエンドポイントを立てたのに、逆にVPCエンドポイントの起動料金が上回ってしまう悲劇の可能性もあります。
これより、不要なVPCエンドポイントを省いていきます。

最適なVPCエンドポイントを模索する

NATGatewayが高いから、VPCエンドポイントを進める記事はいくつか見ますが、今回はその逆で、不要なVPCエンドポイントをNATGatewayに寄せようと思います。

方針

NATGatewayが高くつく原因は、通信量が増えたときの料金増加です。
つまり、通信量が多い箇所に関しては、VPCエンドポイントを利用して、
通信量が少ない箇所に関しては、NATGatewayを利用してVPCエンドポイントを消します。

以下は、代表的なサービスについて個人的な見解をまとめておりますので、ご参考になればと思います。

S3とDynamoDB

この2つは、特殊なVPCエンドポイントで料金が無料なので無条件で作成して大丈夫だと思います。

https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/gateway-endpoints.html

CloudWatch Logs

サービス特性によると思いますが、ログは比較的量が多くなる傾向があると思いますので、VPCエンドポイントは必要だと思います。

ECR

ECRには主に2つVPCエンドポイントが存在します。
https://docs.aws.amazon.com/ja_jp/general/latest/gr/ecr.html

ecr.api

こちらは、ドキュメントを読む限りAPI通信で利用しているだけなので恐らく通信量は多くないと予想しています。sそのため、こちらのVPCエンドポイントは不要と予想しています。

ecr.dkr

こちらは、イメージをpullしてくるためのエンドポイントに見受けられるため、VPCエンドポイントが必要だと思われます。
ただし、イメージが極端に小さかったり、ECSのオートスケール、デプロイや再起動がほとんど無い場合といった特殊なケースでは、VPCエンドポイントが不要になるケースがあると思います。

SystemManager

こちらも2つ存在しますが、どちらもやり取りする情報が基本的に文字列のみ、かつ頻度も少ないため、VPCエンドポイントは不要だと思われます。

まとめ

NATGatewayは高いからとりあえずVPCエンドポイントをポイポイおいておけば良いんでしょ？的な感覚で料金を見積り始めたら、馬鹿みたいにVPCエンドポイントが高くついてしまい、慌てて節約できないかあれこれ試行錯誤しました。
こういうところケチでよかったな〜と思ったり思わなかったりします。
また、学生時代にネットワークした基礎知識が役に立ったりしたので、基礎勉強大事だなと改めて感じました。

コスト削減目指されている方の何かの引っ掛かりになれば幸いです。