--- title: "AWS Fargateとは？ECSのEC2起動タイプとの違い・料金・設定例を解説【2026年版】" url: "https://www.issoh.co.jp/tech/details/3304/" published: 2024-08-07 updated: 2026-10-11 categories: ["AWS"] publisher: "株式会社一創" --- # AWS Fargateとは？ECSのEC2起動タイプとの違い・料金・設定例を解説【2026年版】 AWS Fargateとは、サーバーやクラスターのインスタンスを自分で管理せずにコンテナを実行できる、AWSのサーバーレスなコンピューティングエンジンです。Amazon ECSでコンテナを動かすときは「EC2起動タイプ（自分でEC2インスタンスを持つ）」か「Fargate（AWSに実行基盤を任せる）」を選ぶことになり、「ECSとEC2の違い」「ECSのEC2とFargateの違い」で迷う人の多くがこの分岐点に立っています。本記事では、Fargateの仕組みから、EC2起動タイプとの管理範囲・ネットワーク・課金の違い、東京リージョンの実単価で計算した損益分岐、1つのタスク定義を両方で動かす設定例、ECS Managed Instancesを含めた選び方までを、実装者の目線で整理します。 ## まとめ：ECSのEC2起動タイプとFargateの違いは「誰がサーバーを持つか」 先に結論を押さえておきましょう。AWS Fargateは「コンテナの実行基盤（データプレーン）をAWSに任せられるサーバーレス方式」です。要点は次のとおりです。 - **立ち位置**：Fargateは単独のサービスではなく、Amazon ECSやAmazon EKSの**起動タイプ（実行方式）**の一つ。コンテナの管理はECS/EKSが担い、Fargateが実行環境を提供します。そもそもECSとEC2は層が違い、ECSは「コンテナの指揮役」、EC2は「仮想サーバー」です。 - **EC2起動タイプとの違い**：EC2起動タイプはインスタンスを自分で持ち、OSパッチやスケーリングも自分で運用します。Fargateは必要なvCPUとメモリをタスクごとに指定するだけで、ホストに触れません。ネットワークモードも`awsvpc`に固定されます。 - **料金**：使ったvCPUとメモリに対して**秒単位（Linuxは最低1分）**で課金。東京リージョンの単価で比べると、同じvCPU・メモリ量ならEC2のほうが1割ほど安く、**インスタンスの9割前後までタスクを詰め込めるならEC2、それ以下ならFargateが安い**のが目安です（2026年10月時点の単価で試算）。 - **第3の選択肢**：2025年に加わった**ECS Managed Instances**は、EC2インスタンスの種類を選べるままAWSがパッチや入れ替えを代行する中間の方式。GPUや特権が必要でも運用は減らしたい場合の受け皿です。 - **向く用途**：Fargateは負荷が変動するWebアプリ、マイクロサービス、バッチ、イベント駆動処理など、起動と停止が多いワークロード。24時間高負荷・GPU・特殊なカーネル設定が要るならEC2起動タイプかManaged Instancesを選びます。 以降で、仕組み・違い・設定・料金・選び方の順に掘り下げていきます。 ## AWS Fargateとは：サーバーを持たずにECSやEKSのコンテナを動かす仕組み Fargate（ファーゲート）は、2017年にAWSが提供を開始したコンテナ向けのサーバーレスコンピューティングエンジンです。コンテナを動かすには本来、コンテナを載せるサーバー（ホスト）を用意し、OSのパッチ当てやスケーリングを運用する必要があります。Fargateはこの「サーバーを用意して管理する」部分をAWSが肩代わりするため、利用者はコンテナイメージと必要なリソース量を指定するだけで実行できます。 ### コントロールプレーンとデータプレーンで見るFargateの立ち位置 コンテナの実行基盤を役割で分けると、コンテナを管理・指揮する役割を**コントロールプレーン**、コンテナが実際に動く実行環境を**データプレーン**と呼びます。Amazon ECSやAmazon EKSがコントロールプレーン（オーケストレーション）を担い、その下でコンテナを動かすデータプレーンとして「EC2」か「Fargate」を選びます。つまりFargateは、ECS/EKSと組み合わせて初めて機能する実行基盤であり、単体で完結するサービスではありません。AWSの公式ドキュメントでも、ECSのクラスターが使うインフラは[ECS Managed Instances・Fargate・EC2インスタンスの3種類](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-configuration.html)として整理されています。 ### Fargateを構成するタスク定義・タスク・サービスの3要素と役割 ECS on Fargateを例にすると、主な登場人物は次の3つです。**タスク定義**は、使用するコンテナイメージ・CPU/メモリ・環境変数・ネットワーク設定などを記述したJSON形式の設計図です。**タスク**は、そのタスク定義をもとに実際に起動したコンテナの集まりを指します。**サービス**は、指定した数のタスクが常に動き続けるよう維持し、ロードバランサーやオートスケーリングとの連携を担う仕組みです。利用者はクラスター（実行基盤）の中身を意識せず、これらの定義だけを管理すれば済みます。 ## ECSとEC2の違い：オーケストレーターと仮想サーバーはそもそも別の層 「ECS EC2 違い」と検索する人の疑問は、大きく2つに分かれます。1つは「ECSとEC2はそもそも何が違うのか」、もう1つは「ECSで動かすとき、EC2起動タイプとFargateのどちらにするか」です。前者から整理します。 Amazon EC2は、CPU・メモリ・ディスクを持つ**仮想サーバー**を時間単位で借りるサービスです。OSを選び、ミドルウェアを入れ、アプリを動かすところまで利用者が面倒を見ます。一方のAmazon ECSは、**コンテナをどのサーバーに何個配置し、落ちたら入れ替えるか**を決めるオーケストレーションのサービスで、ECS自体は計算資源を持ちません。そのため、ECSを使うときは「コンテナを載せる計算資源」を別に用意する必要があり、その候補がEC2インスタンスとFargateというわけです。 つまり「ECSかEC2か」は二者択一ではなく、**EC2の上でECSを使う**（EC2起動タイプ）という組み合わせが普通に成り立ちます。EC2単体でDockerを動かす構成と比べると、ECSを挟むことでデプロイ・ヘルスチェック・台数維持・ロードバランサー登録を自動で行う構成にできるのが違いです。EC2そのものの仕組みやインスタンスタイプ、料金モデルは[Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断](https://www.issoh.co.jp/tech/details/15424/)で、インスタンスの絞り込み方は[AWSのインスタンスタイプの選び方](https://www.issoh.co.jp/tech/details/17679/)で解説しています。ECS全体の始め方とDockerイメージを動かす手順は[ECSでDockerコンテナを動かす手順：ECRへのpush・タスク定義・料金とEKSとの違い](https://www.issoh.co.jp/tech/details/3870/)にまとめました。 ## ECSのEC2起動タイプとFargateの違いを管理範囲と課金単位で比較する ECS/EKSでコンテナを動かすとき、最初に判断するのが「Fargateで動かすか、EC2インスタンス上で動かすか」です。両者は同じコンテナイメージを動かせますが、責任範囲とコスト構造、そして設定できる項目が異なります。 | 比較項目 | Fargate起動タイプ | EC2起動タイプ | | ---------- | --------------- | ------------------- | | サーバー管理 | 不要（AWSが管理） | 必要（自分で管理） | | OSパッチ適用 | AWS側で実施 | 利用者が実施 | | リソース指定 | タスクごとにvCPU・メモリ | インスタンスタイプ単位 | | 最大サイズ | 32vCPU・244GB | インスタンスタイプ次第 | | 課金対象 | タスクのvCPU/メモリ（秒） | 起動中のインスタンス | | ネットワークモード | awsvpcのみ | awsvpc・bridge・host等 | | ホストへのSSH | 不可 | 可 | | GPU・特権コンテナ | 不可 | 可 | | デーモン型の常駐 | サイドカーで代替 | DAEMONで1台1個 | | 定常負荷のコスト | 割高になりやすい | 安くしやすい | | 変動負荷のコスト | 無駄が出にくい | 余剰が出やすい | | 運用負荷 | 小さい | 大きい | ざっくり言えば、**運用の手間を減らしたいならFargate、コストを突き詰めたい定常負荷ならEC2**という住み分けです。EC2起動タイプはリザーブドインスタンスやSavings Plans、スポットインスタンスと組み合わせやすく、1台に複数タスクを詰め込めるため、24時間365日動かし続ける大規模アプリではコストパフォーマンスが上回ることが少なくありません。一方、夜間や週末に止められるワークロードや、急なスパイクに合わせて増減させたい場合は、アイドル時間に課金されにくいFargateが有利です。なお単価だけを見るとEC2が安く見えても、インスタンスの運用・保守にかかる人件費まで含めた総所有コスト（TCO）で比べると、Fargateのほうが安上がりになるケースも珍しくありません。 ### ネットワークモードとタスク定義パラメータで変わる設定上の違い 設定面で最初にぶつかる違いはネットワークです。[Fargateのタスクは常にawsvpcネットワークモード](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html)で動き、タスクごとに専用のENI（Elastic Network Interface）とプライベートIPが割り当てられます。ロードバランサーのターゲットグループも、インスタンスではなく**IPターゲット**を指定して作成する必要がある点にも注意が必要です。対してEC2起動タイプでは、[awsvpcのほかにbridge・host・none](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html)を選べ、Linuxでネットワークモードを省略するとbridgeになります。EC2時代のタスク定義をそのままFargateへ持っていくと、ここで登録エラーになるのが典型的な詰まりどころです。 タスク定義のパラメータにも差があります。Fargateでは`privileged`・`gpu`・`links`・`placementConstraints`・`dnsServers`などが無効で、Linuxのcapabilityとして追加できるのは`CAP_SYS_PTRACE`だけです。CPUとメモリは**タスク単位で必ず指定**し、組み合わせも決まっています。たとえば0.25vCPUなら512MiB〜2GB、1vCPUなら2〜8GB、4vCPUなら8〜30GBで、プラットフォームバージョン1.4.0以降のLinuxでは32vCPU（60GB・120GB・244GB）まで選べます（2026年10月時点の公式ドキュメント）。 ### 2025年に加わった第3の選択肢ECS Managed Instancesの位置づけ 2025年9月には、FargateとEC2起動タイプの中間にあたる[Amazon ECS Managed Instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ManagedInstances.html)の提供が始まりました。EC2インスタンスは自分のアカウント内で起動されますが、インスタンスの選定・起動・パッチ適用・入れ替えはAWSが担います。インスタンスは14日で自動的にドレインされて新しいものに置き換わり、SSHはできません。その代わり、GPUを積んだインスタンスや特定のCPUを指定でき、`CAP_NET_ADMIN`などの特権capabilityも有効にできます。課金はタスクではなく**インスタンス単位**で、複数タスクを1台に詰めて使う前提です。既存のFargate用タスク定義（プラットフォームバージョン1.4.0）とも互換があるため、「Fargateでは仕様が足りないが、EC2の運用は持ちたくない」場合の受け皿になります。 ## タスク定義とCLIで起動タイプを切り替える：FargateとEC2の設定例 違いを理解したら、実際に手を動かして確かめるのが早道です。ここでは1つのタスク定義をFargateとEC2の両方で動かせるように書き、CLIで起動タイプを切り替えます。AWS CLI v2が設定済みで、ECSクラスター「demo」と、プライベートサブネット・セキュリティグループ・タスク実行ロールが用意されている前提です（IDは例なので自分の環境の値に置き換えてください）。 ### 1つのタスク定義をFargateとEC2の両方で動かすための書き方 ポイントは3つあります。`requiresCompatibilities`に`FARGATE`と`EC2`の両方を書くこと、ネットワークモードをawsvpcにすること、CPUとメモリをタスク単位でFargateの有効な組み合わせにすることです。この3点を満たせば、同じリビジョンをどちらの起動タイプでも起動できます。 ``` { "family": "web-app", "requiresCompatibilities": ["FARGATE", "EC2"], "networkMode": "awsvpc", "cpu": "512", "memory": "1024", "runtimePlatform": { "operatingSystemFamily": "LINUX", "cpuArchitecture": "X86_64" }, "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole", "containerDefinitions": [ { "name": "web", "image": "public.ecr.aws/nginx/nginx:stable", "essential": true, "stopTimeout": 60, "portMappings": [{ "containerPort": 80, "protocol": "tcp" }], "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-group": "/ecs/web-app", "awslogs-region": "ap-northeast-1", "awslogs-stream-prefix": "web", "awslogs-create-group": "true" } } } ] } ``` このJSONを`taskdef.json`として保存し、登録してから起動タイプを指定して実行します。[aws ecs run-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html)の`--launch-type`を書き換えるだけで、同じタスク定義の実行先が変わります。 ``` # タスク定義を登録する aws ecs register-task-definition --cli-input-json file://taskdef.json # Fargateで1タスク起動する（awsvpcなのでサブネットとSGの指定が必須） aws ecs run-task --cluster demo --launch-type FARGATE \ --task-definition web-app \ --network-configuration "awsvpcConfiguration={subnets=[subnet-0aaa1111bbbb2222c],securityGroups=[sg-0ccc3333dddd4444e],assignPublicIp=DISABLED}" # 同じタスク定義をEC2起動タイプで起動する（クラスターにコンテナインスタンスが登録済みであること） aws ecs run-task --cluster demo --launch-type EC2 \ --task-definition web-app \ --network-configuration "awsvpcConfiguration={subnets=[subnet-0aaa1111bbbb2222c],securityGroups=[sg-0ccc3333dddd4444e]}" # どちらで動いているかを確認する aws ecs describe-tasks --cluster demo --tasks TASK_ID \ --query "tasks[0].[launchType,cpu,memory,lastStatus]" ``` EC2起動タイプでawsvpcを使う場合、1台あたりに付けられるENIの数がインスタンスタイプで決まるため、小さいインスタンスでは配置できるタスク数がENIで頭打ちになります。対象のインスタンスタイプがawsvpcトランキングに対応していれば、アカウント設定でENIの上限を引き上げられます。EC2側でbridgeモードを使い続けたい場合は、タスク定義をFargate用と分けるのが素直です。 ### Fargate SpotとFargateを混ぜるキャパシティプロバイダ戦略の例 常駐サービスでも、一部を[Fargate Spot](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-capacity-providers.html)に載せると費用を下げられます。次の例は、最低1タスクを通常のFargateで確保し、それを超える分を1対3の比率でFargate Spotに寄せる設定です。 ``` # クラスターにFARGATEとFARGATE_SPOTを関連付ける aws ecs put-cluster-capacity-providers --cluster demo \ --capacity-providers FARGATE FARGATE_SPOT \ --default-capacity-provider-strategy capacityProvider=FARGATE,weight=1 # base=1を通常のFargateで確保し、残りをFargate:Spot=1:3で配分する aws ecs create-service --cluster demo --service-name web \ --task-definition web-app --desired-count 5 \ --capacity-provider-strategy capacityProvider=FARGATE,base=1,weight=1 capacityProvider=FARGATE_SPOT,weight=3 \ --network-configuration "awsvpcConfiguration={subnets=[subnet-0aaa1111bbbb2222c],securityGroups=[sg-0ccc3333dddd4444e],assignPublicIp=DISABLED}" ``` Fargate Spotのタスクは、AWSが容量を回収するときに**2分前の通知**（EventBridgeのタスク状態変更イベントと、コンテナへのSIGTERM）を受けてから停止されます。タスク定義の`stopTimeout`は最大120秒まで延ばせるので、SIGTERMを受けたら処理中のリクエストを捌き切って終了するようアプリ側を作っておきます。なお、1つのキャパシティプロバイダ戦略にFargate系とAuto Scalingグループ（EC2）系を混在させることはできず、FargateのサービスをEC2のキャパシティプロバイダへ更新することもできません。両方を試すなら、サービスを分けて作るのが確実です。 ## ECS on FargateとEKS on Fargate：管理・制約の違い 「FargateとECSの違いは？」という疑問も多いですが、両者は対立するサービスではなく**役割が異なる**と理解するのが正確です。ECS（またはEKS）が「どのコンテナを、いくつ、どこで動かすか」を管理し、Fargateは「実際にコンテナを動かす場所」を提供します。ECS・EKS・Fargate・Lambdaを横並びで比べた全体像は[AWSのコンテナサービス比較｜ECS・EKS・Fargate・Lambdaの選び方](https://www.issoh.co.jp/tech/details/17869/)で整理しています。 ### ECS on Fargateの構成とExpress Modeによる最短の公開手順 Amazon ECSはAWS独自のコンテナオーケストレーションサービスで、Dockerコンテナのデプロイ・スケーリング・障害復旧を自動化します。そのデータプレーンとしてFargateを選ぶ構成が「ECS on Fargate」です。タスク定義で起動タイプにFargateを指定するだけで、必要なリソースがその都度プロビジョニングされます。さらに、ロードバランサーやオートスケーリングまで一度に用意する[ECS Express Modeの使い方と料金](https://www.issoh.co.jp/tech/details/9958/)を使えば、コンテナイメージとIAMロールを渡すだけでFargateベースの公開環境が立ち上がります。イメージの置き場所となるECRの料金やpush手順は[Amazon ECRとは？料金・ECSとの違いとDockerイメージのpush手順](https://www.issoh.co.jp/tech/details/2667/)を参照してください。 ### EKS on Fargateで使えない機能：DaemonSet・GPU・Armの制約 Amazon EKSはKubernetesをマネージドで提供するサービスです。2019年にFargate対応が追加され、Kubernetesのポッドをノード（EC2インスタンス）なしで実行できるようになりました。ノードが存在しないため、ノード管理やSSH/SSMアクセスといった概念がなくなり、運用が大きく簡素化されます。ただし制約はECS on Fargateより多く、[EKSの公式ドキュメント](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html)では、DaemonSet・特権コンテナ・HostPort/HostNetwork・GPU・Armプロセッサ・Windowsコンテナ・EBSボリューム・Fargate Spotがいずれも非対応とされています（2026年10月時点）。ポッドはプライベートサブネットでしか動かず、Fargateプロファイルに一致しないポッドはPendingのまま止まります。Kubernetesでの選択肢は[EKS Auto ModeとEKS on Fargateの違い｜制約一覧・料金の分岐点](https://www.issoh.co.jp/tech/details/4524/)で詳しく比べています。 ## Lambda・App Runnerの使い分けと2026年の新規受付停止 AWSにはFargate以外にもサーバーレスでコードを動かす選択肢があります。代表的なのがAWS LambdaとAWS App Runnerです。どれも「サーバー管理が不要」という点は共通しますが、得意な領域が異なります。 | サービス | 実行単位 | 得意な用途 | 実行時間 | 新規採用 | | ---------- | -------- | ----------- | ------- | ------- | | Fargate | コンテナ | 常駐サービス・バッチ | 長時間も可 | 可 | | Lambda | 関数 | 短時間のイベント処理 | 1回最大15分 | 可 | | App Runner | コンテナ/コード | Webアプリの即時公開 | 常駐 | 新規顧客は不可 | イベントに応じて短時間だけ処理を走らせたいならLambda、コンテナをそのまま常駐させて細かく制御したいならFargate、という整理が基本です。以前は「設定を最小限にしてWebアプリを手早く公開したいならApp Runner」が定番でしたが、[App Runnerは新規顧客の受付を停止](https://docs.aws.amazon.com/apprunner/latest/dg/apprunner-availability-change.html)し、既存顧客は引き続き使えるものの新機能の追加予定はないと公表されています。AWSが移行先として案内しているのはECS Express Modeで、その実体はFargate上のECSサービスです。経緯と移行の進め方は[AWS App Runnerは終了する？新規受付停止と移行先](https://www.issoh.co.jp/tech/details/7023/)で解説しています。FargateはVPC構成やサイドカー、マルチコンテナなど複雑な構成に対応できる柔軟性が強みです。 ## Fargateの料金の仕組みと東京リージョン単価・コストを下げる方法 Fargateの料金は、**要求したvCPUとメモリの量×使用時間**で決まります。コンテナイメージの取得を開始した時点からタスクが終了するまでが計算対象で、[公式の料金ページ](https://aws.amazon.com/fargate/pricing/)によればLinuxは秒単位（最低1分）、Windowsは秒単位（最低5分）で課金されます。 ### vCPU・メモリ・エフェメラルストレージの3要素と東京リージョン単価 主な課金要素は、**vCPU**、**メモリ**、そして**追加のエフェメラルストレージ**の3つです。エフェメラルストレージは既定で20GBが無料で付与され、それを超える分が課金対象になります。AWSのPrice List APIで取得した東京リージョン（ap-northeast-1）のオンデマンド単価は次のとおりです（2026年9月11日公開版のデータ。単価は改定されるため、契約前に料金ページで確認してください）。 | 課金要素 | Linux/x86 | Linux/ARM | | ---------------- | ---------- | ---------- | | vCPU（1vCPU・1時間） | 0.05056ドル | 0.04045ドル | | メモリ（1GB・1時間） | 0.00553ドル | 0.00442ドル | | 追加ストレージ（1GB・1時間） | 0.000133ドル | 0.000133ドル | たとえば1vCPU・2GBのタスクを1か月（730時間）動かし続けると、(0.05056＋0.00553×2)×730で**約45ドル**です。0.5vCPU・1GBの小さなタスクなら約22.5ドルになります。Windowsコンテナはこれとは別に、vCPUあたり0.046ドル/時のOSライセンス料が上乗せされます。為替や単価改定で変わる点に留意してください。 ### EC2起動タイプと同じ構成で比べた東京リージョンの月額試算と損益分岐の目安 では、EC2起動タイプと比べてどれだけ差があるのでしょうか。同じ東京リージョンのLinuxオンデマンド単価（料金ページの公開データ・2026年10月9日更新）で、2vCPU・8GiBのインスタンスと、同じ量をFargateで確保した場合を比べました。 | 構成（2vCPU・8GB） | 1時間あたり | 730時間あたり | | ------------------ | --------- | -------- | | EC2 m7i.large（x86） | 0.1302ドル | 約95.0ドル | | Fargate x86で同量 | 0.14536ドル | 約106.1ドル | | EC2 m7g.large（ARM） | 0.1054ドル | 約76.9ドル | | Fargate ARMで同量 | 0.11626ドル | 約84.9ドル | x86でもARMでも、**EC2はFargateの約9割の価格**です（0.1302÷0.14536≒0.90、0.1054÷0.11626≒0.91）。ここから読み取れる判断基準はシンプルで、EC2インスタンスの資源のうち**およそ9割以上をタスクで埋め続けられるならEC2起動タイプが安く、それを下回るならFargateが安い**ということです。実際には、OSやECSエージェントが使う分だけタスクに割り当てられるメモリは8GiBより少なくなり、デプロイ時の入れ替え用の空きや、AZ分散のための余裕も必要です。たとえば0.5vCPU・1GBのタスクを4つ動かす場合、Fargateなら約90ドル/月で、m7i.large 1台（約95ドル/月）より安くなります。EC2が逆転するのは、タスク数が多く詰め込みが効く大規模構成か、後述のSavings Plansを深く掛けられる場合です。 ### NAT Gateway・CloudWatch Logsなど見落としやすい周辺コスト Fargateの請求額が見積もりを上回る典型的な原因は、コンピュート以外の周辺コストです。プライベートサブネットのタスクがイメージ取得やAWS API呼び出しのために通る**NAT Gateway**のデータ処理料、**CloudWatch Logs**のログ取り込み料、インターネットへの**アウトバウンドデータ転送料**、イメージ配信の**Amazon ECR**などが積み重なり、総額が大きく膨らむことがあります。ECRからのイメージ取得やS3・CloudWatch Logsへの通信をVPCエンドポイント経由にする、ログの冗長出力を抑えるといった工夫が効果的です。NAT GatewayとVPCエンドポイントの損益分岐は[VPCエンドポイントとは｜2種類の違いとNATゲートウェイとの料金比較](https://www.issoh.co.jp/tech/details/2326/)で試算しています。 ### タスクサイズ・Savings Plans・Spot・Gravitonの4つの節約策 第一に**タスクサイズの見直し**です。実使用量に対して過剰なCPU/メモリを割り当てないだけで無駄を削れます。CloudWatch Container Insightsで実使用率を見て、1段小さい組み合わせに落とせないか確かめましょう。第二に**Compute Savings Plans**で、1年または3年の利用をコミットすると、料金ページの表記で**Fargateは最大50%**の割引になります。EC2 Instance Savings Plansのほうが割引率は大きいため、長期の定常負荷ではEC2起動タイプとの差がさらに開く点は押さえておきたいところです。東京リージョンでの実割引率は[AWS Savings Plansの選び方と購入手順｜東京の実割引率](https://www.issoh.co.jp/tech/details/17992/)で比較しています。第三に**Fargate Spot**で、中断を許容できるバッチや非同期処理に使う場合、最大70%の料金削減が可能です。第四に**AWS Gravitonプロセッサ（ARM）**への切り替えで、上の単価表のとおりvCPU・メモリとも東京でx86より2割安く動かせます。なお、Fargate上でのWindowsコンテナとARMはECS on Fargateでのみ利用でき、EKS on Fargateでは非対応です（EKSでもEC2のGravitonノードを使えばARMは利用できます）。 ## Fargateのセキュリティと運用：IAMロール分離・ENI・イメージスキャン Fargateはホストの管理をAWSに任せられますが、「セキュリティを何も考えなくてよい」わけではありません。責任共有モデルにおいて、コンテナイメージの中身やアプリケーションの設定は利用者の責任範囲です。 運用の基本は次のとおりです。**IAMの最小権限**では、ECRからのイメージ取得やログ出力に使う「タスク実行ロール」と、アプリがS3などにアクセスするための「タスクロール」を分けて、必要最小限の権限だけを付与します。**ネットワーク分離**では、各タスクが専用のENIを持つため、VPC・サブネット・セキュリティグループでタスク単位に通信範囲を絞れます。EC2起動タイプのbridgeモードではインスタンス単位のセキュリティグループになるので、ここはFargateのほうが細かく制御できる部分です。**イメージの脆弱性スキャン**では、ECRのスキャン機能などでコンテナイメージの脆弱性を継続的に検出・修正します。**監視**では、CloudWatchでメトリクスとログを収集し、必要に応じてX-Rayで分散トレーシングを行います。Fargateはサイドカー方式のセキュリティ製品にも対応しており、ランタイム保護を追加することも可能です。 運用面の注意として、FargateはAWS側のプラットフォーム更新のためにタスクを入れ替える（リタイアする）ことがあります。サービスとして複数タスクで動かし、1タスクが落ちても処理が止まらない構成にしておけば影響は小さく抑えられます。リタイアまでの待機期間については、アカウント設定による調整が可能です。 ## EC2起動タイプとFargateの選び方：採用条件と見送る場面を言い切る Fargateのメリットは、**インフラ管理からの解放**、需要に応じた**自動スケーリング**、アイドル時間に課金されにくい**従量課金**、タスクごとに環境が分離される**高いリソース分離性**です。デメリットは、EC2のような**細かいインスタンス制御ができない**こと、GPUや特権コンテナなど特殊要件に対応できないこと、そして**定常的に動かし続ける用途では割高になりやすい**ことです。これらを踏まえ、当社としての判断を条件付きで言い切ります。 ### Fargateを選ぶべき条件と、迷ったときに既定にしてよい理由 次のどれかに当てはまるなら、最初からFargateで組むことを勧めます。トラフィックが時間帯で大きく変わるWebアプリケーション、独立してデプロイ・スケールするマイクロサービス、必要なときだけ起動するデータ処理バッチ、イベント駆動の処理、そして**インフラ担当が専任でいない**チームです。前述の試算どおり、EC2の詰め込み率が9割に届かない規模ではFargateのほうが安く、OSパッチの運用もなくなります。大量のジョブをキューにためて実行するバッチ基盤としては、[AWS Batch](https://www.issoh.co.jp/tech/details/15519/)がFargateをコンピューティング環境として利用できます。迷ったらFargateで始め、請求額と使用率を3か月ほど見てからEC2起動タイプへの移行を検討する順番が、手戻りの少ない進め方です。前節のように両対応のタスク定義にしておけば、移行時の作業はサービスの作り直しとネットワーク設定の確認で済みます。 ### EC2起動タイプかManaged Instancesを選ぶべき条件と見送り場面 逆に、次の条件ではFargateを見送ります。GPU・Inferentiaなどのアクセラレータが要る、特権コンテナやカーネルパラメータの変更が要る、1台に1つずつ監視エージェントを常駐させたい、そして**24時間高負荷で動き続け、インスタンスの9割以上を埋められる規模**がある場合です。このうち「ハードウェアや特権は必要だが、インスタンスの運用は持ちたくない」ならECS Managed Instances、「AMIを自前で作り込みたい」「14日でインスタンスが入れ替わると困る長時間タスクがある」ならEC2起動タイプ、という切り分けになります。 当社ではAWS上のコンテナ基盤について、FargateとEC2起動タイプのどちらで組むかの判断から、VPC・ECS・CI/CDの構築、運用開始後のコスト見直しまでを支援しています。既存のEC2構成をFargateへ移したい、あるいは費用が想定より膨らんでいるといった相談は、[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)のページからお寄せください。 ## よくある質問 ### Q. ECSとEC2はどちらを選べばよいですか？ 二者択一ではありません。EC2は仮想サーバー、ECSはコンテナを配置・管理する仕組みで、ECSの計算資源としてEC2インスタンスを使う構成（EC2起動タイプ）が成り立ちます。ECSを使うと決めたうえで、計算資源をEC2起動タイプ・Fargate・ECS Managed Instancesのどれにするかを選ぶ、という順番で考えると役割の区別が明確です。FargateとECSの関係も同じで、「ECSを使い、その起動タイプとしてFargateを選ぶ（ECS on Fargate）」という形になります。 ### Q. FargateはEC2より高いのですか？ 単価だけなら、東京リージョンのオンデマンドで同じvCPU・メモリ量のEC2はFargateの約9割の価格です（2026年10月時点）。ただしEC2はインスタンスを丸ごと借りるため、タスクで埋めきれない空きも課金されます。常時フル稼働で9割以上を詰め込める用途ではEC2起動タイプ（特にSavings Plansやスポット併用）が安く、起動・停止が多く負荷が変動する用途ではFargateが有利になることが多いでしょう。 ### Q. Fargateで料金が想定より高くなるのはなぜですか？ NAT Gatewayのデータ処理料、CloudWatch Logsの取り込み料、データ転送料といった周辺コストが上乗せされるためです。タスクサイズの過剰な割り当ても原因になります。コンピュート以外の費用を見積もりに含め、VPCエンドポイントの利用やログ出力の見直し、タスクサイズの調整で抑えると効果的です。 ### Q. FargateでWindowsコンテナやARM（Graviton）は使えますか？ Fargate上では、いずれもAmazon ECS（ECS on Fargate）での提供で、EKS on Fargateでは非対応です（2026年10月時点の公式ドキュメント）。WindowsコンテナはX86\_64のみで1vCPU以上が必要、最低課金も5分になります。ARMは対応イメージであればx86より2割安く動かせる実行方式です。中断を許容できる処理なら、Fargate Spot（最大70%割引・中断の2分前にSIGTERMが届く）と組み合わせるとさらに費用を下げられます。 ### Q. 既存のEC2起動タイプからFargateへ移行するときの手順は？ 最初の作業は、タスク定義をFargate対応の設定へ変更することです。ネットワークモードをawsvpcへ変え、CPUとメモリをタスク単位で有効な組み合わせに指定し、`privileged`などFargateで無効なパラメータを外します。次に、ロードバランサーのターゲットグループをIPターゲットで作り直します。キャパシティプロバイダをEC2系からFargate系へサービスのまま更新することはできないため、新しいサービスをFargateで作り、ロードバランサー側で切り替えてから旧サービスを止める流れが安全です。 ## 関連記事 - [ECSでDockerコンテナを動かす手順：ECRへのpush・タスク定義・料金とEKSとの違い](https://www.issoh.co.jp/tech/details/3870/) - [AWSのコンテナサービス比較｜ECS・EKS・Fargate・Lambdaの選び方とExpress Modeで動かす手順](https://www.issoh.co.jp/tech/details/17869/) - [Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15424/) - [EKS Auto ModeとEKS on Fargateの違い｜制約一覧・料金の分岐点・併用時の落とし穴](https://www.issoh.co.jp/tech/details/4524/) - [ECS Express Modeとは？使い方・料金・CloudFormation対応とApp Runner移行先を解説](https://www.issoh.co.jp/tech/details/9958/) - [AWS App Runnerは終了する？2026年の新規受付停止・メンテナンスモード移行と移行先を解説](https://www.issoh.co.jp/tech/details/7023/) - [AWS Savings Plansの選び方と購入手順｜東京の実割引率とコミット額の決め方](https://www.issoh.co.jp/tech/details/17992/) --- 出典: [AWS Fargateとは？ECSのEC2起動タイプとの違い・料金・設定例を解説【2026年版】]()（株式会社一創）