コンテンツにスキップ

Amazon ECS Managed Instanceは AWS Fargate と何が違うのか？ - How elegant the tech world is...!

チェック

  • [ ] 本文を確認した
  • [ ] 概要を確認した
  • [ ] タグを確認した
  • [ ] inbox/ 直下へ移行した

概要

Amazon ECS Managed Instanceは AWS Fargate と何が違うのか？ - How elegant the tech world is...! のWebクリップ。本文からGo、AWS、Observability、設計、キャリア評価などの学習材料として使えそうな内容を保存した。関連タグ: architecture, aws, infra/aws, web-clip。

本文

How elegant the tech world is...!

この広告は、90日以上更新していないブログに表示しています。

Amazon ECS Managed Instanceは AWS Fargate と何が違うのか？

はじめに

iselegantです。

今日は2025年9月30日(US時間)に発表されたAmazon ECS Managed Instance(以降、ECSマネージドインスタンス)について、その全容とFargateとの違いの観点から特徴を解説していきたいと思います。 ECSにおけるコンピューティングの選択肢として、これまではEC2もしくはFargateのいずれかから選択可能でした。 ECSマネージドインスタンスの登場により、選択肢が3つとなったわけですが、EC2とFargate両者のメリットを享受できるバランスの良い選択肢という位置づけです。

EC2インスタンス自体はAWSの持ち物

ECSマネージドインスタンスを選択すると、ECSタスクを起動させるために、まずEC2インスタンスが起動します。 これ自体は、今までのECS on EC2と変わりません。 ただ、このEC2インスタンスはAWS側の責務で運用される、という点が異なります。

ECSマネージドインスタンスの基本的な考え方は、Well-Architectedの一部観点(運用・セキュリティ・信頼性・パフォーマンス・コスト)と照らし合わせると比較的わかりやすいかと思うので、これらの観点に沿いながら、まずはざっと概要を理解していきましょう。

運用・セキュリティはAWS側の責務

前述の通り、EC2インスタンス自体が「AWSの持ち物」になります。 このインスタンスはAWS側がセキュリティ対策を施したものが利用されます。 そのため、ユーザー側はそのOSレイヤーに介入することができません。 具体的には、以下のような運用においては、ユーザー側は関与することができません。

  • インスタンスへのSSHアクセス

  • ルートファイルシステムの変更

  • カスタムAMIの利用

また、起動されたインスタンスのOS・セキュリティの状態を一定に保つため、Bottlerocketをベースとし、定期的なパッチ適用でOSが自動保守されます。 この制約を受け、14日毎にVMインスタンスが再起動されます。そのため、その上で稼働するECSタスクも定期的に入れ替えが必要となります。

可用性・パフォーマンス・コスト最適化の考慮は一部ユーザー側の範囲

EC2インスタンス自体の運用・セキュリティがAWS側の責任である一方、可用性・パフォーマンス・コスト管理に関して、一部はユーザー側の責務です。 順番に特徴を見ていきましょう。

可用性

可用性の一つの観点として、「EC2インスタンスをどのAZで起動させるか？」といった点はユーザーが責務を持ちます。 これはECS on EC2やFargateと変わらず、ECSタスクが起動する先として、事前にサブネットを指定する必要があります。 ただ、マルチAZでサブネットを指定すれば、スケーリング時にAWSがベストエフォートでAZに分散配置してくれます。

ここで一つポイントとなるのが、ECSタスクのスケーリング時における、EC2インスタンス自体のAZ分散の挙動です。 筆者の検証結果を元に、スケーリングされるときの挙動をStep別で見ていきましょう。

まず、次のように、ECSサービスからECSタスクを起動することを考えます。

ECSタスク数を1として起動すると、まずはECSタスクの起動に必要なEC2インスタンスが起動します。

そして、その上でECSタスクが起動します。

ここまでの流れは特に違和感ないでしょう。 次がポイントとなりますが、ECSタスク数を2にすると、リソースが許す限り、同一のEC2インスタンス上に起動しようとします。

つまり、ECSがマルチAZを重視して新規のEC2インスタンスが起動するのではなく、集約（=コスト最適化）の観点が優先されて、起動していく動きとなります。 そして、更にECSタスク数を3とすると、

まだEC2インスタンスのリソースに余裕があるので、また同じEC2インスタンス上にECSタスクが起動しました。 では更にECSタスク数を4にしましょう。

今度はEC2インスタンスのリソースでは乗り切らないもしくは逼迫すると判断され、ここで初めて別のAZ側にEC2インスタンスが起動し、そちら側でECSタスクが起動しました。 ここで、集約数が高いEC2インスタンス上のECSタスクを１つ停止してみましょう。

ECSタスク数は4に維持しようとするため、ECSタスクは再度起動しますが、全体のAZ分散の状況を考慮して、比較的余裕のあるEC2インスタンス側にてECSタスクが起動されました。

このように、詳細なスケーリングの動作内容は現時点で公開されていないものの、ECSタスクの起動に関して、最初は集約を意識しながらも、マルチAZが考慮されていく動きとなります。

パフォーマンス

パフォーマンス観点では、稼働するEC2インスタンスのスケーリング運用はAWS側にて行われますが、どのようなインスタンスタイプを用いるかはユーザー側でコントロール可能です。 ECSマネージドインスタンスでは、このインスタンスタイプやスケールの動きをキャパシティプロバイダーにて制御するのですが、大きく2つの選択肢があります。

まず１つ目がデフォルトキャパシティプロバイダーです。 これは、AWS自身がECSタスクで要求されるコンピューティングリソースをよしなに考慮しながら、汎用インスタンスタイプを中心にスケールをコントロールするパターンです。 いわゆる万能型の位置づけであり、一般的なWebアプリケーションのようなユースケースはこちらで概ねカバーできるでしょう。

そして2つ目がカスタムキャパシティプロバイダーです。 こちらは、ユーザー自身が、CPUやメモリの最小/最大、インスタンスタイプ、インスタンスの特徴を指定し、その条件下でAWSがスケールをコントロールするパターンです。 デフォルトキャパシティプロバイダーと比較して、コンピューティングの運用に対する抽象度は下がります。 一方、GPUを利用したいといったような、特定のニーズに応えることができます。

図で表すと、次のように整理できます。

ちなみに、ECSクラスターには複数のプロバイダーを定義することが可能です。 つまり、ECSマネージドインスタンスで利用されるこれら２つのキャパシティプロバイダーに加え、同一のECSクラスターにFargate用キャパシティプロバイダーも混ぜ込むことができます。

ECSサービスやECSタスク毎のニーズに合わせて、どのキャパシティプロバイダーに基づいてリソースを割り当てるか定められるため、より選択肢が広がったと言えますね。

コスト最適化

c6g

一方、ECSインスタンス上のECSタスク集約数が多くなると、規模の経済が働き、コスト差は小さくなります。

EC2とFargateを比較した際の費用対効果の考え方として、少し前の記事になりますが、Newspicks CTO 安藤さんがブログで公開してくれているので、気になるかたはこちらも参照にされると良いと思います。

tech.uzabase.com

Fargateとの比較による違い

基本スタンス：コンピューティング要件の柔軟さ

「AWS側の責務で運用されるのであれば、”マネージドなコンピューティング”という意味でFargateと同じなのでは？使い分けはどうするの？」と考える方もいるかも知れません。

EC2マネージドインスタンスとFargateを比較検討する際の基本スタンスとしては、EC2インスタンス管理自体の責務はAWS側に委ねたいが、コンピューティング要件に柔軟さを求めるか、という点がポイントになります。 前述の通り、ECSマネージドインスタンスはインスタンスタイプ自体を自分たちでコントロールできます。 そのため、GPUの利用やネットワークパフォーマンスといった、特定のリソース要件に対して、マネージドな選択肢が増えたと考えると良いでしょう。

一部構成上の制約

現状では、ECSマネージドインスタンス上のECSサービスにおいてはService Connectがサポートされていません。 そのため、ECSサービス間の接続関しては、ALB / NLB / GWLBによる接続、もしくはCloud Mapを利用したサービスディスカバリによる接続のいずれかになります。

セキュリティレベル

FargateはFirecrackerと呼ばれるマイクロVMをベースに、ECSタスク毎にコンピューティングリソースが用意されます。 一方、ECSマネージドインスタンス側は、あくまでもEC2のVMをベースに、複数のECSタスクが集約起動される形でコンピューティングリソースが用意されます。 ECSタスクレベルでワークロードを厳密に分離したい要件がある場合、Fargateのほうが適切でしょう。

イメージキャッシュとトータルの起動時間

FargateはECSタスク毎に起動するため、コンテナデプロイ時にイメージキャッシュが効かないという制約がありました。 一方、ECSマネージドインスタンスでは、EC2がベースとなります。 コンピューティング部分がEC2となる場合、イメージキャッシュが働きます。 そのため、同一のインスタンスで同一のコンテナが起動する際は、キャッシュが利用され、コンテナの起動がより早くなります。

他方、ECSマネージドインスタンスでは、コンピューティングリソースが不足した場合、追加のEC2インスタンス起動が必要となるため、その分の起動時間オーバーヘッドは発生します。

タスクの入れ替え

ECSマネージドインスタンスでは、VMインスタンスのセキュリティ状態を維持するため、最大14日後にECSタスクの入れ替えが必要になります。 一方、FargateにもECSタスクの入れ替えは不定期に発生しますが、ECSマネージドインスタンスほど頻繁に発生しません（筆者の経験上、数カ月に1度程度）。 Fargateを採用しているアプリケーションでは、ECSタスクの入れ替え自体が許容できるケースが多いですが、この14日毎という定期的な運用サイクルに耐えられるか、というの一つの判断ポイントになります。

料金体系

FargateはECSタスクのCPU/メモリといったコンピューティングリソースに対して料金が発生します。 一方、ECSマネージドインスタンスは、起動するVMインスタンスタイプに応じた料金が発生します。

先程言及した通り、EC2インスタンスで稼働するECSタスクの集約数が多いほど、ECSマネージドインスタンス側の料金が費用対効果が高まります。 仮にデフォルトプロバイダーを選択した場合、インスタンスタイプの選定やECSタスクの稼働対象インスタンスはAWSがハンドリングするため、自然とコスト観点で最適化される挙動となるでしょう。

ECSマネージドインスタンスを利用する際のIAM権限周り

EC2インスタンスの運用をAWS側に委ねることになるので、必要なIAM権限をAWS、すなわちEC2に対してインスタンスプロファイルとして渡さなければなりません。 EC2ではインフラストラクチャ IAMロールと呼ばれるIAMの種別があります。 これは、ECS自体がクラスター内部のリソース管理を行うために必要な権限となります。 このインフラストラクチャロールとしてECSマネージドインスタンス用のAWS管理ポリシーを与えつつ、AWSが運用で必要なIAMロールがEC2が使えるようにiam:PassRoleで伝搬させて上げる仕組みが必要です。

このあたりは次のドキュメントを参照することで詳細を確認できますが、初見は少しわかりにくいので、こちらの図で仕組みを頭に入れておくと、設定にハマったときに問題特定しやすいと思います。

Amazon ECS infrastructure IAM role - Amazon Elastic Container Service

Amazon ECS Managed Instances instance profile - Amazon Elastic Container Service

その他、運用上のTips

ECSマネージドインスタンスでは、EC2の管理責務自体をAWSが担うものの、ユーザーはAWSマネジメントコンソール上からはEC2インスタンスの稼働状況を確認可能です。 利用可能なオプションは限定的ですが、EC2のダッシュボード上からEC2インスタンス自体のシステムログが確認できます。

IAM関連のトラブルシューティング時には、こちらのログを見ないと特定しずらいケースもあるので、覚えておくと良いでしょう。

まとめ

いかがでしたでしょうか？

今回はECSマネージドインスタンスに関して、W-Aアーキテクチャの観点からその特徴とFargateとの差異に関して解説しました。 筆者も実際の環境で利用してみたのですが、IAM設定周りのみ構築時にクリアできれば、要件に合わせた選択肢の幅が広がったこともあり、なかなか使い勝手が良い印象を受けました。 ちなみにAWS公式ドキュメント上では、実はFargateよりもECSマネージドインスタンスの利用を推奨していたりします。

Amazon ECS offers three infrastructure types for your clusters. Choose the type that best matches your workload requirements, operational preferences, and cost optimization goals:

Amazon ECS Managed Instances (Recommended)

Amazon ECS clusters - Amazon Elastic Container Service

ECSマネージドインスタンスは、パフォーマンスやコスト、AWS側への管理責任の委譲などの面から、バランスの良いオプションです。 いずれにしても、キャパシティプロバイダーを組み合わせることで、ニーズに併せてECSタスク稼働させることができます。 ECSを利用されているエンジニアの方々は、今後のアーキテクチャの選択肢として、ぜひ理解しておくと良いでしょう。

本ブログが皆さまの理解の手助けになれば幸いです。 では、また！

Masaya ARAI I ♥ AWS, Golang, Terraform, UI/UX 2020 APN AWS Top Engineers

  • はてなブログ

  • ブログをはじめる

  • 週刊はてなブログ

  • はてなブログPro

  • Amazon ECS Managed Instanceは AWS Fargate と何が違うのか？

  • Amazon ECS Blue/Green Deploymentは既存のCodeDeploy方式と何が違うのか？

  • 技術書典#16向けに 「The Cloud Run (Google Cloudコンテナ設計本)」を執筆しました

  • AWS側の目線から理解する、Google Cloud ロードバランサの世界

  • AWS App Runnerの正体を探る

  • 2025 / 10

  • 2025 / 8

  • 2024 / 5

  • 2024 / 1

  • 2022 / 12

  • 2022 / 9

  • 2022 / 3

  • 2021 / 12

  • 2021 / 10

  • 2021 / 7

  • 2021 / 6

  • 2021 / 5

  • 2020 / 12

  • 2020 / 9

  • 2020 / 7

  • 2020 / 6

  • 2020 / 5

  • 2020 / 3

引用をストックしました

引用するにはまずログインしてください

引用をストックできませんでした。再度お試しください

限定公開記事のため引用できません。

要点

  • AWS運用、保守、ECS/Fargate/CloudFrontなどの実務Tipsとして確認する。
  • 元URL: https://iselegant.hatenablog.com/entry/2025/10/03/120315

タグ

architecture #aws #infra/aws #web-clip