コンテナ基盤の導入や移行を検討する情シス担当者にとって、実行環境の選択は悩ましい課題です。ECS on EC2、ECS on Fargate、EKSのどれを選ぶべきか、運用負荷や費用の面で迷う方も多いのではないでしょうか。
本記事では、AWS Fargateの位置づけからEC2との違い、料金、制約、PoCの進め方までを整理し、自社に適しているかを判断するための軸をお伝えします。

AWS Fargateとは？ECSやEKSで使うサーバーレスなコンテナ実行環境

Fargateは、Amazon Elastic Container Service（Amazon ECS）やAmazon Elastic Kubernetes Service（Amazon EKS）でコンテナを動かすための、サーバーレスな実行環境です。コンテナとは、アプリケーションと動作に必要な部品を、ひとまとめにした実行単位のことです。サーバーレスとは、利用者がサーバーの種類や台数を管理しなくてよい仕組みを指します。

AWSの公式ドキュメントでは、FargateはECSと組み合わせて、Amazon EC2インスタンスのクラスターを管理せずにコンテナを動かす技術と説明されています。利用者は、CPUとメモリの量、ネットワーク、権限を定義して起動するだけです。

FargateはECSやEKSと何が違うのか

結論から言うと、FargateはECSやEKSと競合するサービスではありません。ECSやEKSは、コンテナの配置や増減を管理するオーケストレーション（コンテナの管理役）です。Fargateは、そのコンテナが実際に動く計算資源、つまり実行環境にあたります。

AWSの選択ガイドでも、コンテナが動く層にはEC2とFargate、管理する層にはECSとEKSが位置づけられています。Fargateは、ECSとEKSのどちらとも組み合わせて使えます。

したがって、選択の考え方は「ECSかFargateか」ではありません。「ECSやEKSの実行環境を、EC2にするか、Fargateにするか」です。この整理が、導入判断の出発点になります。なお、ECSにはEC2とFargateに加え、AWSがEC2インスタンスを管理するAmazon ECS Managed Instancesという選択肢もあります。本記事では、Fargateと EC2の比較に絞って解説します。

Fargateが解決する運用課題

EC2上でコンテナを動かす場合、利用者はEC2インスタンスの管理も担います。具体的には、インスタンスの種類の選定、OSのパッチ適用、空き容量を見ながらの台数調整などです。コンテナ化しても、サーバー運用の手間が残る点は課題になりがちです。

Fargateを使うと、次の作業が不要になります。

• サーバーの選定：インスタンスの種類を決める作業
• 台数の調整：負荷に合わせてクラスターの規模を決める作業
• 配置の最適化：コンテナをサーバーに無駄なく詰める作業

一方で、アプリケーションやイメージの管理は、引き続き利用者の担当です。詳しくは「本番導入前に決める体制と役割分担」をご覧ください。

Fargateでできること

Fargateでは、用途に応じてストレージやネットワークを組み合わせられます。ECSで利用できる主な機能は、次のとおりです。

• コンテナの実行：Linux（x86とArm）とWindowsのコンテナを動かせる
• 負荷分散：ALBやNLBなど、Elastic Load Balancingでアクセスを分散できる
• ストレージ：EBSやEFS（共有できる永続ストレージ）も使える
• ログ出力：Amazon CloudWatch Logsへログを送れる

なお、Fargateには使えない設定もあります。GPUや特権コンテナなどが代表例です。詳しくは「Fargateの制約事項」をご覧ください。

結論｜Fargate・EC2・ECS・EKSをどう使い分けるか

サーバー管理の手間を減らしたいなら、Fargateが有力な候補です。細かな設定や特殊な要件があるなら、EC2起動タイプやEKS on EC2を検討します。選ぶ順番は、次のとおりです。

1. オーケストレーションを選ぶ：AWSの標準機能で足りればECS、Kubernetesを使いたい場合はEKS
2. 実行環境を選ぶ：運用負荷を減らしたいならFargate、細かな制御が必要ならEC2
3. 制約を確認する：GPUや特権コンテナなど、Fargateで使えない要件がないか

ECS on FargateとECS on EC2の違い

ECS on Fargateは、Amazon ECSのタスクをAWS Fargate上で実行する構成です。EC2インスタンスを用意せず、タスク（ECSで動かすコンテナの実行単位）だけを定義して動かします。

ECS on EC2では、タスクを動かすEC2インスタンスを、利用者が用意して管理します。インスタンスやOSを自由に選べる代わりに、パッチ適用や台数調整も利用者の担当です。

EKS on FargateとEKS on EC2の違い

EKS on Fargateは、Kubernetes（コンテナ運用の標準的な管理基盤）のPod（コンテナの実行単位）をFargate上で実行する構成です。EKSでは、Fargateプロファイルという設定で、どのPodをFargateで動かすかを指定します。ノード（Podを動かすサーバー）の管理が不要になる点が利点です。

ただし、EKSではFargateに制約が多く、公式ドキュメントでも注意点が示されています。たとえば、DaemonSet（全ノードに同じ常駐プログラムを置く仕組み）は使えません。Fargate Spotも、EKSでは利用できません。

Kubernetesの機能を広く使いたい場合は、EKS on EC2が選ばれやすくなります。詳しくは「Fargateの制約事項」をご覧ください。

管理負荷・柔軟性・コストの比較表

ここまでの違いを、次の表にまとめます。コストの傾向は、ワークロードによって変わる点にご注意ください。

構成	サーバー管理	柔軟性	コストの傾向	向いている要件	主な制約
ECS on Fargate	不要	中程度	使った分だけ課金	Webアプリ、API、バッチ	GPU・特権コンテナは不可
ECS on EC2	必要	高い	高利用率なら有利な場合も	GPU、安定した高負荷	インスタンス運用の手間
EKS on Fargate	ノード管理は不要	中程度	Podの要求量で課金	Kubernetesで運用を減らしたい	DaemonSet・GPUは不可
EKS on EC2	必要	高い	構成により異なる	Kubernetesの機能を広く使いたい	運用に専門知識が必要

AWS Fargateのメリットと注意点

AWS Fargateの最大のメリットは、サーバー管理から解放され、アプリケーションに集中できる点です。一方で、利用前に押さえておきたい注意点が3つあります。

• 料金：ワークロードにより、EC2より割高にも割安にもなる。詳しくは「EC2起動タイプとコスト差が出るポイント」をご覧ください
• 制約：GPUなど、使えない設定がある。詳しくは「Fargateの制約事項」をご覧ください
• 向き不向き：常時高負荷などではEC2が適する場合がある。詳しくは「EC2やEKSを選ぶべきケース」をご覧ください

サーバー管理が不要で運用負荷を下げられる

Fargateでは、EC2インスタンスの選定やクラスターの調整が不要です。公式ドキュメントでは、サーバーの種類の選択や、スケールのタイミングの判断が不要になると説明されています。運用チームは、サーバーの面倒を見る時間を減らせます。

基盤のセキュリティ更新も、AWSが担います。Fargateのプラットフォームバージョンは、カーネルやOSの更新に応じて新しい改訂版が出ます。新しく起動したタスクは、常に最新の改訂版で動きます。

なお、問題が見つかった改訂版で動くタスクは、AWSによって入れ替えられる場合があります。そのため、同じタスクを複数動かし、1つが止まっても影響が出ない設計にしておくことが大切です。

コンテナごとに分離でき、増減もしやすい

Fargateでは、タスクやPodごとに独立した実行環境が割り当てられます。ECSの公式ドキュメントによると、各タスクは独自の分離境界を持ちます。カーネル、CPU、メモリ、ネットワークインターフェースを、他のタスクと共有しません。

増減のしやすさも利点です。Auto Scaling（負荷に応じて台数を自動で増減する機能）を設定すれば、アクセスの増減に合わせてタスクを調整できます。サーバーの台数を意識せず、タスクの数だけで考えられます。

AWS Fargateの料金とコスト最適化

AWS Fargateの料金は、使った分だけ支払う従量課金です。公式の料金ページでは、初期費用はなく、使用したリソース分のみが課金されると案内されています。ただし、見積りでは周辺サービスの費用を見落としがちです。

料金の内訳と見落としやすい費用

公式の料金ページによると、Fargateの料金は次の要素で決まります。

• vCPU：タスクやPodに割り当てた、仮想CPUの量
• メモリ：タスクやPodに割り当てた、メモリの量
• エフェメラルストレージ：一時的に使うディスク領域。標準で20GBが含まれ、追加分のみ課金される
• OSとCPUアーキテクチャ：LinuxかWindowsか、x86かArmか
• 課金の期間：イメージの取得開始から終了までを秒単位で計算し、最低1分

加えて、次の費用は別に発生します。見積り時に漏れやすいため、注意が必要です。

費用項目	発生する場面	見積り時の注意
ログ	CloudWatch Logsへログを送るとき	出力量と保管期間も含めて試算する
データ転送	外部へ通信するとき	標準のAWSデータ転送料金が課金される
パブリックIPv4アドレス	タスクやPodに付与したとき	付与する台数と期間を確認する
ロードバランサー	ALBなどで公開するとき	Fargateとは別のサービスとして課金される
NAT Gateway	プライベートサブネットから外部へ出るとき	使わない構成にできないか、事前に検討する

料金の試算には、AWS Pricing Calculatorが使えます。タスク数、稼働時間、リソース量を入力して月額を見積もります。料金は更新されるため、公式ページで最新の単価を確認してください。

EC2起動タイプとコスト差が出るポイント

FargateとEC2起動タイプのコストは、一概にどちらが安いとは言えません。差が出るポイントは、主に次の4つです。

観点	Fargateの傾向	EC2起動タイプの傾向
稼働パターン	動いた時間だけ課金。断続的な処理に向く	インスタンスが起動している間、課金される
利用率	割り当てた量で課金。使い切れないと割高	複数のコンテナを詰めて使い切れば効率的
運用工数	パッチ適用や台数調整が不要	インスタンス管理の工数がかかる
割引の手段	Fargate Spot、Savings Plans	スポットインスタンス、Savings Plans、Reserved Instances

断続的な処理や、負荷の変動が大きいシステムは、Fargateの従量課金が合いやすいと言われています。一方、24時間ほぼ一定の高負荷なら、EC2のほうが割安になる場合があります。単価だけでなく、運用に割く人の時間も比較しましょう。

Fargate SpotとSavings Plansの考え方

Fargate Spotは、AWSの余剰な計算容量を、割引価格で使える仕組みです。公式の料金ページでは、通常のFargate料金から最大70％の割引と案内されています。ただし、容量が必要になると、2分前の通知でタスクが中断されます。

このため、中断されても再実行できる処理に向いています。たとえば、バッチ処理や、開発・検証環境です。なお、Fargate SpotはECSで使え、EKSでは使えません。

Savings Plansは、1年または3年、一定の利用量を約束する代わりに、料金が下がる仕組みです。公式の料金ページでは、Fargateの利用料金を最大50％節約できると案内されています。利用量が安定している本番環境に向いています。

あわせて、サイジング（必要十分なリソース量の見極め）も重要です。割り当てが大きすぎると、使わない分も課金されます。PoCで実際の使用量を測って調整しましょう。

AWS Fargateの本番利用前に確認すべきセキュリティと運用設計

Fargateでは基盤の管理はAWSが担いますが、セキュリティと運用の設計は利用者の責任です。本番利用の前に、次の4点を確認しましょう。

権限・ネットワーク・シークレットの確認ポイント

まず、権限の設計です。ECSでは、2種類のAWS IAMロール（AWSの操作権限をまとめたもの）を使い分けます。

実行ロールは、イメージの取得やログの出力など、ECSがタスクを起動する際に使う権限です。タスクロールは、コンテナ内のアプリがAWSのサービスを呼び出す際に使う権限です。

次に、ネットワークです。Fargateのタスクは、必ずAmazon VPC（AWS上の専用ネットワーク）の中で動きます。起動時には、サブネットとSecurity Group（通信を許可する範囲を決める設定）を指定します。

外部に公開するアプリは、ALBの背後にタスクを置くのが一般的です。ロードバランサーの対象は、インスタンスではなく、IPアドレスで指定します。プライベートサブネットのタスクがイメージを取得するには、NAT GatewayまたはVPCエンドポイントが必要です。

NAT Gatewayを使わない方法もあります。Amazon ECRにVPCエンドポイント（AWS PrivateLinkを使った専用の接続口）を設定すると、プライベートな経路でイメージを取得できます。ただし、ECR用のインターフェイス型エンドポイント（ecr.apiとecr.dkr）に加えて、Amazon S3用のゲートウェイ型エンドポイントも必要です。ログをCloudWatch Logsへ送る場合は、ログ用のインターフェイス型エンドポイントも作成します。

最後に、シークレット（パスワードやAPIキー）の扱いです。コードやイメージに直接書かず、AWS Secrets ManagerやAWS Systems Manager Parameter Storeに保存し、実行時に渡します。暗号化には、AWS KMSの鍵が使えます。

なお、Amazon ECRの脆弱性スキャンを有効にしておくと、イメージの既知の脆弱性を早期に把握できます。

監視・ログ・デプロイの確認ポイント

Fargateでは、基盤のサーバーを直接操作できません。そのため、ログと指標を先に設計しておくことが重要です。

ログは、CloudWatch Logsに送るのが標準的です。SplunkやFireLens（外部サービスへの転送機能）にも対応しています。

CPUやメモリの使用状況は、Container Insights（CloudWatchでコンテナの指標を見られる機能）で確認します。処理の遅れの原因を追うなら、分散トレース（1つのリクエストが通る経路を追う手法）が役立ちます。AWS X-Rayなどで実現できます。

タスクの起動に失敗したときは、切り分けの順番を決めておくと対応が早まります。具体的には、次の順で確認します。

1. タスクの停止理由と、ECSのイベントを確認する
2. イメージを取得できているか、経路と権限を確認する
3. ログに、アプリケーションのエラーが出ていないか確認する
4. ヘルスチェックの猶予時間が、起動にかかる時間に合っているか確認する

デプロイの方式も、先に決めておきましょう。ローリングアップデートは、タスクを順番に入れ替える方式です。Blue/Green デプロイは、新旧2つの環境を並べて切り替える方式で、問題があれば元に戻しやすくなります。

Fargateの制約事項

Fargateには、EC2にはない制約があります。導入後に困らないよう、事前に確認しましょう。公式ドキュメントで示されている主な制約を、次の表にまとめます。

項目	ECS on Fargate	EKS on Fargate	影響しやすいケース
GPU	使えない	使えない	機械学習の推論など
特権コンテナ	使えない	使えない	ホストを直接操作するツール
DaemonSet	（該当なし）	使えない	ノードごとの監視エージェント
Fargate Spot	Linuxで使える	使えない	バッチの費用削減
ネットワーク	常にawsvpcモード	VPC CNIのみ	独自のネットワーク構成

このほか、ECSのFargateタスクは、追加できるLinuxの機能が限られ、Dockerボリュームも使えません。

制約は更新される場合があります。採用前に、公式ドキュメントの最新情報を確認してください。PoCでは、実際のアプリを動かして、必要な設定が通るかを試すことも欠かせません。

AWS Fargateが向いているケースと向いていないケース

Fargateが向くかどうかは、ワークロードの特性で決まります。以下は判断例であり、最終的にはPoCでの確認が必要です。

WebアプリやAPIに向いているケース

WebアプリやAPIは、ECS on Fargateと相性が良い代表例です。ALBの背後に複数のタスクを置き、アクセス量に応じて増減できます。サーバーの管理が不要なため、少人数の運用チームでも扱いやすくなります。

マイクロサービス（機能ごとに小さく分けたアプリの集まり）にも向いています。サービスごとにタスクが分離され、他のサービスへの影響を抑えられます。少人数で運用したい場合や、アクセスの増減が大きい場合は、有力な候補です。

バッチやジョブ実行に向いているケース

バッチやジョブは、必要なときだけ起動して、終わったら止める使い方が基本です。Fargateは、実行した時間だけ課金されるため、この使い方と相性が良いです。夜間の集計処理や、定期的なデータ変換などが例です。

EC2やEKSを選ぶべきケース

次のような場合は、EC2起動タイプやEKS on EC2を検討しましょう。

• GPUが必要：機械学習の推論や画像処理など。FargateではGPUが使えない
• 特権コンテナが必要：ホストの機能を直接操作するツールなど
• 常時高負荷：24時間ほぼ一定の負荷で、リソースを使い切れる
• 細かな制御が必要：インスタンスの種類やOSを、自分で選びたい
• Kubernetesの機能を広く使いたい：DaemonSetなど、Fargateで使えない機能が必要

判断に迷う場合は、まずFargateでPoCを行います。課題が出れば、EC2への切り替えを検討しましょう。

AWS Fargate導入の進め方

Fargateの導入は、要件整理、構成検討、PoC、本番導入の順に進めるのが基本です。各段階で何を決めるかを、先に押さえておきましょう。

要件整理から構成検討までの流れ

導入ステップは、次の5段階が基本です。社内稟議や見積りに必要な材料も、段階ごとにそろいます。

1. 要件整理：ワークロードの特性と、制約に関わる要件を洗い出す
2. 構成検討：ECSかEKS、FargateかEC2を決め、周辺設計を行う
3. PoC：小規模で、性能、費用、運用、セキュリティを検証する
4. 本番導入：体制と役割分担を決め、段階的に移行する
5. 改善：使用量を見て、サイズや購入オプションを見直す

要件整理では、稼働時間、負荷の変動、必要なリソース量を洗い出し、GPUなど制約に関わる要件も確認します。構成検討では、AWS Well-Architected Frameworkの観点で設計を点検すると、抜け漏れを減らせます。

PoCで確認すべき項目

PoC（本番前に小規模で試す検証）では、導入の判断材料となる5つの観点を確認します。結果は、社内稟議や見積りの根拠として使えます。

観点	確認する内容	判断のポイント
性能	起動時間、応答時間、高負荷時の挙動	要求する性能を満たしているか
コスト	実使用量にもとづく月額試算	EC2構成と比べて許容できるか
運用	ログ、監視、障害の切り分け、デプロイ	運用チームが無理なく扱えるか
セキュリティ	権限、ネットワーク、シークレット	自社の基準を満たしているか
制約	使いたい設定が実際に動作するか	代替できない要件が出ていないか

とくにコストは、実際の使用量を測ってから試算することが重要です。PoCで得た値を、AWS Pricing Calculatorに入力して見積りましょう。

本番導入前に決める体制と役割分担

Fargateを使っても、運用のすべてがなくなるわけではありません。責任分界（AWSと利用者のどちらが何を担うかの線引き）を理解して、体制を決めます。

領域	AWSの担当	自社の担当
基盤（サーバー、実行環境）	管理とパッチ適用	設計の前提の確認
コンテナイメージ	保管の仕組みの提供	作成と脆弱性への対応
アプリケーション	なし	開発と更新
権限・ネットワーク	サービスの提供	設計と設定
監視・障害対応	基盤の障害対応	アプリの監視と一次切り分け

あわせて、運用を内製するか、外部に委託するかも決めておきます。設計やPoCに不安がある場合は、構成検討の段階から専門家へ相談する方法もあります。

AWS Fargateに関するよくある質問

Q1. AWS FargateとECSの違いは何ですか？

ECSは、コンテナの配置や増減を管理するオーケストレーションです。Fargateは、そのコンテナを動かす実行環境です。両者は競合せず、ECSの実行環境としてFargateかEC2を選びます。

Q2. AWS FargateはEC2より安いですか？

一概には言えません。断続的な処理や、負荷の変動が大きい場合は、Fargateが合いやすくなります。常時高負荷なら、EC2のほうが割安になる場合があります。運用工数も含め、PoCで比較しましょう。

Q3. EKSでもFargateを使うべきですか？

EKSでもFargateは使えますが、制約が多い点に注意が必要です。DaemonSet、特権コンテナ、GPUは使えません。Kubernetesの機能を広く使うなら、EKS on EC2も比較しましょう。

Q4. AWS FargateでGPUや特権コンテナは使えますか？

どちらも使えません。ECSでもEKSでも、Fargateでは非対応です。これらが必要な場合は、EC2起動タイプを選びます。

まとめ｜AWS Fargateは運用負荷・コスト・制約を比較して判断する

AWS Fargateは、ECSやEKSでコンテナを動かす、サーバーレスな実行環境です。
EC2を実行環境とする構成と比べて、サーバー管理の手間を減らせます。
一方で、料金はワークロードによって変わり、GPUや特権コンテナなどの制約もあります。

採用の判断では、運用負荷、コスト、制約の3点を比較しましょう。
まずは対象のワークロードを整理し、PoCで使用量と運用の手間を確かめることが重要です。

テクノプロでは、AWSに精通した技術者が、コンテナ基盤の検討から運用までを支援します。

・要件整理・構成検討：ECS／EKS、Fargate／EC2の選定と、ネットワーク・権限・シークレットの設計

・PoC・費用見積り：実使用量にもとづく性能・コスト・運用の検証と、稟議に利用できる見積り根拠の整理

・本番導入・運用：監視・ログ・デプロイの設計から、段階的な移行、運用体制づくりまで

・人材支援：運用を担うAWS技術者の派遣と、内製化に向けた技術者教育

「まず何から整理すべきか」という段階でもご相談いただけます。
テクノプロまでお気軽にお問い合わせください。