Fargate 32vCPU対応で変わる自己管理クラスタの是非

大規模なバッチ処理やETL（データを抽出・変換・投入する処理）、AI推論基盤を、EC2の自己管理クラスタやEKS（Amazon Elastic Kubernetes Service）のセルフマネージドノードグループで運用してきた企業のインフラ担当者にとって、Fargateは「小規模タスク向けの選択肢」だった。ノード管理を手放せる代わりに、1タスクあたりの上限が小さく、重量級ワークロードには使えなかったためだ。

2026年6月5日、AWSはAmazon ECS（Elastic Container Service）上のFargateで32vCPU、メモリ最大244GiBのタスクをサポートすると発表した[1]。従来の上限は16vCPUで、単純計算で上限が2倍に広がった。ただしEKS上でFargateを使う構成には適用されない。

本稿では、恩恵が及ぶ範囲と、なお自己管理を必要とする規模を、料金と技術上限の両面から整理する。

予備知識

• Fargate: ECSやEKSでコンテナを動かす際、EC2インスタンスの管理を不要にするAWSのサーバーレスコンピューティングエンジン。
• ECS（Elastic Container Service）: AWS独自のコンテナオーケストレーションサービス。Kubernetesを使わずコンテナを運用できる。
• EKS（Elastic Kubernetes Service）: AWSのマネージドKubernetesサービス。ノードにEC2かFargateを選べる。
• タスク定義: ECS/EKSでコンテナに割り当てるvCPU・メモリなどのリソース量を宣言する設定単位。

ECS/Fargateの設計判断を最新の構成で押さえ直したい読者には次の一冊が向く。

AWSコンテナ設計・構築［本格］入門 増補改訂版

created by Rinker

• Amazon
• 楽天市場
• Yahooショッピング
• メルカリ

32vCPU対応の範囲、ECSとEKSで扱いが異なる

今回の拡張はAmazon ECS上のFargateに限定され、EKS上のFargateには適用されない。ECSでは32vCPUタスクに対し、メモリを60GiB・120GiB・244GiBの3段階から選べるようになった[1]。x86とARM(Graviton、AWS独自設計のARMベースプロセッサ)の両アーキテクチャがLinux上で対象になり、Fargate Spot(スポット容量を使う割安なFargate)でも利用できる[1]。

全ての商用リージョンとAWS GovCloud(US)が対象だ[1]。一方でEKS上のFargateは、公式ドキュメント時点で最大16vCPU・120GiBのままで、今回の発表はEKS Podの構成表に反映されていない[2]。ECSでは自己管理相当の規模に近づいたが、EKS上でFargateを使う構成では従来どおり16vCPUの壁が残る。

コンピュート単価と運用工数を合わせてTCOで比べたい読者には次の一冊が参考になる。

AWSコスト最適化ガイドブック

created by Rinker

• Amazon
• 楽天市場
• Yahooショッピング
• メルカリ

コスト比較、Fargateと自己管理EC2の時間単価差

32vCPUで選べるメモリは60GiB・120GiB・244GiBの3値なので、最小の60GiBで比較する[6]。この構成だとFargateは自己管理EC2オンデマンドより、x86で約15%、ARMで約8%高い。以下の単価はいずれも米国東部(バージニア北部)のもので、東京リージョンは同構成で約25%高い[3]。AWS公式の料金表によれば、Fargate Linux/x86はvCPU時間0.0404ドル(約6.3円、1ドル=155円換算、2026年8月時点)、メモリGB時間0.00444ドル(約0.7円)[3]。Linux/ARM(Graviton)はvCPU時間0.0324ドル(約5.0円)、メモリGB時間0.00356ドル(約0.6円)で、x86より2割ほど安い[3]。

32vCPU・60GiBのタスクを1時間動かすと、x86構成で約1.56ドル(約242円)、ARM構成で約1.25ドル(約194円)になる。同じ32vCPU相当のEC2オンデマンドは、x86のc6i.8xlargeが時間1.36ドル(約211円)、Gravitonのc7g.8xlargeが時間1.16ドル(約180円)である[7]。この価格にはEKSコントロールプレーン料金(標準サポート時間0.10ドル、約16円)[5]や運用工数は含まれない。

Fargateの実行基盤

Fargate 1.3.0強制終了、コンテナ実行基盤の選び直し

本番ワークロードをAmazon ECS（Elastic Container Service、AWSのコンテナオーケストレーションサービス）上のFargate（サーバー管理不要で使えるコンテナ実行環境）で運用し、実行基盤のコスト最適化を毎年[…]

自己管理クラスタがなお優位に立つ条件

コンピュート単価の差が縮まっても、自己管理クラスタが必要な場面は残る。第一に、タスクあたり32vCPUを超える規模だ。EC2起動タイプのタスク定義は最大192vCPUまで指定でき、超大規模なバッチ・AI推論ジョブは依然としてEC2起動タイプかEKSのセルフマネージドノードでしか組めない[4]。

第二に、GPUを使うAI推論やGravitonに対応していない特定インスタンスファミリー、カーネルパラメータの細かいチューニングが必要なワークロードは、Fargateの標準構成では対応できない。第三に、EKS上でFargateを使う構成では16vCPUの壁がそのまま残るため、EKSで32vCPU相当のPodを動かしたい場合はEC2ノードグループが前提になる。

EKSのサポート期限

Amazon EKS 1.33サポート終了、延長コストか計画移行かの分岐点

数千人規模の従業員が使う基幹システムをAmazon EKS（Amazon Elastic Kubernetes Service、AWSのマネージドKubernetesサービス）上で本番稼働させ、年1回の内部監査を受ける情報システム部門のイ[…]

日本企業のインフラ部門が移行判断で直面する固有の壁

海外のクラウドネイティブ企業なら、コスト差が縮んだ時点で移行検証に着手できる。日本企業では事情が異なる。既存のEC2/EKS自己管理クラスタは、SIer(システムインテグレーター、開発・保守を請け負う外部事業者)への保守委託契約とセットで運用されているケースが多く、Fargate移行はインフラ構成だけでなく保守契約の範囲変更を伴う。

加えて、内部統制上の変更管理プロセス(申請・レビュー・承認)を経る必要があり、x86で約15%・ARMで約8%というコスト差は稟議の説得材料として弱いと判断されやすい。人員が限られる情報システム部門では、検証工数そのものが後回しになりがちだ。

IT部門は、まず32vCPU超のタスクの有無を棚卸しし、Fargate移行が技術的に可能な範囲を先に確定させるべきだ。決裁側は、1割前後のコスト差だけでなく、保守契約の見直しコストと運用負荷削減効果を合わせて稟議の可否を判断する必要がある。

まとめ

ECS上のFargateは32vCPU・最大244GiBまで対応し、従来自己管理でしか運用できなかった規模のワークロードにフルマネージドの選択肢が広がった。ただしEKS上のFargateは16vCPUの壁が残り、192vCPUまで指定できるEC2起動タイプの上限にも及ばない。

IT部門の担当者は、まず自社のタスクをvCPU規模別に棚卸しし、32vCPU以内でEC2起動タイプを使っているタスクから移行検証を始めるのが次の一手になる。決裁側は、コンピュート単価の1割前後の差だけでなく、SIer保守契約の見直しコストと運用負荷削減の合計で稟議の判断材料とすべきだ。

上限拡張は選択肢を増やしたに過ぎず、全面移行の理由にはならない。

よくある質問(FAQ)

Q1. EKS上のFargateでも32vCPUタスクを使えますか。
使えない。今回の拡張はAmazon ECS上のFargateが対象で、EKS上のFargateは公式ドキュメント時点で最大16vCPU・120GiBのままだ[1][2]。

Q2. ARM(Graviton)とx86でFargateの料金はどれくらい違いますか。
Linux/ARMはLinux/x86よりvCPU時間単価が約2割安い(x86が0.0404ドル、ARMが0.0324ドル)[3]。同じ性能要件ならARM対応アプリケーションほどコスト差が出やすい。

Q3. Fargate Spotは32vCPUタスクでも使えますか。
使える。今回のリリースはFargate Spot(スポット容量を使う割安なFargate)にも対応しており、割り込み耐性のあるバッチ処理では追加のコスト削減余地がある[1]。

出典