AWS Fargateとは？EC2との違い・料金をわかりやすく解説【2026年版】

AWS Fargateとは、サーバーやクラスターを自分で管理することなくコンテナを実行できる、AWSのサーバーレスコンピューティングエンジンです。EC2インスタンスのプロビジョニングやパッチ適用が不要になり、開発者はアプリケーションの構築と運用に集中できます。本記事では、Fargateの基本から、EC2起動タイプとの違い、料金の仕組みとコスト最適化、ECS/EKS・Lambda・App Runnerとの使い分け、そしてセキュリティと運用の勘所までをわかりやすく整理します。

まとめ：Fargateを一言でいうと

先に結論を押さえておきましょう。AWS Fargateは「コンテナの実行基盤（データプレーン）をAWSに任せられるサーバーレス方式」です。要点は次のとおりです。

• 立ち位置：Fargateは単独のサービスではなく、Amazon ECSやAmazon EKSの起動タイプ（実行方式）の一つ。コンテナの管理はECS/EKSが担い、Fargateが実行環境を提供します。
• EC2との違い：EC2起動タイプはサーバー（インスタンス）を自分で持って管理するのに対し、Fargateはサーバーを意識せず、必要なvCPUとメモリを指定するだけ。運用負荷が小さい反面、定常的に動かし続ける用途では割高になりやすい。
• 料金：使ったvCPUとメモリに対して秒単位（最低1分）で課金。アイドル時間に課金されにくい一方、NAT Gatewayやログなどの周辺コストが上乗せされる点に注意。
• 向く用途：負荷が変動するWebアプリ、マイクロサービス、バッチ、イベント駆動処理など、起動と停止が頻繁なワークロード。

以降で、それぞれを具体的に掘り下げていきます。

AWS Fargateとは：サーバーレスでコンテナを動かす仕組み

Fargate（ファーゲート）は、2017年にAWSが提供を開始したコンテナ向けのサーバーレスコンピューティングエンジンです。コンテナを動かすには本来、コンテナを載せるサーバー（ホスト）を用意し、OSのパッチ当てやスケーリングを運用する必要があります。Fargateはこの「サーバーを用意して管理する」部分をAWSが肩代わりするため、利用者はコンテナイメージと必要なリソース量を指定するだけで実行できます。

「データプレーン」としてのFargate

コンテナの世界では、コンテナを管理・指揮する役割をコントロールプレーン、コンテナが実際に動く実行環境をデータプレーンと呼びます。Amazon ECSやAmazon EKSがコントロールプレーン（オーケストレーション）を担い、その下でコンテナを動かすデータプレーンとして「EC2」か「Fargate」を選びます。つまりFargateは、ECS/EKSと組み合わせて初めて機能する実行基盤であり、単体で完結するサービスではありません。

Fargateを構成する要素

ECS on Fargateを例にすると、主な登場人物は次の3つです。タスク定義は、使用するコンテナイメージ・CPU/メモリ・環境変数・ネットワーク設定などを記述した設計図です。タスクは、そのタスク定義をもとに実際に起動したコンテナの集まりを指します。サービスは、指定した数のタスクが常に動き続けるよう維持し、ロードバランサーやオートスケーリングと連携します。利用者はクラスター（実行基盤）の中身を意識せず、これらの定義だけを管理すれば済みます。

FargateとEC2起動タイプの違い

ECS/EKSでコンテナを動かすとき、最初に判断するのが「Fargateで動かすか、EC2インスタンス上で動かすか」です。両者は同じコンテナを動かせますが、責任範囲とコスト構造が大きく異なります。

ざっくり言えば、運用の手間を最小化したいならFargate、コストを突き詰めたい定常負荷ならEC2という住み分けです。EC2起動タイプはリザーブドインスタンスやSavings Plans、スポットインスタンスと組み合わせやすく、1台に複数タスクを詰め込めるため、24時間365日動かし続ける大規模アプリではコストパフォーマンスが上回ることが少なくありません。一方、夜間や週末に止められるワークロードや、急なスパイクに合わせて増減させたい場合は、アイドル時間に課金されにくいFargateが有利です。なお単価だけを見るとEC2が安く見えても、インスタンスの運用・保守にかかる人件費まで含めた総所有コスト（TCO）で比べると、Fargateのほうが安上がりになるケースも少なくありません。コンテナオーケストレーションそのものについてはECS: AWSの強力なコンテナオーケストレーションサービスもあわせて参照してください。

FargateとECS・EKSの関係

「FargateとECSの違いは？」という疑問が多いですが、両者は対立するサービスではなく役割が異なると理解するのが正確です。ECS（またはEKS）が「どのコンテナを、いくつ、どこで動かすか」を管理し、Fargateは「実際にコンテナを動かす場所」を提供します。

ECS on Fargate

Amazon ECSはAWS独自のコンテナオーケストレーションサービスで、Dockerコンテナのデプロイ・スケーリング・障害復旧を自動化します。そのデータプレーンとしてFargateを選ぶ構成が「ECS on Fargate」です。タスク定義で起動タイプにFargateを指定するだけで、必要なリソースがその都度プロビジョニングされます。なお、ECSの設定をさらに自動化する新機能としてECS Express Modeとは何か – AWS ECSの新機能でコンテナデプロイを自動化して容易化する機能も登場しており、最小限の指定でFargateベースの公開環境を構築できます。

EKS on Fargate

Amazon EKSはKubernetesをマネージドで提供するサービスです。2019年にFargate対応が追加され、Kubernetesのポッドをノード（EC2インスタンス）なしで実行できるようになりました。ノードが物理的に存在しないため、ノード管理やSSH/SSMアクセスといった概念がなくなり、運用が大きく簡素化されます。Kubernetesベースでの選択肢についてはEKS Auto ModeとEKS on Fargateのノード管理とアクセス方法で詳しく整理しています。

Lambda・App Runnerとの使い分け

AWSにはFargate以外にもサーバーレスでコードを動かす選択肢があります。代表的なのがAWS LambdaとAWS App Runnerです。どれも「サーバー管理が不要」という点は共通しますが、得意な領域が異なります。

イベントに応じて短時間だけ処理を走らせたいならLambda、コンテナをそのまま常駐させて細かく制御したいならFargate、設定を最小限にしてWebアプリを手早く公開したいならApp Runner、という整理になります。App RunnerとFargateの違いはAWS App Runnerとは何か？クラウドネイティブなアプリケーション実行サービスの概要で具体的に比較しています。FargateはVPC構成やサイドカー、マルチコンテナなど複雑な構成に対応できる柔軟性が強みです。

Fargateの料金の仕組みとコスト最適化

Fargateの料金は、要求したvCPUとメモリの量×使用時間で決まります。コンテナイメージの取得を開始した時点からタスクが終了するまでが計算対象で、秒単位（最低1分）で課金されます。

課金される3つの要素

主な課金要素は、vCPU（秒単位）、メモリ（GB・秒単位）、そして追加のエフェメラルストレージの3つです。エフェメラルストレージは既定で20GBが無料で付与され、それを超える分が課金対象になります。東京リージョンのLinux/x86の場合、概算でvCPUが約0.05ドル/時、メモリが約0.0055ドル/GB時が目安です（単価は変動するため、必ず最新の公式料金ページで確認してください）。たとえば1vCPU・2GBのタスクを1か月間（30日）24時間動かし続けると、計算リソースだけで月およそ44ドル前後になります。あくまで概算であり、為替や単価改定で変わる点に留意してください。

見落としやすい周辺コスト

Fargateの請求額が見積もりを上回る典型的な原因は、コンピュート以外の周辺コストです。プライベートサブネットのタスクがイメージ取得やAWS API呼び出しのために通るNAT Gatewayのデータ処理料、CloudWatch Logsのログ取り込み料、インターネットへのアウトバウンドデータ転送料、イメージ配信のAmazon ECRなどが積み重なり、総額が大きく膨らむことがあります。NATの代わりにVPCエンドポイントを使う、ログの冗長出力を抑えるといった工夫が効果的です。

コストを下げる4つの定石

第一にタスクサイズの最適化です。Fargateの1タスクは最大16vCPU・120GBまで指定できますが、実使用量に対して過剰なCPU/メモリを割り当てないだけで無駄を削れます。第二にCompute Savings Plansで、1年または3年の利用をコミットすると最大72%程度の割引が受けられます。第三にFargate Spotで、中断を許容できるバッチや非同期処理に使えば最大70%程度安くなります（中断の2分前にSIGTERMが送られるため、終了処理を実装しておきます）。第四にAWS Gravitonプロセッサ（ARM）の活用で、対応イメージならx86より2割ほど安く動かせます。なお、Fargate上でのWindowsコンテナとARM（Graviton）はAmazon ECS（ECS on Fargate）でのみ利用でき、EKS on Fargateでは非対応です（EKSでもEC2/Gravitonノードを使えばARMは利用できます）。

Fargateのセキュリティと運用のポイント

Fargateはホストの管理をAWSに任せられますが、「セキュリティを何も考えなくてよい」わけではありません。責任共有モデルにおいて、コンテナイメージの中身やアプリケーションの設定は利用者の責任範囲です。

運用の基本は次のとおりです。IAMの最小権限では、ECRからのイメージ取得やログ出力に使う「タスク実行ロール」と、アプリがS3などにアクセスするための「タスクロール」を分けて、必要最小限の権限だけを付与します。ネットワーク分離では、各タスクが専用のENI（Elastic Network Interface）を持つため、VPC・サブネット・セキュリティグループで通信範囲を絞ります。イメージの脆弱性スキャンでは、ECRのスキャン機能などでコンテナイメージの脆弱性を継続的に検出・修正します。監視では、CloudWatchでメトリクスとログを収集し、必要に応じてX-Rayで分散トレーシングを行います。Fargateはサイドカー方式のセキュリティ製品にも対応しており、ランタイム保護を追加することも可能です。

Fargateのメリット・デメリットと向くユースケース

メリットは、インフラ管理からの解放、需要に応じた自動スケーリング、アイドル時間に課金されにくい従量課金、タスクごとに環境が分離される高いリソース分離性です。デメリットは、EC2のような細かいインスタンス制御ができないこと、GPUなど特殊要件に対応しにくいこと、そして定常的に動かし続ける用途では割高になりやすいことです。

これらを踏まえると、Fargateが向くのは、トラフィックが変動するWebアプリケーション、独立してデプロイ・スケールするマイクロサービス、必要なときだけ起動するデータ処理バッチ、イベント駆動の処理などです。逆に、24時間高負荷で動き続ける大規模システムや、GPU・特殊なカーネル設定を要するワークロードでは、EC2起動タイプの方が適しています。

よくある質問（FAQ）

Q. FargateとECSはどちらを選べばよいですか？

二者択一ではありません。ECS（またはEKS）がコンテナを管理する仕組みで、Fargateはその実行方式の一つです。実際には「ECSを使い、その起動タイプとしてFargateを選ぶ（ECS on Fargate）」という形になります。

Q. FargateはEC2より高いのですか？

使い方次第です。常時フル稼働させる用途では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では非対応です。ただしEKSでもEC2/Gravitonノードを使えばARMは利用できます。ARMは対応イメージであればx86より安く動かせます。最新の対応状況は公式ドキュメントで確認してください。

Q. Fargate Spotとは何ですか？

余剰のFargate容量を最大70%程度の割引で使えるオプションです。中断される可能性があり、その2分前にSIGTERMが通知されます。バッチやデータパイプラインなど、中断を許容できるワークロードに適しています。

関連記事

• ECS: AWSの強力なコンテナオーケストレーションサービス
• EKS Auto ModeとEKS on Fargateのノード管理とアクセス方法
• AWS App Runnerとは何か？クラウドネイティブなアプリケーション実行サービスの概要
• ECS Express Modeとは何か – AWS ECSの新機能でコンテナデプロイを自動化して容易化する機能