【全世界のFargateファンに朗報】Fargate利用料が35%〜50%値下げされました！

「Fargate便利、便利だよね。でも、高くない？」

安くなりました。それも異常なほどに安くなりました。これが衝撃といわずして何が衝撃でしょうか。ほんまなんでやねんというぐらい安いです。罠は特に無いです。そのまま安いです。今使ってる人は今日から安いです。

Fargate導入中のお客様全てに、このニュースをお届けしたい気持ちです。

AWS Fargate Price Reduction – Up to 50% | AWS Compute Blog

Fargate　大幅値下げきたか…!!

　 ( ﾟдﾟ)　ｶﾞﾀｯ
　 /　　 ヾ
＿_L| /￣￣￣/＿
　 ＼/　　　/

Fargateの値下げ幅一覧

その値下げ幅をとくとご覧あれ。

値下げ幅については、以下の設定となっています。

• 1ｖCPUあたり、最小メモリ構成で35%OFF
• 同じCPU構成で、メモリが増えていくに従い、値下げ幅が50%に近づく

EC2との価格比較詳細

弊社大栗による、EC2との詳細な価格比較記事がでております。EC2から移行される際は、是非こちらも参考にしてみてください。幅はありますが、概ね素のEC2から3〜25%ぐらい割高となっています。

2019年1月にAWS Fargateが大幅値下げしたのでEC2との価格比を確認してみた

通常、EC2でECSを動かしている場合、タスクがスケールした時や、タスクの入替えのために、ある程度の余剰リソースをEC2インスタンスに確保しておくことが必要でした。そのあたりの無駄がなくなること諸々を考えると、この価格は十二分にコストメリットがでていると言えます。

Fargate大幅値下げの背景にFirecracker有り

re:Invent2018で発表されたマイクロVMであるFirecrackerが、今回のFargateの大幅値下げに関係するようです。Firecrackerは、マルチテナントのコンテナのサービスを作成し管理するためのオープンソースですが、これを利用することで、より少ないオーバーヘッドで実行環境を開始すことができるようになり、今回のコスト削減が実現してます。

Fargateでは実現できないこともあるので注意

現在、EC2ベースでECSを利用している環境で、これを機会にFargateへの移行を検討される人も多いかと思いますが、まだFargateではできないことも結構あるので注意が必要です。

docker execコマンドが使えない

EC2ベースでのECS運用の場合、コンテナになにかあった場合に原因追求のためdocker execでシェルログインすることが多いかと思いますが、ホストインスタンスが存在しないFargateでは、その手法は使えません。sshdをコンテナにインストールしておいてSSHログインすることも可能は可能ですが、プロダクション環境で利用するコンテナにsshdを動かしてくのはあまり良いとは言えないでしょう。

Fargateは永続ストレージを持たないため、全てのログを標準出力、標準エラー出力経由で外に常にだしておく設計がこれまで以上に重要となります。

ログドライバーがawslogs（CloudWatch Logs）のみ

現状、Fargate上で動くDockerで採用できるログドライバーはawslogsのみです。つまりは、ログの集約先としてはCloudWatch Logsしか利用できません。そのため、ログプラットフォームとして非常に利用が多いFluentdなども利用することができません。

ただ、この点は、将来のアップデートで、他のログドライバーにも対応されることが明言されているので、遅かれ早かれ対応されることでしょう。首を長くして待ちましょう。こちらのGitHubでIssueがあがっています。

Fargate Log Driver Support v2 · Issue #10 · aws/containers-roadmap

EFSが利用できない

複数タスク内で共通のストレージ領域を使うためにEFSを利用したいというシチュエーションも結構あるかと思いますが、現状それはできません。S3などを利用していただくことになります。

GPUインスタンスを利用できない

EC2を利用できないため、特定の用途で利用するためのインスタンスタイプが指定ができません。

ホストインストール系のセキュリティソフトが利用できない

従来はDockerコンテナを利用するホスト側インスタンスに、DeepSecurityなどのセキュリティアプリケーションをインストールして対応していた場合も多かったかと思いますが、Fargateでは利用できないため、その他のコンテナのSideCarとして動作するようなセキュリティアプリケーション（aquaやTwistlockなど）の検討が必要です。

Windowsコンテナが使えない

使えません…

Fargateは本当になにもメンテナンスしなくても良いの？

実は以前、機密情報の受け渡しにFargateが対応した時点で、Fargateにタスクリフレッシュのためのリタイアメント機能が導入されています。

【祝！】FargateでもECSにごっつ簡単に環境変数に機密情報を渡せるようになりました！ ｜ DevelopersIO　アップデート2.「タスクリフレッシュのためのリタイアメント機能の導入」

AWSでFargateタスクに対してセキュリティ、もしくはインフラ上の問題を検知した場合、AWSがそのタスクに対して必要なパッチを適用します。基本これらのパッチはタスクの停止は必要ありませんが、場合によってはタスクのリサイクルが必要になる場合もあります。

事前にメールがとどき、ローリングアップデートにより指定期日にタスクが再起動するものです。基本的にローリングアップデートは新タスクが動作し、ヘルスチェックが正常であることが確認できたら旧タスクが停止する動作です。直接的にサービス影響はない可能性もありますが、プロダクション環境での運用には一定の考慮が必要です。

Fargate関連アップデート

下記、Toriさんのツイートにあるように、リージョンあたりのタスク数増減もデフォルトで20から50に引き上げられています。

ちなみにデフォルトで起動可能な Fargate タスク数もリージョンあたり 50 まで上限が増えております〜(これまではリージョンあたり 20)

/ "Amazon ECS Service Limits - Amazon Elastic Container Service" https://t.co/CGqi1OA2qF

— ポジティブな Tori (@toricls) 2019年1月7日

私の知っているお客様でも、タスク定義が10を優に超えるお客様は複数ございます。そういう場合、冗長化構成にするとすぐにタスク数20を超えていたのですが、そういった場合でも非常に使いやすくなったかと思います。

Fargateの今後の普及と進化を期待させるには十分な値下げ

re:Invent2017の衝撃的なデビューで、一躍コンテナ実行環境として光を浴びたFargate。その取り回しのやりやすさや、サーバーの面倒（各種バックアップやセキュリティパッチの運用）を見なくて良い便利さから一気に利用は広がりました。

FargateはEC2インスタンスを気にしなくて良いので、複数コンテナを利用するマイクロサービス的な環境でも、アベイラビリティゾーンあたりのインスタンス配置の考慮が基本的に不要（サービス定義でタスク配置するサブネットを指定するだけ）であったり、コンテナオートスケール時に合わせてEC2インスタンスをスケールアウトする手間も不要です。ECSを利用する上で、わかりにくく設定が難しいネットワークモードも、Fargateなら設定が非常にシンプルでセキュリティグループの設定もわかりやすいです（AWS VPCモードになり、全コンテナにパブリック or プライベートIPアドレスが割り当てられる）。

そのあたりを全てAWS側で処理してくれる故の価格の割高感があったわけですが、今回の値下げで非常にFargateが利用しやすくなったかと思います。タスクスケジューラーとしての1タスクのみのシンプルな利用から、複数マイクロサービスが連携する大規模なクラスタ環境まで、気軽に使える状況が整いました。もちろん上述したとおりECS（on EC2）でしかできないこともあるので、全AWSのコンテナワークロードがFargateに移行できるわけではありませんが、その制約を受け入れながらアプリケーションの実行環境として、Fargateどんどん活用いただければと思います。

また、EKSがFargate対応したときにもめちゃくちゃ効果がでかいですね。ごっつ楽しみです。

それでは、今日はこのへんで。濱田（@hamako9999）でした。