Amazon ECS Managed Instances が AWS Trainium / Inferentia に対応

はじめに

2026 年 6 月 3 日、AWS は Amazon ECS Managed Instances に対して AWS Trainium および AWS Inferentia のサポートを発表しました。生成 AI のトレーニングや推論に特化した専用アクセラレーターを、ECS Managed Instances のフルマネージドな環境でそのまま利用できるようになります。

ECS 上で Trainium や Inferentia を使った生成 AI ワークロードを動かす場合、これまではインスタンスタイプごとに Neuron デバイスの指定をタスク定義内で個別に行う必要があり、Kubernetes ほどの複雑さは避けたいチームにとっては地味にハードルになっていました。今回のアップデートはこの課題に直接応えるものです。

同じ ECS Managed Instances では、これまで NVIDIA GPU メトリクスのサポートが発表されており、今回はその対象が AWS 独自の Neuron チップ（Trainium / Inferentia）にも広がった形です。

本記事では「何が変わったのか」「Inferentia2 / Trainium1 / Trainium2 はどう使い分けるのか」「実際にどう設定するのか」「コストをどう考えるか」を中心に解説します。ECS 上で生成 AI の推論・トレーニングワークロードを検討しているエンジニアの方はぜひ読んでみてください。

---

何が変わったのか

ECS で Trainium や Inferentia を使った生成 AI ワークロードを検討したことがある方なら、インスタンスタイプの選択やタスク定義での Neuron デバイスの指定について、何を意識する必要があるのか気になるところです。

項目	Before	After
Capacity Provider でのインスタンス選択	Inferentia2 / Trainium1 / Trainium2 は選択肢として明示されていなかった	アクセラレーター属性（acceleratorNames など）の指定で選択可能に
タスク定義での Neuron デバイス割り当て	linuxParameters.devices でインスタンスタイプごとにデバイスパスを個別指定	resourceRequirements への設定追加だけで全デバイスを自動割り当て
有効化手段	—	AWS Console / Amazon ECS MCP Server / IaC ツール

従来の課題

これまで ECS で Trainium や Inferentia を使う場合、タスク定義の linuxParameters.devices に Neuron デバイスのパスをインスタンスタイプごとに個別指定する方法が使われていました。たとえば inf2.xlarge では /dev/neuron0 の 1 つだけですが、trn1.32xlarge では /dev/neuron0 から /dev/neuron15 までの 16 個のパスを指定する必要があり、タスク定義の内容がインスタンスタイプに強く依存する形になっていました。インスタンスタイプを変更するたびにタスク定義側の修正が発生するのは、運用上の手間でした。

Trainium / Inferentia サポートによる解決

今回のアップデートにより、ECS Managed Instances の Capacity Provider で Inferentia2 / Trainium1 / Trainium2 を選択できるようになり、タスク定義側では resourceRequirements に設定を追加するだけで、インスタンス上の Neuron デバイスをすべて自動的にそのタスクへ割り当てられるようになりました。1 つのタスクがインスタンス上のすべてのデバイスを専有するため、インスタンスタイプを変えてもタスク定義を個別に書き換える必要がなくなります。

なお、この設定の名称については、アナウンス文と実際のドキュメントで表記が異なる点があるため、注意が必要です。詳細は「有効化の手順」の節で解説します。

---

対応アクセラレーターの特徴

Capacity Provider で選択できるようになった Inferentia2 / Trainium1 / Trainium2 は、いずれも AWS Neuron SDK 上で動作しますが、得意とするワークロードはそれぞれ異なります。なお、第一世代の Inferentia（Inf1）は EC2 launch type でのみサポートされており、ECS Managed Instances では利用できません。

項目	Inferentia2（Inf2）	Trainium1（Trn1）	Trainium2（Trn2）
主な用途	推論（LLM、画像生成など）	学習（事前学習・ファインチューニング）	大規模モデルの学習・推論
最大チップ数（1 インスタンス）	12 個	16 個	16 個
アクセラレーターメモリ（最大）	384 GB（HBM）	512 GB（HBM）	1.5 TB（HBM3）
メモリ帯域（最大）	9.8 TB/s	9.8 TB/s	46 TB/s

Inferentia2（推論向け）

Inf2 は推論に特化したインスタンスで、LLM や画像生成モデルなど、パラメータ数の大きい生成 AI モデルの推論に向いています。最大 12 個の Inferentia2 チップを NeuronLink で接続でき、複数チップに分散させた推論にも対応しています。第一世代の Inferentia（Inf1）と比較して、スループットは最大 4 倍、レイテンシーは最大 10 分の 1 です。

Trainium1 / Trainium2（学習向け）

Trn1 は生成 AI モデルの事前学習やファインチューニングに向いたインスタンスです。最大 16 個の Trainium チップを搭載し、FP16 / BF16 で最大 3 ペタフロップスの計算性能を持ちます。

Trn2 はその次世代にあたり、数百億から兆パラメータ規模のモデルの学習・デプロイを想定したインスタンスです。最大 16 個の Trainium2 チップで FP8 換算最大 20.8 ペタフロップス、1.5 TB の HBM3 メモリと 46 TB/s のメモリ帯域を持ち、Trn1 と比べてエネルギー効率は 3 倍です。

---

有効化の手順

前提条件

Trainium / Inferentia を使った Neuron ワークロードを実行するには、次の点を満たす必要があります。

• ECS Managed Instances のキャパシティプロバイダーを使用していること
• コンテナ内のアプリケーションが、AWS Neuron に対応した機械学習フレームワーク（PyTorch、TensorFlow など）を使っていること
• タスク定義が Linux コンテナであること

Managed Instances では Neuron ドライバーを含む AMI が自動的に使用されるため、EC2 launch type のように AMI を個別に指定する必要はありません。

Step 1：Capacity Provider でインスタンスタイプを選択する

ECS Managed Instances のキャパシティプロバイダーでは、起動テンプレートの instanceRequirements に以下のような属性を指定することで、Neuron 対応インスタンスを選択できます。

• acceleratorManufacturers：amazon-web-services を指定すると、AWS 製アクセラレーター（Inferentia / Trainium を含む）を対象にできる
• acceleratorNames：inferentia2、trainium、trainium2 のいずれかを指定して、対象チップを絞り込める
• allowedInstanceTypes：inf*、trn* のようなワイルドカードでインスタンスタイプ名を指定できる

allowedInstanceTypes を使う場合の設定例です。

{
    "instanceRequirements": {
        "allowedInstanceTypes": ["inf*", "trn*"]
    }
}

Step 2：タスク定義に Neuron デバイスの割り当てを設定する

タスク定義側では、コンテナ定義の resourceRequirements に Neuron デバイスを要求する設定を追加します。

{
  "containerDefinitions": [
    {
      "name": "neuron-app",
      "image": "<your-image>",
      "resourceRequirements": [
        {
          "type": "NeuronDevice",
          "value": "ALL"
        }
      ]
    }
  ]
}

type に NeuronDevice、value に ALL を指定することで、Amazon ECS がインスタンス上の Neuron デバイスを自動的に検出し、すべてのデバイスをこのコンテナに割り当てます。1 つのタスクがインスタンス上のすべてのデバイスを専有するため、同じインスタンスに他の Neuron タスクは配置されません。

NEURON_CORE と NeuronDevice の表記差異に注意

今回のアップデートのアナウンス文では「タスク定義の ResourceRequirement セクションに NEURON_CORE=all を追加する」という表現が使われていますが、ECS の Developer Guide では resourceRequirements の type に NeuronDevice、value に ALL を指定する形で説明されています。

実際にタスク定義を作成する際は、NEURON_CORE という文字列をそのまま使うのではなく、Developer Guide が示す NeuronDevice / ALL の形式に従ってください。

注意
1 つのタスク定義の中で NeuronDevice を指定できるコンテナ定義は 1 つまでです。また、同じタスク定義内で resourceRequirements の NeuronDevice と linuxParameters.devices による Neuron デバイス指定を併用することはできません。

設定の確認

タスクが起動したら、DescribeTasks API でデバイスの割り当てを確認できます。レスポンスにはコンテナごとの neuronDeviceIds フィールドが含まれ、割り当てられた Neuron デバイスの ID を確認できます。

aws ecs describe-tasks \
    --cluster <cluster-name> \
    --tasks <task-id>

コンテナインスタンス単位での空き状況は DescribeContainerInstances API で確認できます。registeredResources と remainingResources に NEURON_DEVICES が表示されます。

aws ecs describe-container-instances \
    --cluster <cluster-name> \
    --container-instances <container-instance-id>

---

活用シーン

ユースケース① LLM 推論エンドポイント（Inf2）

Inf2 インスタンスの Capacity Provider 上に、LLM やコード補完モデルなどの推論サービスをコンテナとしてデプロイするパターンです。resourceRequirements の設定により、各タスクは Inferentia2 の Neuron デバイスをすべて専有して動作します。

ECS Service の Auto Scaling と組み合わせることで、リクエスト数の増減に応じてタスク数（＝インスタンス数）を自動的に調整できます。アクセスが時間帯によって変動するチャットボットやコード補完サービスでは、コンテナベースでスケールできる点が効いてきます。inf2.24xlarge や inf2.48xlarge のように複数チップを搭載したインスタンスを選べば、NeuronLink を使った分散推論で、より大きなモデルにも対応できます。

ユースケース② ファインチューニング（Trn1 / Trn2）

Trn1 や Trn2 インスタンスを使い、自社データによる LLM のファインチューニングジョブを ECS タスクとして実行するパターンです。常時起動が必要な推論とは異なり、ファインチューニングは「ジョブが完了したら終了してよい」処理であるため、ECS Managed Instances によるインスタンスのプロビジョニング・終了の自動化が活きます。

ジョブが完了してタスクが停止すると、そのインスタンスは ECS Managed Instances によって他のワークロードが配置されないアイドル状態となり、最終的に終了されます。学習用の高価なインスタンスのコストを実行中の時間分だけに抑えられるため、業界特化型モデルの継続学習や定期的な再学習パイプラインのバッチジョブとして使いやすい構成です。

ユースケース③ MLOps パイプライン

データの前処理、学習、評価、デプロイといった一連の ML パイプラインを、それぞれ異なるインスタンスタイプの ECS タスクとして構築するパターンです。たとえば、前処理は汎用インスタンス、学習は Trn1 / Trn2、評価・デプロイは Inf2 のタスクとして実行し、Step Functions などで一連の流れをオーケストレーションします。

各ステップが ECS タスクとして独立しているため、既存の CI/CD パイプラインに組み込みやすく、インフラを意識せずにパイプライン全体をコードで管理できます。

---

他の選択肢との比較

EKS / SageMaker での Neuron サポートとの違い

Trainium や Inferentia を使った AI/ML ワークロードを動かす手段としては、EKS や SageMaker もよく使われます。

EKS でも以前から Inferentia / Trainium を使ったワークロードを実行できますが、Neuron デバイスを Pod に割り当てるには、Neuron device plugin を Helm チャートなどでクラスターに導入し、必要に応じてスケジューラー拡張やノード問題検出、モニタリング用のプラグインも併せて運用する必要があります。クラスターの構築・運用そのものに加えて、これらの Neuron 関連コンポーネントのライフサイクル管理も発生します。

ECS Managed Instances では、resourceRequirements への設定だけで Neuron デバイスの検出・割り当てがマネージドに行われ、デバイスプラグインのような追加コンポーネントの導入は不要です。Kubernetes クラスターの運用経験がないチームでも、コンテナベースで Neuron ワークロードを動かしやすくなっています。

SageMaker は、学習ジョブや推論エンドポイントといった「ML タスク」を抽象化したマネージドサービスで、Trn1 や Inf2 を使った学習・推論は以前から利用できます。モデルの学習や推論サービングそのものに専念したい場合には適した選択肢です。一方で、既存のアプリケーションが ECS 上のマイクロサービス群として構築されている場合、AI/ML ワークロードだけを SageMaker の「ジョブ」「エンドポイント」という別の単位に切り出すよりも、同じ ECS クラスター上でコンテナとして動かせる方が、既存の運用・デプロイの仕組みと一貫性を保ちやすくなります。

ECS Managed Instances の Trainium / Inferentia サポートは、Kubernetes クラスターの運用までは踏み込みたくないが、SageMaker のジョブ・エンドポイント単位よりも柔軟なコンテナ基盤で AI/ML ワークロードを動かしたい、というチームにとって新しい選択肢になります。

---

コストの考え方

料金体系

ECS Managed Instances で Trainium / Inferentia を利用する場合、通常の EC2 インスタンス料金に加えて、ECS Managed Instances 自体の管理料金が発生します。

EC2 インスタンス側では、On-Demand・Reserved Instances（1 年 / 3 年）・Savings Plans・Spot Instances など、通常の EC2 の購入オプションをそのまま利用できます。ECS Managed Instances 側の料金は、これらの EC2 の購入オプションとは独立しており、秒単位（最小 1 分）で課金されます。EC2 側のコストは Reserved Instances やスポットインスタンスなどで抑えつつ、その上に乗る ECS Managed Instances の管理料金は別軸で考慮する必要がある、という構成です。具体的な料金は変更される可能性があるため、最新の情報は Amazon ECS Managed Instances の料金ページ を確認してください。

コスト最適化のヒント

ファインチューニング（Trn1 / Trn2）のようなバッチワークロードでは、ジョブが完了すれば ECS Managed Instances 側でインスタンスが終了されるため、高価な学習用インスタンスを使うのは実行中の時間分だけに抑えられます。再実行可能なジョブであれば Spot Instances を組み合わせることで、EC2 インスタンス側のコストをさらに削減できます。

LLM 推論エンドポイント（Inf2）のように常時稼働させるワークロードでは、ECS Service の Auto Scaling と組み合わせて、トラフィックの少ない時間帯にタスク数を減らすことで、アイドル状態のアクセラレーターにコストを払い続ける状況を避けられます。利用量が安定して見込める場合は、Reserved Instances や Savings Plans も検討してください。

また、Inferentia2 / Trainium1 / Trainium2 はそれぞれインスタンスサイズによってチップ数やメモリ量が異なります。ワークロードに必要な性能を見極めた上で、過剰なサイズのインスタンスを選択しないことも効果的なコスト最適化につながります。

---

まとめ

今回のアップデートにより、ECS Managed Instances の Capacity Provider で Inferentia2 / Trainium1 / Trainium2 を選択し、タスク定義に設定を追加するだけで、Neuron デバイスの割り当てがマネージドに行われるようになりました。これまでインスタンスタイプごとにデバイスパスを意識する必要があった手間が解消され、ECS 上でコンテナベースの生成 AI ワークロードを動かす際の選択肢が一つ広がりました。

実装する際に注意したいのは、NEURON_CORE と NeuronDevice の表記差異です。アナウンス文にある NEURON_CORE=all という表現をそのままタスク定義に書いても動作しないため、実際の構文は resourceRequirements の NeuronDevice / ALL である点を押さえておいてください。

まず Inf2 を使った小規模な推論エンドポイントで DescribeTasks によるデバイス割り当ての確認まで一通り試し、動作を確認した上でファインチューニングや MLOps パイプラインへと適用範囲を広げていくのが現実的な進め方です。

---

参考リンク

• Amazon ECS Managed Instances now supports AWS Trainium and AWS Inferentia（What's New）
• Amazon ECS task definitions for AWS Neuron machine learning workloads（公式ドキュメント）
• Amazon ECS Managed Instances（製品ページ）
• Amazon ECS Managed Instances Pricing（料金ページ）
• Announcing Amazon ECS Managed Instances for containerized applications（AWS News Blog）
• Amazon EC2 Inf2 Instances（製品ページ）
• Amazon EC2 Trn1 Instances（製品ページ）
• Amazon EC2 Trn2 instances and UltraServers（製品ページ）
• Install Kubernetes device plugin for GPUs - Amazon EKS（公式ドキュメント）