ECS FargateでWebクローラーのバッチ処理を開発しているのですが、新規バッチのデプロイ後にAWSのコストが予想以上に上がったときのことを書きます。

結論としては、ネットワーク設定ミスによって、本来かける必要のないコストがかかってしまっていました。

個人的に気づきにくかったので、AWSのコスト見直しの一つの項目として、確認の手順を書きたいと思います。

気付いたきっかけ

AWS Cost Explorer のホーム画面で日別コストが見れるのですが、ある日から急にコストが高まっていることに気づきました。

サービス別のコストを見ると、「EC2 その他」の項目が増加していることが分かりました。

これだけだと原因が分かりにくかったのですが、
「使用タイプグループ」のフィルターでEC2関連を絞り込んでいくことで、原因となっているのが「EC2: NAT Gateway - Data Processed」であることが分かります。

AWSのメニューから、VPC > NATゲートウェイ > モニタリングと遷移した画面でも、NATゲートウェイの通信量が増えていることが確認できます。

NATゲートウェイ通信量増加の原因

ECS Fargate でサービスを作成したとき、ネットワーク設定のサブネットの項目にパブリックサブネットではなくプライベートサブネットが指定されていたことが原因でした。

そもそもプライベートサブネット・パブリックサブネット・ NATゲートウェイとは何か

プライベートサブネットはインターネットから接続できないセキュリティ性の高いネットワークで、
パブリックサブネットはインターネットから接続可能なネットワークです。

NATゲートウェイは、プライベートサブネットの内側から外部のインターネットに接続する際に、プライベートIPアドレスをグローバルIPアドレスに変換するためのものです。
※ NATは Network Address Translation の略です。
※ グローバルIPアドレスがないとインターネットに接続できません。

プライベートサブネットには、外部からのアクセスを遮断したいDBサーバなどを配置することが多いです。
今回問題となったバッチ処理のサーバは別に機密情報を持っているわけではないのでプライベートなネットワークに配置する必要はありませんでした。パブリックサブネットに配置することで、NATゲートウェイを通さなくなるので通信コストの増加をなくすことができました。

プライベートサブネットとパブリックサブネットの見分け方は、ルートテーブルの送信先「0.0.0.0/0」がインターネットゲートウェイにつながっているかでどうかで見分けます。

ターゲットが「igw-」から始まるのがインターネットゲートウェイなので、この場合はパブリックサブネットです。

「nat-」や「eni-」から始まる文字の場合は、プライベートサブネットとなります。

解決方法

ECS Fargateのサービスのネットワーク構成に設定していたサブネットの項目を、プライベートサブネットからパブリックサブネットに設定し直すことで解決しました。

※ ECSクラスターのサービスで実行している場合、ネットワーク構成がサービス作成時にしか設定できないため、サービスを新たに作り直す必要があります。

ちょっとした設定の違いでコストが大きく変わることがあるので、びっくりして心臓に悪いですが今後もエンジニアとして頑張りたいと思います。