[AWS] FargateをNatゲートウェイと組み合わせて完全に死亡した話

今回お話しするのはPrivateLinkです。
名前だけは知っていて機能としては使ったことがなかったのですが、これをうまく使えば大きく通信費用を減らすことができるかもしれません。

今回はタイトルの通り、失敗例とPrivateLinkで解決した話を書こうと思います。

見出し

1 失敗の経緯
2 Fargate＋Natゲートウェイはヤバイ
3 対策はPrivateLinkで！
4 実際に導入
5 PrivateLinkの有無の比較
6 おわりに

失敗の経緯

もともと、業務で使用するために定期実行のcron処理を実行する方法を模索しており、「Fargate + タスクスケジュール」の組み合わせを考えていました。
EC2ベースのタスクスケジュール機能では、タスクが動いていない時間のリソースが無駄になってしまうことが気になったことが要因です。

AWS Batchで定期実行を行うことも考えました。
こちらを採用した場合には必要なタイミングでEC2インスタンスが立ち上がり、不要な時には削除されるのでリソース的な無駄はなくなります。

しかしAWS Batchはあくまでもbatch処理のためのサービスであり、cronのような決まったタイミングで定期的に実行する処理には不向きです。
(決まった時間に実行させたり、10分おきに実行などが意図したタイミングにならないため)

ということで最終的にFargate + タスクスケジュールによる定期実行を実装することに決まりました。

Fargate＋Natゲートウェイはヤバイ

「AWS FargateでNATを利用する時の注意事項」というQiitaの記事は知っていたのですが、選択を誤ってしまいました。

この記事にもあるように、PrivateSubnetに配置したFargateはNatゲートウェイを経由してECRからdockerイメージをダウンロードします。
例えば、dockerイメージのサイズが1GBあり、そのイメージを使って５分おきに実行されるタスクスケジュール設定があった場合、５分おきに1GBのダウンロードの通信が発生します。

そのようなcron処理が大量にあった場合には、大量の通信が常に発生してしまう状態になります。

EC2がホストのタスクスケジュールの場合にはdockerイメージがローカルへキャッシュされるためこのような自体にはなりませんが、ホストの実体がないFargateではこのような問題に直面してしまいます。

選択を誤った経緯については、初めてこの構成を導入したサービスでは「300MBのイメージで1日1回実行する」程度の頻度だったため料金の発生が微量だったため気がつくことができなかったためです。
この組み合わせの構成に前例ができたことで別のサービスへ構成の展開をしたところ、展開先のサービスでは大量の定期実行処理が設定されていたために大幅な料金の発生が起きてしまいました。

これに気がついた時はしばらくへこみました。

対策はPrivateLinkで！

AWSの2019年1月の記事にあるようにECS・ECRがPrivateLinkに対応しました。
本来であればECRへの通信はインターネットを経由したものになるのですが、PrivateLinkによりエンドポイントを作成することで外部のネットワークを経由せずにやりとりを行うことができるようになります。

こちらからNatゲートウェイとPrivateLinkでどちらの方が料金が安くなるかを計算することができますので、導入の際には参考にしてみると良いですね。

実際に導入

実際にエンドポイントを1つ作成してみます。
エンドポイントの作成をする前に、対象のVPCの範囲でhttps通信を許可するセキュリティグループを用意しておきます。

PrivateLinkの設定を行うためにはVPCコンソールを開きます。
「エンドポイント」という項目があるのでそちらから新規作成をします。

今回はECRに必要な「com.amazonaws.ap-northeast-1.ecr.dkr」を選択しました。
PrivateSubnetからのアクセスに対応したいため、対象のサブネットはPrivateの物を選択します。
最後に、先ほど作成したセキュリティグループを設定して完了です。

作成にはしばらく時間がかかります。

PrivateLinkの有無の比較

PrivateLinkのエンドポイントが有効になる前と後で比較をしてみます。
VPC内の適当なEC2インスタンスからECRリポジトリのドメインへの名前解決をしてみました。

この段階では適用前のためパブリックな接続先が表示されています。

エンドポイントが適用されたことを確認してから再度nslookupコマンドを実行してみました。
するとVPC内のPrivateIPアドレスが割り当てられていることがわかります。

このようにPrivateLinkを設定すると、外部のネットワークを介せずにECRへアクセスが可能です。

おわりに

実際にECSを運用するのであれば、この他にも
　・com.amazonaws.region.ecr.apiのエンドポイント
　・Amazon S3 ゲートウェイエンドポイント
　・CloudWatch Logs VPC エンドポイント(PrivateLinkでログを吐くなら)
の設定が必要なようです。
※ Fargateのバージョンが1.4になった時に必須になります。

詳細についてはAWSのドキュメントに手順が載っているためこちらを参考にした方が早いでしょう。

PrivateLink自体も有料なサービスですが、Natゲートウェイを経由した通信よりも多くの場合で費用を抑えられるはずです。
もしもNatゲートウェイの通信費が気になっている場合は、この設定を見直せば解決するケースがあるかもしれませんね。