はじめに
2026 年 6 月 5 日、AWS は Amazon ECS with AWS Fargate の新たなコンピュート構成として 32 vCPU のサポートを発表しました。
これまで Fargate のタスクサイズには上限があり、大規模な AI 推論や ETL 処理、HPC(High Performance Computing)系のワークロードを動かそうとすると、結局 EC2 起動タイプへ移行せざるを得ないケースが少なくありませんでした。サーバーレスの運用メリットを享受したいのに、リソースサイズの都合でインスタンス管理に戻ってしまう。今回のアップデートは、このジレンマに直接応えるものです。
本記事では「何が変わったのか」「どんな場面で活用できるのか」「実際にどう設定するのか」「コストをどう考えるか」「EC2 とどう使い分けるか」を中心に解説します。ECS / Fargate を運用しているインフラエンジニア・SRE の方はもちろん、技術選定に関わるマネージャー層の方にもご一読いただけると幸いです。
何が変わったのか
ECS 上で計算集約型のワークロードを動かしたことがある方なら、「Fargate でやりたいけど vCPU が足りない」という壁にぶつかった経験があるのではないでしょうか。今回のアップデート内容を、具体的な数値で確認します。
| 項目 | Before | After |
|---|---|---|
| 最大 vCPU 数 | 16 vCPU | 32 vCPU |
| 最大メモリ | 120 GB | 244 GB(60 / 120 / 244 GB から選択) |
| 対応アーキテクチャ | x86 / ARM(Linux) | 変更なし(x86 / ARM 両対応を継続) |
| 対応キャパシティプロバイダー | Fargate / Fargate Spot | 変更なし(両方で 32 vCPU が利用可能) |
| 対応リージョン | 全商用リージョン / GovCloud(US) | 変更なし |
従来の課題
Fargate のタスクサイズは段階的に拡張されてきましたが、直近の上限は 16 vCPU・最大 120 GB メモリでした。この水準は多くの一般的なワークロードには十分な一方、以下のようなケースでは天井に達してしまうことがありました。
- CPU ベースで LLM(大規模言語モデル)の推論を行いたいが、必要なメモリ量がタスクサイズの上限を超えてしまう
- Apache Spark や Apache Flink などの分散処理フレームワークを、単一タスクで大きめに動かしたい
- ゲノム解析パイプラインのように、一時的に大量の CPU とメモリを必要とする科学計算ワークロードがある
こうした要件に直面したチームは、複数タスクへの分散などでアーキテクチャを複雑化させるか、EC2 起動タイプへの移行を検討するか、という選択を迫られていました。
32 vCPU 対応による解決
今回のアップデートにより、Fargate のタスクサイズに 32 vCPU という新たな選択肢が加わりました。メモリは 60 GB・120 GB・244 GB の 3 段階から選択可能で、x86・ARM(AWS Graviton)いずれのアーキテクチャでも利用できます。
設定方法もシンプルで、タスク定義の cpu 値に 32768(32 vCPU)を指定し、memory 値として 60 GB・120 GB・244 GB のいずれかを指定するだけです。既存のデプロイフロー(コンソール・CLI・IaC)をそのまま使えるため、学習コストはほぼかかりません。この組み合わせは Linux プラットフォームバージョン 1.4.0 以降が必要です。具体的な設定方法は後述します。
このアップデートの位置づけ
Fargate のコンピュートリソース拡張は今回が初めてではありません。直近では 2022 年 9 月に、当時の上限であった 4 vCPU・30 GB から 16 vCPU・120 GB へと約 4 倍に引き上げられたアップデートがありました。今回の 32 vCPU 対応は、この延長線上にあるアップデートです。
ユースケース
具体的にどんな場面で活用できるかを、4 つの軸で見ていきます。
CPU ベースの AI 推論
生成 AI ブーム以降、LLM(大規模言語モデル)を GPU なしの CPU 環境で推論させたいというニーズが急増しています。llama.cpp のような CPU 推論エンジンや、RAG(検索拡張生成)パイプラインを使ったアプリケーションは、必ずしも GPU を必要としません。一方でこうしたワークロードは、モデルそのものをメモリ上に展開する必要があるため、数十 GB 単位のメモリを要求するケースが珍しくありません。
32 vCPU・244 GB という構成であれば、比較的大きなモデルでも GPU インスタンスを用意することなく、サーバーレスのまま高スループットな推論サービスを構築できます。リクエスト数に応じてタスク数をスケールさせれば、推論基盤全体の運用をシンプルに保てる点も魅力です。
大規模データ処理・ETL
Apache Spark や Apache Flink といった分散処理フレームワークは、本来複数ノードに処理を分散させることを前提に設計されています。しかし、データ量がそこまで大きくない場合や、処理を素早く終わらせたい場合には、無理に分散構成を組むよりも単一の大きなタスクで一気に処理する方がシンプルで高速なことがあります。
これまでは Fargate のタスクサイズの制約から実現が難しかったこの種のワークロードも、32 vCPU であれば単一タスクで大規模なデータ変換・集計処理を実行できます。処理が完了すればタスクごと終了するため、リソースの解放も自動的に行われます。
HPC・科学技術計算
ゲノム解析パイプライン(GATK など)やシミュレーション計算のように、一時的に大量の CPU とメモリを必要とする HPC 系のワークロードは、従来 EC2 のハイスペックインスタンスか、オンプレミスの計算リソースに頼らざるを得ませんでした。
こうした処理は常時動かしておく必要はないが動かすときは大量のリソースが要るという性質を持つことが多く、サーバーレスの従量課金モデルと相性が良い領域です。32 vCPU 対応によって、必要なときだけ大規模リソースをオンデマンドで確保し、処理が終われば即座に解放するという使い方が、インフラ管理の手間なしで実現できます。
大量並列処理・バッチジョブ
多数のスレッドを必要とする Web クローリングや、大量ファイルの並列圧縮・形式変換処理など、CPU バウンドな並列タスクも 32 vCPU の恩恵を受けやすい領域です。
従来であれば複数の小さなタスクに処理を分割し、並列実行することでスループットを稼ぐ必要がありましたが、単一タスクの CPU 数が増えたことで、タスク間通信や結果の集約といった分散処理特有のオーバーヘッドを抑えながら、より少ないタスク数でまとまった処理を完了できるようになりました。
実装方法
32 vCPU 対応の実装は、既存のタスク定義のリソース値を変更するだけで完結します。新しいパラメータや構文は登場しません。
前提条件
| 項目 | 値 |
|---|---|
cpu 値 |
32768(32 vCPU) |
memory 値 |
61440(60 GB)・122880(120 GB)・249856(244 GB)のいずれか |
| Linux プラットフォームバージョン |
1.4.0 以降 |
| 対応キャパシティプロバイダー |
FARGATE / FARGATE_SPOT
|
| 対応アーキテクチャ |
X86_64 / ARM64
|
メモリは 3 つの固定値からの選択制で、8 vCPU・16 vCPU のような範囲内で任意の値を指定できる形式ではない点に注意してください。
タスク定義の設定
タスク定義の cpu と memory を以下のように指定します。
{
"family": "large-workload-task",
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGATE"],
"cpu": "32768",
"memory": "61440",
"executionRoleArn": "arn:aws:iam::<your-account-id>:role/ecsTaskExecutionRole",
"runtimePlatform": {
"cpuArchitecture": "X86_64",
"operatingSystemFamily": "LINUX"
},
"containerDefinitions": [
{
"name": "app",
"image": "<your-image-uri>",
"essential": true,
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/large-workload-task",
"awslogs-region": "<your-region>",
"awslogs-stream-prefix": "ecs"
}
}
}
]
}
ARM(AWS Graviton)で動かす場合は cpuArchitecture を ARM64 に変更します。コンテナイメージが ARM64 に対応している必要があるので、マルチアーキテクチャ対応のイメージを使っているか事前に確認してください。
AWS CLI でのデプロイ
タスク定義を JSON ファイルとして保存し、register-task-definition で登録します。
aws ecs register-task-definition \
--cli-input-json file://task-definition.json
デプロイ自体は既存のサービス更新フローと変わらないため、update-service でタスク定義のリビジョンを切り替えるだけで反映できます。
IaC でのデプロイ(Terraform 例)
Terraform を使っている場合も、cpu と memory の値を変更するだけです。
resource "aws_ecs_task_definition" "large_workload" {
family = "large-workload-task"
network_mode = "awsvpc"
requires_compatibilities = ["FARGATE"]
cpu = 32768
memory = 61440
execution_role_arn = aws_iam_role.ecs_task_execution.arn
runtime_platform {
cpu_architecture = "X86_64"
operating_system_family = "LINUX"
}
container_definitions = jsonencode([
{
name = "app"
image = "<your-image-uri>"
essential = true
}
])
}
注意点
既存のサービスでプラットフォームバージョンを 1.3.0 などに明示的に固定している場合、1.4.0 以降に更新してください。プラットフォームバージョンはタスク定義ではなく RunTask やサービスの作成・更新時に指定するパラメータのため、古いバージョンを指定したまま 32 vCPU のタスク定義でサービスを更新しようとすると、その時点でエラーになります。
32 vCPU はリソース単価も大きくなるため、想定外のコストにつながらないよう、コスト最適化の考え方とあわせて導入することをおすすめします。
コスト最適化
32 vCPU・244 GB という構成は、リソース単価もそれだけ大きくなります。ここでは、32 vCPU 構成と組み合わせて使えるコスト最適化の手段を整理します。
Fargate Spot を組み合わせる
Fargate Spot は、通常の Fargate 料金から最大 70 % の割引で実行できる仕組みです。今回のアップデートでは Fargate と Fargate Spot の両方で 32 vCPU が利用可能になっているため、中断耐性のあるワークロードであれば、そのままコスト削減につなげられます。
バッチ処理や ETL ジョブ、リトライ可能な AI 推論タスクなど、途中で中断されても再実行すれば問題ない性質のワークロードと相性が良い選択肢です。常時稼働させる必要があるサービスや、中断によってユーザー影響が出るリアルタイム処理には不向きなので、ワークロードの性質を見極めて使い分けてください。
Graviton(ARM)で実行する
AWS は、Graviton ベースの ARM アーキテクチャで Fargate タスクを実行した場合、x86 と比べて約 20 % 低いコストで、価格対性能比は最大 40 % 向上すると公表しています。32 vCPU 構成も x86・ARM 両方に対応しているため、コンテナイメージが ARM64 に対応していれば、cpuArchitecture を ARM64 に変更するだけでこの恩恵を受けられます。
ARM64 非対応のベースイメージや、x86 専用のネイティブライブラリに依存したアプリケーションでは、そのまま動かないことがあります。移行前にマルチアーキテクチャ対応のイメージを用意するか、検証環境で動作確認してください。
Compute Savings Plan を適用する
継続的に Fargate を利用する場合は、Compute Savings Plan の活用も検討してください。1 年または 3 年のコミットメントと引き換えに、Fargate 利用料が最大 50 % 割引になる仕組みです。今回のアップデートでは、32 vCPU の利用分にも既存の Compute Savings Plan が自動適用されます。新たな契約や設定変更をすることなく、コミットメント済みの割引をそのまま受けられます。
組み合わせ戦略
ワークロードの性質によって、最適な組み合わせは変わります。
| ワークロードの性質 | おすすめの組み合わせ |
|---|---|
| 中断耐性のあるバッチ処理・ETL | Fargate Spot + Graviton |
| 常時稼働する本番サービス | Compute Savings Plan + Graviton |
| 検証・一時的な負荷テスト | Fargate Spot(オンデマンドでの単発実行) |
Graviton(ARM)はアプリケーションが対応している限り併用できる選択肢です。Fargate Spot と Compute Savings Plan はワークロードの稼働パターンに応じて使い分け、中断耐性がある処理は Spot、常時稼働が必要な処理は Savings Plan、という方針で考えると整理しやすくなります。
EC2 vs Fargate の選択基準
32 vCPU 対応によって Fargate でカバーできる範囲は広がりましたが、すべての場面で EC2 起動タイプを代替できるわけではありません。ここでは、それでも EC2 起動タイプを選ぶべき場面を整理します。
それでも EC2 が必要なケース
32 vCPU を超えるリソースが必要な場合は、引き続き EC2 起動タイプが必要です。EC2 起動タイプでは、タスクの CPU を 0.25 vCPU から最大 192 vCPU まで指定できます。32 vCPU はあくまで Fargate における上限です。
GPU を使うワークロードも EC2 起動タイプが前提になります。Fargate のコンテナ定義では gpu パラメータがサポートされていないため、GPU を使った機械学習の学習・推論ワークロードには、GPU 対応の EC2 インスタンスタイプが必要です。
特権コンテナやホストデバイスへの直接アクセスが必要な場合も同様です。Fargate では、コンテナに root 相当の権限を与える privileged パラメータと、ホストのデバイスをコンテナに直接公開する devices パラメータのいずれもサポートされていません。CAP_SYS_ADMIN や CAP_NET_ADMIN といった追加の Linux ケーパビリティも、権限昇格を防ぐ目的で制限されています。カーネルモジュールの操作や特殊なネットワーク設定など、ホストレベルの操作を必要とするワークロードには EC2 起動タイプが適しています。
高いネットワーク帯域幅、ローカル NVMe SSD ストレージ、特定の CPU 世代など、インスタンスタイプ固有の特性に依存したチューニングを行いたい場合も、EC2 起動タイプの方が柔軟に対応できます。
Fargate を選ぶべきケース
逆に、必要なリソースが 32 vCPU・244 GB 以内に収まり、サーバー管理の手間を省きたい場合は Fargate が適しています。ワークロードの実行頻度が不定期・バースト的で、インスタンスを常時起動させておくコストをかけたくない場合や、パッチ適用やスケーリング設定などインフラ運用の負荷をできる限り減らしたい場合も同様です。
判断のための比較表
| 観点 | Fargate(32 vCPU 構成) | EC2 起動タイプ |
|---|---|---|
| 最大 vCPU | 32 vCPU | 192 vCPU |
| GPU 対応 | 非対応 | 対応(GPU インスタンス) |
| 特権コンテナ | 非対応 | 対応 |
| ホストデバイスアクセス | 非対応 | 対応 |
| インスタンス管理 | 不要(サーバーレス) | 必要(パッチ適用・スケーリング設定など) |
| 起動の柔軟性 | タスク単位で起動・解放 | インスタンス起動が前提 |
「32 vCPU で足りるか」「GPU や特権モードが必要か」の 2 点を確認すれば、多くの場合はどちらを選ぶべきか判断できます。
ベストプラクティス
32 vCPU 構成を実際に運用する上で、押さえておきたいポイントを整理します。
メモリの選び方(60 / 120 / 244 GB)
これまでの vCPU 区分と異なり、32 vCPU はメモリを範囲内で自由に指定できる方式ではなく、60 GB・120 GB・244 GB という 3 つの固定値からの選択制です。細かい調整ができない分、どの値を選ぶかが直接コストに影響します。
CPU 負荷が支配的でメモリ消費はそれほど大きくないワークロード(動画トランスコーディングや比較的軽量なバッチ処理など)であれば 60 GB、CPU とメモリの両方をバランス良く使う中規模なデータ処理であれば 120 GB、大規模な LLM をメモリ上に展開する CPU 推論やデータセット全体をメモリに載せて処理する分析基盤のようにメモリ使用量がボトルネックになるワークロードであれば 244 GB、というのが大まかな目安です。
固定 3 択という制約上、本当は 80 GB あれば足りるのに 120 GB を選ばざるを得ないといった余剰が発生しやすい点には注意してください。実際の使用率を確認しながら、過不足のない選択をしていくことが重要です。
Container Insights でのモニタリング
メモリ・CPU の選択が適切かどうかは、実際に動かしてみないと分からない部分も多くあります。Container Insights を有効にしてタスクレベルのリソース使用率を継続的に確認し、メモリ使用率が選択した tier の上限に張り付くようであれば一段階上のメモリ構成を、逆に余裕がありすぎる場合は一段階下げることでコストを抑えられないかを検討してください。
Auto Scaling と組み合わせる
32 vCPU は 1 つの大きなタスクでスケールアップする選択肢であり、トラフィック変動に対応するタスク数を増減してスケールアウトするという考え方を置き換えるものではありません。リクエスト数や負荷が変動するワークロードでは、引き続き Service Auto Scaling と組み合わせ、32 vCPU のタスクを必要な数だけ動的に増減させる構成を検討してください。単一の巨大タスクに依存しすぎると、そのタスクが落ちた際の影響範囲が大きくなる点にも注意が必要です。
まとめ
Amazon ECS with AWS Fargate の 32 vCPU・最大 244 GB メモリ対応により、AI 推論や大規模データ処理、HPC 系のワークロードをサーバーレスのまま動かせる範囲が広がりました。Fargate Spot や Graviton、Compute Savings Plan といった既存のコスト最適化手段もそのまま活用できます。一方で、32 vCPU を超えるリソースが必要な場合や、GPU・特権コンテナを使う場合は、引き続き EC2 起動タイプが必要です。
リソース不足を理由に EC2 起動タイプへ移行したワークロードを抱えているチームは、まずそのワークロードが 32 vCPU・244 GB の範囲に収まるかを確認し、Fargate へ戻せないか検討してみてください。タスク定義の cpu と memory の値を変更するだけで試せるため、検証のハードルも高くありません。