AWS Fargateとは？ECSのEC2起動タイプとの違い・料金・運用をわかりやすく解説【2026年版】

AWS Fargateとは、コンテナを動かすサーバーをAWSに任せ、利用者はコンテナイメージと必要なCPU・メモリ量だけを指定すればよい実行方式です。Amazon ECSやAmazon EKSでコンテナを動かすとき、計算資源として「自分で持つEC2インスタンス」か「Fargate」かを選びます。本記事では、仕組みをわかりやすく整理したうえで、EC2起動タイプとの違い、東京リージョンの実単価で試算した損益分岐、ECS Execやタスクのリタイアといった運用の要点、選ぶ条件と見送る条件までをまとめます。

まとめ：FargateとEC2起動タイプの違いは「誰がサーバーを持つか」

• 立ち位置：Fargateは単独のサービスではなく、ECS・EKSが使う計算資源の選択肢の一つです。コンテナの配置と管理はECS・EKSが、実行環境はFargateが担います。
• EC2起動タイプとの違い：EC2起動タイプはインスタンスを自分で持ち、OSパッチや台数の調整も自分で行います。Fargateはタスクごとに必要なvCPUとメモリを指定するだけで、ホストには触れません。ネットワークモードはawsvpcに固定です。
• 料金：Linuxは秒単位（最低1分）の従量課金です。東京リージョンのオンデマンドでm7i.large・m7g.large（2vCPU・8GiB）と同量のFargateを比べると、EC2はFargateの約9割の価格です。コンピュート料金だけで見れば、インスタンスのvCPUとメモリをどちらも9割以上タスクで埋め続けられるときにEC2が安くなるのが目安です（2026年10月の公開単価で試算）。
• 運用：SSHはできませんが、ECS Execでコンテナにシェルで入れます。AWSのプラットフォーム更新でタスクが入れ替わる（リタイア）ため、複数タスクのサービスとして動かすのが前提です。
• 選び方：負荷が変動するWebアプリ・マイクロサービス・バッチはFargate。GPU・特権コンテナが要る構成や、24時間高負荷で総費用を比べてEC2が安いと確かめた構成はEC2起動タイプか、2025年に加わったECS Managed Instancesを選びます。

AWS Fargateとは：サーバーを持たずにECS・EKSのコンテナを動かす実行基盤

Fargate（ファーゲート）は、2017年に提供が始まったコンテナ向けのサーバーレス実行基盤です。コンテナを動かすには本来、載せるサーバーを用意し、OSのパッチ当てや台数の増減を自分で運用しなければなりません。Fargateではこの部分をAWSが受け持ち、利用者が管理するのはコンテナイメージと「CPUとメモリをどれだけ使うか」の指定だけになります。

コントロールプレーンとデータプレーンで見るFargateの役割

コンテナ基盤は、コンテナをどこにいくつ置くかを決めるコントロールプレーンと、コンテナが実際に動くデータプレーンに分けて考えると整理できます。ECS・EKSがコントロールプレーンで、その下のデータプレーンとしてEC2インスタンスかFargateを選びます。AWSの公式ドキュメントでも、ECSクラスターのインフラはECS Managed Instances・Fargate・EC2インスタンスの3種類として並べられています。Fargateだけを契約して使う、という形にはなりません。

タスク定義・タスク・サービスの3要素

ECS on Fargateで扱うのは次の3つです。タスク定義はコンテナイメージ・CPU・メモリ・環境変数・ネットワーク設定を書いたJSONの設計図、タスクはそのタスク定義から起動したコンテナのまとまり、サービスは指定した数のタスクを動かし続け、ロードバランサーやオートスケーリングとつなぐ仕組みです。タスク定義でOSファミリー（LinuxかWindowsか）は指定しますが、サーバーの台数やホストOSのパッチは、この3つのどこにも出てきません。

ECSとEC2の違い：オーケストレーターと仮想サーバーは別の層

「ECS EC2 違い」で迷う疑問は2つに分かれます。ECSとEC2がそもそも何か、という疑問と、ECSで動かすときにEC2起動タイプとFargateのどちらにするか、という疑問です。先に前者を片付けます。

Amazon EC2は、CPU・メモリ・ディスクを持つ仮想サーバーを借りるサービスで、OS以上は利用者が面倒を見ます。Amazon ECSは、コンテナをどのサーバーに何個置き、落ちたら入れ替えるかを決めるオーケストレーションのサービスで、ECS自体は計算資源を持ちません。そのためEC2の上でECSを使う構成（EC2起動タイプ）が普通に成り立ち、「ECSかEC2か」は二者択一ではありません。EC2の仕組みと料金モデルはAmazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断、インスタンスの絞り込み方はAWSのインスタンスタイプの選び方、ECSでDockerイメージを動かすまでの手順はECSでDockerコンテナを動かす手順：ECRへのpush・タスク定義・料金とEKSとの違いで扱っています。

ECSのEC2起動タイプとFargateの違いを管理範囲・設定・課金で比較

運用の手間を減らしたいならFargate、詰め込みが効く定常負荷でコストを突き詰めるならEC2、という住み分けです。EC2はSavings Plansやスポットと組み合わせやすく、1台に複数タスクを詰められます。Fargateはアイドルのインスタンスが存在しないため、夜間に止める処理や急なスパイクに合わせて増減する処理で無駄が出ません。

ネットワークモードとタスク定義パラメータの違い

最初にぶつかる違いはネットワークです。Fargateのタスクは常にawsvpcネットワークモードで動き、タスクごとに専用のENI（Elastic Network Interface）とプライベートIPが付きます。ロードバランサーのターゲットグループもIPターゲットで作る必要があります。EC2起動タイプではawsvpcのほかbridge・host・noneを選べ、Linuxで省略するとbridgeになるため、EC2用のタスク定義をそのままFargateで登録しようとするとここで弾かれます。

タスク定義にも差があります。Fargateではprivileged・gpu・links・placementConstraints・dnsServersなどが使えず、追加できるLinuxのcapabilityはCAP_SYS_PTRACEだけです。カーネルパラメータは、Linuxのプラットフォームバージョン1.4.0以降ならsystemControlsで名前空間内のもの（net.で始まるものなど）に限って設定できます。CPUとメモリはタスク単位で決められた組み合わせから選び、0.25vCPUなら512MiB〜2GB、1vCPUなら2〜8GB、16vCPUなら32〜120GB、32vCPUなら60・120・244GBです（16vCPU以上はLinuxのプラットフォームバージョン1.4.0以降）。エフェメラルストレージは既定20GiBで、ephemeralStorageで最大200GiBまで増やせます。

第3の選択肢ECS Managed Instancesの位置づけ

2025年9月に提供が始まったAmazon ECS Managed Instancesは、FargateとEC2起動タイプの中間にあたります。EC2インスタンスは自分のアカウントで起動されますが、選定・パッチ適用・入れ替えはAWSが担い、インスタンスは14日でドレインされて新しいものに置き換わります。SSHはできない一方、GPU付きのインスタンスや特定のCPUを指定できます。課金はインスタンス単位で、EC2料金に管理料金が上乗せされます。東京のm7i.largeなら管理料金は1時間0.015624ドルで、EC2料金と合わせた0.145824ドルは、同量のFargate（0.14536ドル）とほぼ同額です（Price List API・2026年10月19日公開版）。「Fargateでは仕様が足りないが、EC2の運用は持ちたくない」場合の受け皿で、14日を超えて動き続けるタスクには向きません。

タスク定義とCLIで起動タイプを切り替える：FargateとEC2の設定例

ここでは1つのタスク定義をFargateとEC2の両方で動かせるように書き、CLIで起動先を切り替えます。AWS CLI v2が東京リージョン（ap-northeast-1）で設定済みで、ECSクラスター「demo」、NAT Gateway経由でインターネットへ出られるプライベートサブネット、セキュリティグループ、タスク実行ロール、後述のECS Execで使うタスクロールが用意されている前提です（IDは例なので自分の環境の値に置き換えてください）。

FargateとEC2の両方で動くタスク定義の書き方

条件は3つです。requiresCompatibilitiesにFARGATEとEC2を並べる、ネットワークモードをawsvpcにする、CPUとメモリをFargateの有効な組み合わせでタスク単位に書く。これで同じリビジョンをどちらでも起動できます。

{
  "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",
  "taskRoleArn": "arn:aws:iam::123456789012:role/webAppTaskRole",
  "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"
        }
      }
    }
  ]
}

taskdef.jsonとして保存して登録し、aws ecs run-taskの--launch-typeを書き換えると実行先が変わります。

# ロググループを先に作る（標準の実行ロールにはlogs:CreateLogGroupが無い）
aws logs create-log-group --log-group-name /ecs/web-app

# タスク定義を登録する
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の数で配置できるタスク数が頭打ちになります。awsvpcトランキング対応のインスタンスタイプならアカウント設定で上限を引き上げられます。EC2側でbridgeを使い続けるなら、タスク定義をFargate用と分けるほうが素直です。

Fargate Spotを混ぜるキャパシティプロバイダ戦略

常駐サービスでも、一部をFargate Spotに載せると費用を下げられます。次の例は、最低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のタスクは、容量の回収時に2分前の通知（EventBridgeのタスク状態変更イベントとSIGTERM）を受けてから止まります。stopTimeoutは最大120秒まで延ばせるので、SIGTERMを受けたら処理中のリクエストを捌き切って終わるようにアプリを作っておきます。Spotの容量が足りないときに通常のFargateへ自動で振り替わることはないため、baseは止まると困る最低限の台数で決めます。1つのキャパシティプロバイダ戦略にFargate系とAuto Scalingグループ（EC2）系を混ぜることはできませんが、2025年6月からは既存サービスのキャパシティプロバイダを更新して、サービスを作り直さずにEC2とFargateの間を移せます。

ECS on FargateとEKS on Fargateの違い

同じFargateでも、ECSから使うかEKSから使うかで管理の単位（タスクかPodか）と使える機能が変わります。ECS・EKS・Fargate・Lambdaを横並びで比べた全体像はAWSのコンテナサービス比較｜ECS・EKS・Fargate・Lambdaの選び方で整理しています。

ECS on FargateとExpress Modeによる公開手順

ECSのデータプレーンにFargateを選ぶ構成が「ECS on Fargate」で、タスク定義で起動タイプにFargateを指定すると、タスクの起動ごとに必要な資源が割り当てられます。ロードバランサー・オートスケーリング・ネットワークまで一度に用意したいなら、コンテナイメージとIAMロールを渡すだけでFargateベースの公開環境ができるECS Express Modeの使い方と料金が近道です。イメージの置き場所となるECRの料金とpush手順はAmazon ECRとは？料金・ECSとの違いとDockerイメージのpush手順を参照してください。

EKS on Fargateで使えない機能：DaemonSet・GPU・Arm・Spot

EKS on FargateではKubernetesのPodをノードなしで動かせますが、制約はECS on Fargateより多くなります。EKSのユーザーガイドでは、DaemonSet・特権コンテナ・HostPort/HostNetwork・GPU・Armプロセッサ・Windowsコンテナ・EBSボリューム・Fargate Spotがいずれも非対応で、Podはプライベートサブネットでしか動かず、IMDSも使えません（2026年10月時点）。Fargateで動かすつもりのPodがFargateプロファイルに一致しないと、配置できるEC2ノードが無い限りPendingのまま止まります。Kubernetesでノード管理を減らす選択肢の比較はEKS Auto ModeとEKS on Fargateの違い｜制約一覧・料金の分岐点にまとめました。

LambdaとFargateの違いとApp Runner新規受付停止後の選び方

イベントに応じて短時間だけ処理を走らせるならLambda、コンテナを常駐させてVPC構成やサイドカーまで制御したいならFargate、が基本の分け方です。Lambdaのタイムアウトは通常15分が上限で、Lambda Managed Instancesの非同期呼び出しなど一部の構成だけが最大90分まで延ばせます。それを超えて動き続けるバッチはFargateの領分です。かつての「手早くWebアプリを公開するならApp Runner」は、App Runnerが新規顧客の受付を停止し新機能の追加予定もないと公表されたため使えなくなりました。AWSが移行先として勧めるECS Express Modeの実体はFargate上のECSサービスです。経緯はAWS App Runnerは終了する？新規受付停止と移行先で解説しています。

Fargateの料金の仕組みと東京リージョン単価・コストを下げる方法

Fargateの料金は要求したvCPUとメモリの量×使用時間で決まります。対象はイメージの取得開始からタスク終了までで、公式の料金ページではLinuxが秒単位（最低1分）、Windowsが秒単位（最低5分）です。

vCPU・メモリ・エフェメラルストレージの東京リージョン単価

AWSのPrice List APIで取得した東京リージョン（ap-northeast-1）のオンデマンド単価は次のとおりです（2026年10月19日公開版。契約前に料金ページで最新値を確認してください）。

1vCPU・2GBのLinux/x86タスクを1か月（730時間）動かし続けると、(0.05056＋0.00553×2)×730で約45ドル、0.5vCPU・1GBなら約22.5ドルです。同じ1vCPU・2GBをWindowsで動かすと、vCPU・メモリの単価自体が高いうえにOSライセンス料が加わり、約85ドルとほぼ倍になります。エフェメラルストレージは20GBまで無料で、50GBに増やすと超過30GB分で月約2.9ドルが加わります。

EC2起動タイプと同じ構成で比べた月額と損益分岐

同じ東京リージョンのLinuxオンデマンド単価（EC2料金ページの公開データ・2026年10月23日更新）で、2vCPU・8GiBのインスタンスと同量のFargateを比べました。

この2構成では、x86でもARMでもEC2はFargateの約9割の価格です（0.1302÷0.14536≒0.90、0.1054÷0.11626≒0.91）。コンピュート料金だけで比べると、タスクの要求vCPUとメモリの合計がインスタンスのどちらも9割以上に届かなければ、EC2は安くなりません。CPUかメモリの片方だけが余る構成や、別のインスタンスタイプ・Savings Plansを使う場合は比率が変わるため、実際のタスク構成でFargateの積算額とEC2の必要台数×単価を比べ直してください。実際にはOSとECSエージェントが使う分だけタスクに回せるメモリは8GiBより減り、デプロイ時の入れ替え用の空きやAZ分散の余裕も要ります。0.5vCPU・1GBのタスク4つなら、Fargateは約90ドル/月で、m7i.large 1台（約95ドル/月）より安く済みます。

NAT Gateway・CloudWatch Logsなど見落としやすい周辺コスト

Fargateの請求が見積もりを超える典型は、コンピュート以外の費用です。プライベートサブネットのタスクがイメージ取得やAWS APIの呼び出しで通るNAT Gatewayのデータ処理料、CloudWatch Logsの取り込み料、インターネットへのデータ転送料が積み上がります。ECR・S3・CloudWatch LogsへはVPCエンドポイント経由にし、ログの冗長出力を抑えると効きます。NAT GatewayとVPCエンドポイントの損益分岐はVPCエンドポイントとは｜2種類の違いとNATゲートウェイとの料金比較で試算しています。

タスクサイズ・Savings Plans・Spot・Gravitonによる節約

効果が大きい順に並べると、まずタスクサイズの見直しです。Container Insightsで実使用率を見て、1段小さい組み合わせに落とせないか確かめます。次にFargate Spotで、中断を許容できるバッチや非同期処理なら最大70%安くなります（ECSのLinuxのみ）。Graviton（ARM）への切り替えは、上の単価表のとおり東京でvCPU・メモリとも約2割安くなります。1年・3年の利用を約束するCompute Savings PlansはFargateで最大50%の割引ですが、EC2 Instance Savings Plansのほうが割引率は大きく、長期の定常負荷ではEC2との差が開きます。東京での実割引率はAWS Savings Plansの選び方と購入手順｜東京の実割引率で比較しています。

Fargateの運用：ECS Exec・タスクのリタイア・固定IP・権限分離

サーバー管理がなくなっても、運用の作業がゼロになるわけではありません。Fargateで本番を回すときに押さえる点は、コンテナへの入り方、AWS都合のタスク入れ替え、送信元IP、権限とネットワークの分離の4つです。

ECS Execによるコンテナ接続と実行権限

FargateではホストにSSHできませんが、ECS Execを使えば実行中のコンテナでコマンドを実行したり、シェルを開いたりできます。ホスト上でdocker execを叩くことはできないままですが、SSM Session Managerを経由するECS Execがその代わりになります。前提は、手元にSession Manager pluginを入れること、ssmmessages:CreateControlChannelなど4つのSSM権限を持つロールをタスク定義のtaskRoleArnに指定し、そのリビジョンをサービスに反映しておくこと、VPCエンドポイントだけで外に出る構成ならssmmessagesのエンドポイントを作ることです。

# 既存サービスでECS Execを有効にし、新しいタスクに入れ替える
aws ecs update-service --cluster demo --service web \
  --enable-execute-command --force-new-deployment

# 入れ替わったタスクのコンテナでシェルを開く
aws ecs execute-command --cluster demo --task TASK_ID \
  --container web --interactive --command "/bin/sh"

有効化は起動時に決まるため、既存のタスクには後から効きません。本番では、誰が実行できるかをIAMの条件キー（ecs:container-nameなど）で絞り、セッションのログをCloudWatch LogsかS3に残す設定を合わせて入れます。

タスクのリタイアとプラットフォームバージョン

Fargateのタスクは、プラットフォームバージョン（2026年10月時点のLATESTはLinuxが1.4.0、Windowsが1.0.0）の特定のリビジョン上で動きます。AWSはOSやコンテナランタイムの更新のたびに古いリビジョンをリタイアさせ、その上のタスクを止めます。通知はAWS Health Dashboardとメールで届き、停止までの待機は既定7日で、アカウント設定fargateTaskRetirementWaitPeriodで0日（即時）か14日に変えられます。2025年12月からは、週末だけに寄せたいといった用途向けにEC2のイベントウィンドウも指定できます。

サービスのタスクはECSが自動で入れ替えます。複数タスクを複数のAZに分け、ヘルスチェックとSIGTERMでの終了処理を整えておけば、入れ替えの影響は小さく抑えられます。危ないのはEventBridgeのスケジュールやStep FunctionsからRunTaskで起動する単発タスクで、止められても代わりは起動されません。数日がかりの処理を1タスクで流す設計は避け、途中から再開できる単位に分けます。

NAT Gatewayによる送信元IPの固定

Fargateのタスクに付くIPは起動のたびに変わり、パブリックIPを割り当てても固定できません。外部のAPIがIPアドレスの許可リストを求める場合は、タスクをプライベートサブネットに置き、Elastic IPを付けたNAT Gateway経由で外に出します。外から見える送信元はNAT GatewayのElastic IPに揃います。受信側を固定したいときは、Network Load BalancerにElastic IPを付けて前に置きます。

タスク実行ロールとタスクロールの権限分離

イメージ取得やログ出力に使うタスク実行ロールと、アプリがS3などを呼ぶタスクロールは別物で、権限を混ぜないのが基本です。各タスクが専用のENIを持つため、セキュリティグループをタスク単位で付けられるのもFargateの利点で、bridgeモードのEC2起動タイプ（インスタンス単位のセキュリティグループ）より細かく絞れます。イメージの脆弱性を継続的に検出するなら、Amazon Inspectorと連携するECRの拡張スキャンを有効にします。

EC2起動タイプとFargateの選び方：デメリットと見送る条件

Fargateのデメリットは、インスタンスを細かく制御できないこと、GPU・特権コンテナやsystemControlsの範囲を超えるカーネル設定に対応しないこと、24時間高負荷で詰め込みが効く用途ではEC2より割高になりうることの3点です。運用体制と、必要なハードウェア・権限から採用条件を整理します。

Fargateを既定にしてよい条件

負荷が時間帯で大きく変わるWebアプリ、独立してデプロイするマイクロサービス、必要なときだけ起動するバッチ、そしてインフラ専任の担当がいないチームは、必要なハードウェア・権限がFargateの対応範囲に収まる限り、Fargateを第一候補にします。前述の2vCPU・8GiBの試算では、EC2を9割以上埋められない構成ならFargateが安く、ホストOSのパッチ適用もAWSに任せられます。キューにためたジョブを流すなら、AWS Batchのコンピューティング環境にFargateを選べます。迷ったらFargateで始め、請求額と使用率を3か月見てからEC2への移行を検討する順番が手戻りの少ない進め方です。両対応のタスク定義にしておけば、移行はキャパシティプロバイダ戦略の更新で済み、残る作業は移行先の容量・権限・ネットワーク・ロードバランサー設定の確認です。

EC2起動タイプかManaged Instancesを選ぶ条件

GPUやInferentiaが要る、特権コンテナやsystemControlsで扱えないカーネル設定が要る、1台に1つ監視エージェントを常駐させたい、24時間高負荷で、実際のタスク構成で総費用を比べてEC2が安いと確かめられた。このどれかに当てはまればFargateは見送ります。そのうえで「ハードウェアや特権は要るがインスタンスの運用は持ちたくない」ならECS Managed Instances、「AMIを作り込みたい」「14日でインスタンスが入れ替わると困る長時間タスクがある」ならEC2起動タイプです。

当社では、FargateとEC2起動タイプのどちらで組むかの判断から、VPC・ECS・CI/CDの構築、運用開始後のコスト見直しまでを支援しています。既存のEC2構成をFargateへ移したい、費用が想定より膨らんでいるといった相談はインフラ構築（AWS・Google Cloud・Azure）からお寄せください。

よくある質問

AWS Fargateをわかりやすく言うと何ですか？

コンテナを動かすためのサーバーをAWSが用意・管理してくれる仕組みです。利用者はコンテナイメージと、使うCPU・メモリの量を指定するだけで、サーバーの台数やOSのパッチを気にする必要がありません。ECSやEKSと組み合わせて使い、Fargate単体では動きません。

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

東京リージョンのオンデマンドで2vCPU・8GiBのm7i.large・m7g.largeと同量のFargateを比べると、コンピュート料金はEC2がFargateの約9割です（2026年10月時点）。ただしEC2はタスクで埋めきれない空きにも課金されるため、vCPUとメモリを9割以上埋められない構成ではFargateのほうが安くなります。

Fargateで料金が想定より高くなるのはなぜですか？

NAT Gatewayのデータ処理料、CloudWatch Logsの取り込み料、データ転送料といった周辺コストと、タスクサイズの過剰な割り当てが主な原因です。VPCエンドポイントの利用、ログ出力の削減、使用率に合わせたタスクサイズの見直しで抑えられます。

FargateでWindowsコンテナやARM（Graviton）は使えますか？

どちらもECS on Fargateで使え、EKS on Fargateでは使えません。WindowsはX86_64のみで、最低課金は5分、OSライセンス料も加わります。ARMは対応イメージならx86より約2割安く動かせます。

EC2起動タイプからFargateへ移行する手順は？

タスク定義のネットワークモードをawsvpcにし、CPUとメモリをタスク単位で有効な組み合わせに指定し、privilegedなどFargateで使えないパラメータを外します。ロードバランサーのターゲットグループはIPターゲットで作り直します。2025年6月からは既存サービスのキャパシティプロバイダ戦略を更新してFargateへ移せます。一度に切り替えるのが不安なら、Fargateで新しいサービスを作り、ロードバランサー側で振り分けを移してから旧サービスを止める方法も取れます。

関連記事

• ECSでDockerコンテナを動かす手順：ECRへのpush・タスク定義・料金とEKSとの違い
• AWSのコンテナサービス比較｜ECS・EKS・Fargate・Lambdaの選び方とExpress Modeで動かす手順
• Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を実装者目線で解説
• EKS Auto ModeとEKS on Fargateの違い｜制約一覧・料金の分岐点・併用時の落とし穴
• ECS Express Modeとは？使い方・料金・CloudFormation対応とApp Runner移行先を解説