AWS Batch が Amazon ECS Managed Instances をサポートしたので GPU と CPU インスタンスそれぞれ試してみた

AWS Batch が Amazon ECS Managed Instances をサポートしたので、GPU と CPU インスタンスそれぞれを試して、実際の動作や設定方法、料金体系などを確認してみました。

2026.08.28

はじめに

AWS Batch のコンピューティング環境に Amazon ECS Managed Instances タイプが追加されました。Amazon ECS Managed Instances（以降はマネージドインスタンス）は、EC2 インスタンスのプロビジョニングやパッチ適用を AWS が管理してくれる仕組みです。

CPU はスポット、GPU はオンデマンドでコンピューティング環境を 2 つ作り、ジョブを実行して確認してみました。

なにが嬉しいのか

Fargate では扱えないスペック要求でも GPU でも EC2 の面倒をみなくて済む

AWS Batch の Amazon ECS オーケストレーターで選べるコンピューティング環境は Fargate と EC2 の 2 つでした。Fargate は 32 vCPU、244 GiB が上限です。GPU や特権コンテナ、ホストのデバイスは扱えません。EC2 タイプならどれでも使えます。ただし AMI の選定と更新、起動テンプレートの整備、パッチ適用時のインスタンス入れ替えは我々ユーザのお仕事であり、ツラミです。

Fargate で済ませたいけれどスペックが足りない、GPU がほしい。これらの理由で EC2 タイプを選ぶと、運用の面倒まで付いてきました。

マネージドインスタンスはこの 2 つの間を埋める熱い選択肢が追加されました。GPU や大きな vCPU、メモリを要求するジョブを実行できます。AMI の更新とパッチ適用、インスタンスのライフサイクルは AWS がやってくれます。これはありがたい。

「GPU を使えること」だけなら EC2 タイプでもできました。「EC2 の面倒を見なくていいこと」だけなら Fargate でもできました。両方を同時に満たせる選択肢の登場が今回のアップデートです。

Fargate では使えない EC2 の購入オプションを適用できる

Fargate では当然、オンデマンドキャパシティ予約やリザーブドインスタンスが使えません。マネージドインスタンスは、オンデマンドキャパシティ予約、リザーブドインスタンス、Amazon EC2 Instance Savings Plans の割引を適用できます。

EC2 タイプでも同じなので、これ自体がマネージドインスタンス固有の利点ではありません。EC2 運用の手間を手放したまま割引を受けられるところが違いです。

確認結果

インスタンスが 1 台もない状態からジョブを投入して、実行開始までの待ち時間は CPU が 44.2 秒と 29.1 秒、GPU が 36.4 秒とかなり速い結果でした
ホスト OS は Bottlerocket でした

3 タイプの使い分け

使い分けの基準は公式ドキュメントにまとまっています。

観点	Fargate	Amazon ECS Managed Instances	EC2
主なターゲット	32 vCPU、244 GiB に収まる汎用ジョブ	GPU や大きなリソースが必要なジョブ	カスタム AMI やマルチノードパラレルが必要なジョブ
GPU	非対応	NVIDIA アクセラレーターに対応	対応
特権コンテナ、ホストのデバイス	非対応	対応	対応
AMI の更新とパッチ適用	不要	AWS が管理	利用者が管理
カスタム AMI、起動テンプレート	不可	不可	可
マルチノードパラレルジョブ	不可	不可	可
常時起動の下限（`minvCpus`）	なし	指定不可	指定可
課金	タスク単位	EC2 料金 + インスタンス単位の管理手数料	EC2 料金

マネージドインスタンスは Amazon ECS オーケストレーターのコンピューティング環境専用です。Amazon EKS のコンピューティング環境では選べません。

使う前に知っておきたいこと

Amazon ECS Managed Instances 自体の仕組みは、DevelopersIO の既存記事を参考にしてください。

コンピュートノード常時起動の設定はできない

EC2 タイプでは、ジョブが 1 件も無い状態でも最低これだけの vCPU 数は起動させておく、という下限を minvCpus で指定できました。マネージドインスタンスにこの設定はありません。ジョブを投入してからインスタンスが起動するので、1 件目のジョブには必ず待ち時間が発生します。

後述の scaleInAfter は、空いたインスタンスをいつ落とすかの設定です。起動済みのインスタンスを残すことはできますが、ジョブが無い状態から起動させる用途には使えません。

minvCpus のほかに allocationStrategy、imageId、instanceTypes、launchTemplate なども指定できません。一覧は公式ドキュメントにまとまっています。

maxvCpus について

原文にも将来変わりうる旨が添えられています。

Currently, AWS Batch evaluates maxvCpus based on the total vCPUs requested by running jobs, not the total vCPUs of the underlying Amazon EC2 instances. Amazon ECS Managed Instances uses multi-tenant instance allocation. As a result, the actual instance vCPU capacity provisioned might exceed the job vCPU total. The compute environment might provision more instance capacity than the maxvCpus value implies. This behavior might be refined in a future update.

出典: Compute environments on Amazon ECS Managed Instances - AWS Batch

ジョブキューではスポットをオンデマンドより前に置けない

ジョブキューには複数のコンピューティング環境を順序付きで登録できます。マネージドインスタンスでは、スポットの環境をオンデマンドより前に置けません。スポットを先に試して、容量が足りなければオンデマンドに回す、という並べ方はできないことになります。

インスタンスプロファイルのロール名は ecsInstanceRole で始める

14 日を超えて計算が必要なジョブには向いていない

AWS Batch のドキュメントには記載がありませんが、Amazon ECS 側に次の制約が挙げられています。

OS は Bottlerocket。カスタム AMI は使えない
SSH でログインできない。デバッグには ECS Exec を使う
最大稼働時間は 14 日。超えるとドレインが始まる
使えるのは 1 vCPU を超えるサイズで、nano と micro は対象外

14 日を超えて計算が必要なジョブには向いていません。

料金は EC2 料金と管理手数料が発生します

AWS Batch 自体に追加料金はありません。かかるのは EC2 インスタンスの料金と、Amazon ECS Managed Instances のインスタンス単位の管理手数料です。

東京リージョンの管理手数料です。インスタンス 1 台あたりの時間単価です。

インスタンスタイプ	管理手数料（USD/時）
c6i.large	0.01284
g4dn.xlarge	0.05538
g5.xlarge	0.113802

管理手数料は購入オプションで変わりません。スポット、リザーブドインスタンス、Savings Plans で安くなるのは EC2 料金の側だけです。

Terraform はまだ対応していない

Terraform AWS Provider は aws_batch_compute_environment の ECS_MANAGED_INSTANCES に未対応でした。今回コンピューティング環境を CLI で作っているのはこのためです。

ツール	対応状況（2026 年 8 月 27 日時点）
AWS CLI v2	2.36.28 以降
CloudFormation	テンプレートリファレンスに定義あり。デプロイは未確認
Terraform AWS Provider	6.62.0 で未対応

検証環境

リージョンは ap-northeast-1 です。AWS Batch のリソースは CLI で作成します。CPU スポット環境と、GPU オンデマンド環境の 2 つを用意します。

CPU ジョブをスポットで動かす

CPU スポットのコンピューティング環境を作成する

allowedInstanceTypes にはファミリーと世代の異なる 4 タイプを列挙します。候補を広げておくと、スポットのキャパシティを確保しやすくなります。capacityOptionType に SPOT を指定し、maxvCpus は 4 に絞りました。infrastructureOptimization.scaleInAfter を 60 秒にしているのは、ジョブが終わったインスタンスを早めに落とすためです。

{
  "computeEnvironmentName": "batch-mi-cpu-spot",
  "type": "MANAGED",
  "state": "ENABLED",
  "computeResources": {
    "type": "ECS_MANAGED_INSTANCES",
    "maxvCpus": 4,
    "managedInstancesProvider": {
      "infrastructureRoleArn": "<インフラストラクチャロールの ARN>",
      "instanceLaunchTemplate": {
        "ec2InstanceProfileArn": "<インスタンスプロファイルの ARN>",
        "networkConfiguration": {
          "subnets": ["<サブネット ID 1>", "<サブネット ID 2>"],
          "securityGroups": ["<セキュリティグループ ID>"]
        },
        "instanceRequirements": {
          "allowedInstanceTypes": ["c6i.large", "c7i.large", "m6i.large", "m7i.large"]
        },
        "capacityOptionType": "SPOT"
      },
      "infrastructureOptimization": {
        "scaleInAfter": 60
      }
    }
  }
}

このファイルを ce-cpu-spot.json として保存し、コンピューティング環境を作成します。

aws batch create-compute-environment \
  --cli-input-json file://ce-cpu-spot.json \
  --region ap-northeast-1

status が VALID、statusReason が ComputeEnvironment Healthy になれば作成完了です。今回は 5 秒ほどで切り替わりました。

aws batch describe-compute-environments \
  --compute-environments batch-mi-cpu-spot \
  --region ap-northeast-1 \
  --query 'computeEnvironments[0].{status:status,state:state,statusReason:statusReason,type:computeResources.type}'

実行結果

{
    "status": "VALID",
    "state": "ENABLED",
    "statusReason": "ComputeEnvironment Healthy",
    "type": "ECS_MANAGED_INSTANCES"
}

コンソールのコンピューティング環境の一覧では、プロビジョニングモデルが ECS managed instances になっていました。キャプチャは検証を終えた後に撮ったものです。そのため状態の列が Disabled になっていますが、作成直後は Enabled です。

詳細画面では、キャパシティタイプと許可されたインスタンスタイプを確認できます。ステータス理由もここに表示されます。

ジョブキューを作成する

GPU 用のキューは後ほど別に作ります。

aws batch create-job-queue \
  --job-queue-name batch-mi-cpu-spot-queue \
  --priority 100 \
  --compute-environment-order order=1,computeEnvironment=batch-mi-cpu-spot \
  --region ap-northeast-1

ジョブ定義を登録する

ジョブ定義は ecsProperties 形式で書きます。従来の containerProperties は使えません。 コンテナは Amazon Linux 2023 のパブリックイメージです。nproc、uname -m、/proc/cpuinfo で、ホストインスタンスの情報を出力させます。

MEMORY は 2048 MiB にしました。ECS がジョブに割り当てられるメモリは、インスタンスの公称値を下回ります。実測では m7i.large が公称 8192 MiB に対して 7474 MiB でした。公称 4096 MiB の c6i.large や c7i.large では 4096 MiB の要求が通らないので、4 タイプすべてを候補に残すために下げています。

{
  "jobDefinitionName": "batch-mi-cpu-hello",
  "type": "container",
  "platformCapabilities": ["MANAGED_INSTANCES"],
  "ecsProperties": {
    "taskProperties": [
      {
        "executionRoleArn": "<タスク実行ロールの ARN>",
        "runtimePlatform": {
          "operatingSystemFamily": "LINUX",
          "cpuArchitecture": "X86_64"
        },
        "containers": [
          {
            "name": "main",
            "image": "public.ecr.aws/amazonlinux/amazonlinux:2023",
            "command": ["sh", "-c", "echo hello from ECS Managed Instances; nproc; uname -m; grep 'model name' /proc/cpuinfo | head -1; cat /proc/meminfo | head -1"],
            "resourceRequirements": [
              {"type": "VCPU", "value": "2"},
              {"type": "MEMORY", "value": "2048"}
            ]
          }
        ]
      }
    ]
  }
}

このファイルを jd-cpu.json として保存し、ジョブ定義を登録します。

aws batch register-job-definition \
  --cli-input-json file://jd-cpu.json \
  --region ap-northeast-1

ジョブを投入する

インスタンスが 1 台もない状態からジョブを投入します。

aws batch submit-job \
  --job-name mi-cpu-hello-1 \
  --job-queue batch-mi-cpu-spot-queue \
  --job-definition batch-mi-cpu-hello \
  --region ap-northeast-1

ステータスの遷移を追います。次はポーリング結果を時刻順に並べたものです。ブラケットはポーリング時刻なので、待ち時間は createdAt と startedAt の差で見ます。

aws batch describe-jobs --jobs <ジョブ ID> --region ap-northeast-1 \
  --query 'jobs[0].{status:status,createdAt:createdAt,startedAt:startedAt,stoppedAt:stoppedAt,statusReason:statusReason}'

実行結果（整形）

[00:56:15Z] status=SUBMITTED   createdAt 1787792161918
[00:56:26Z] status=RUNNABLE
[00:56:42Z] status=STARTING
[00:56:48Z] status=RUNNING     startedAt 1787792206150
[00:56:59Z] status=SUCCEEDED   stoppedAt 1787792216187

投入から実行開始まで 44.2 秒でした。2 回目は 29.1 秒で、公式ドキュメントの「a few minutes」に対してどちらも 1 分を切りました。

Amazon ECS Managed Instances might take a few minutes to provision capacity when launching instances for the first time.

引用: https://docs.aws.amazon.com/batch/latest/userguide/getting-started-ecs-managed-instances.html

コンテナの出力は CloudWatch Logs に保存されます。ログストリーム名はジョブの詳細から取得します。

aws batch describe-jobs --jobs <ジョブ ID> --region ap-northeast-1 \
  --query 'jobs[0].ecsProperties.taskProperties[0].containers[0].logStreamName' --output text

aws logs get-log-events \
  --log-group-name /aws/batch/job \
  --log-stream-name <ログストリーム名> \
  --region ap-northeast-1 --query 'events[].message' --output text

実行結果

hello from ECS Managed Instances
2
x86_64
model name	: Intel(R) Xeon(R) Platinum 8488C
MemTotal:        7952572 kB

Sapphire Rapids 世代の Xeon で、メモリは約 7.6 GiB です。m7i.large と一致します。

同じ出力は ECS のタスク画面からも追えます。こちらは新しいログが上に並びます。

ジョブ一覧でも作成時刻と開始時刻の差を確認できます。mi-cpu-sleep-1 と mi-hostinfo は別の確認で投入したジョブです。

起動したマネージドインスタンスを確認する

インスタンスを ECS 側から特定する

どのタイプが選ばれるかは事前にわかりません。ECS のコンテナインスタンスから ec2InstanceId を取るのが確実です。

CL=$(aws batch describe-compute-environments --compute-environments batch-mi-cpu-spot \
  --region ap-northeast-1 --query 'computeEnvironments[0].ecsClusterArn' --output text)

CI=$(aws ecs list-container-instances --cluster "$CL" --region ap-northeast-1 \
  --query 'containerInstanceArns[0]' --output text)

aws ecs describe-container-instances --cluster "$CL" --container-instances "$CI" \
  --region ap-northeast-1

attributes の ecs.instance-type に、選ばれたインスタンスタイプが入ります。registeredResources は ECS がこのインスタンスで割り当てられるリソース量です。応答から必要な項目を抜き出して整形しています。

実行結果（抜粋）

ec2InstanceId        = i-0b72a6cdbcacaa6e5
status               = ACTIVE
agentConnected       = True

--- 属性 (attributes) ---
  ecs.ami-id            = ami-05407bd149bd4f625
  ecs.availability-zone = ap-northeast-1c
  ecs.cpu-architecture  = x86_64
  ecs.instance-type     = m7i.large
  ecs.os-family         = LINUX

--- registeredResources ---
  CPU    = 2048
  MEMORY = 7474

1 回目は m7i.large が選ばれました。同じジョブ定義で 3 回投げたところ、2 回目は c7i.large、3 回目は c6i.large です。列挙した 4 タイプのうち 3 種類が使われました。

MEMORY は 7474 MiB です。m7i.large の公称メモリ 8192 MiB より 718 MiB 少なくなっています。

EC2 側の属性も、インスタンス ID を指定すれば取得できました。

aws ec2 describe-instances --instance-ids <インスタンス ID> --region ap-northeast-1

実行結果（抜粋）

InstanceType          = m7i.large
InstanceLifecycle     = spot
SpotInstanceRequestId = sir-w6j7jdin
AZ                    = ap-northeast-1c
ImageId               = ami-05407bd149bd4f625
RootDeviceName        = /dev/xvda

InstanceLifecycle が spot で、capacityOptionType の指定どおりスポットで起動していました。

ホストは Bottlerocket でストレージは 2 個

使われた AMI を確認します。

aws ec2 describe-images --image-ids <AMI ID> --region ap-northeast-1 \
  --query 'Images[0].{Name:Name,Owner:OwnerId,Desc:Description,Root:RootDeviceName}'

実行結果

{
    "Name": "ecs-managed-instances-standard-x86_64-20260807152311",
    "Owner": "679336465495",
    "Desc": "ECS Managed Instances AMI (variant: standard, x86_64)",
    "Root": "/dev/xvda"
}

AMI 名に Bottlerocket の文字はありません。ホストの OS を確かめるため、/proc/version と df を出力するジョブを流しました。カーネルのビルドツールチェーンが x86_64-bottlerocket-linux-gnu-gcc で、Bottlerocket 上のカーネルとわかりました。

実行結果（抜粋）

  ---proc-version---
+ Linux version 6.1.177 (builder@buildkitsandbox) (x86_64-bottlerocket-linux-gnu-gcc (Buildroot 2025.05.1) 13.4.0, GNU ld (GNU Binutils) 2.44) #1 SMP PREEMPT_DYNAMIC Wed Aug  5 16:35:02 UTC 2026
  ---os-release---
  NAME="Amazon Linux"
  VERSION="2023"
  ---mounts---
  Filesystem      Size  Used Avail Use% Mounted on
+ overlay          79G  214M   74G   1% /

/etc/os-release が Amazon Linux 2023 を返すのはコンテナイメージ側のものです。

アタッチされている EBS も確認します。ボリューム ID は describe-instances の BlockDeviceMappings から取れます。

aws ec2 describe-volumes --volume-ids <ボリューム ID 1> <ボリューム ID 2> --region ap-northeast-1 \
  --query 'Volumes[].{Id:VolumeId,SizeGiB:Size,Type:VolumeType,Device:Attachments[0].Device}' --output table

実行結果

-------------------------------------------------------------
|                      DescribeVolumes                      |
+------------+-------------------------+----------+---------+
|   Device   |           Id            | SizeGiB  |  Type   |
+------------+-------------------------+----------+---------+
|  /dev/xvdcz|  vol-0b685b3953dd9db18  |  80      |  gp3    |
|  /dev/xvda |  vol-0e4d21149cba04b4b  |  8       |  gp3    |
+------------+-------------------------+----------+---------+

EBS は 2 本アタッチされていました。ルートの /dev/xvda が 8 GiB で、これは AMI の定義どおりです。もう 1 本の /dev/xvdcz が 80 GiB で、コンテナのルートファイルシステム（overlay 79 GiB）に使われていました。ECS 側のドキュメントは、インスタンスにアタッチされるデータボリュームとして最小 30 GiB、最大 16,384 GiB、既定 80 GiB と説明しています。今回の結果はこちらと一致しました。

GPU ジョブはオンデマンドで動かす

GPU を搭載したマネージドインスタンスには、NVIDIA ドライバと CUDA Toolkit がプリインストールされています。

When you use GPU-enabled instance types with Amazon ECS Managed Instances, the NVIDIA drivers and CUDA toolkit are pre-installed on the instance, making it easier to run GPU-accelerated workloads.

出典: Use GPUs with Amazon ECS Managed Instances - Amazon Elastic Container Service

GPU オンデマンドのコンピューティング環境を作成する

こちらは capacityOptionType を ON_DEMAND にします。allowedInstanceTypes には、GPU ジョブ対応表に載っているファミリーから 3 タイプを並べました。いずれも 4 vCPU で GPU を 1 基積んでいます。

{
  "computeEnvironmentName": "batch-mi-gpu-ondemand",
  "type": "MANAGED",
  "state": "ENABLED",
  "computeResources": {
    "type": "ECS_MANAGED_INSTANCES",
    "maxvCpus": 4,
    "managedInstancesProvider": {
      "infrastructureRoleArn": "<インフラストラクチャロールの ARN>",
      "instanceLaunchTemplate": {
        "ec2InstanceProfileArn": "<インスタンスプロファイルの ARN>",
        "networkConfiguration": {
          "subnets": ["<サブネット ID 1>", "<サブネット ID 2>"],
          "securityGroups": ["<セキュリティグループ ID>"]
        },
        "instanceRequirements": {
          "allowedInstanceTypes": ["g4dn.xlarge", "g5.xlarge", "g6.xlarge"]
        },
        "capacityOptionType": "ON_DEMAND"
      },
      "infrastructureOptimization": {
        "scaleInAfter": 60
      }
    }
  }
}

このファイルを ce-gpu-ondemand.json として保存し、コンピューティング環境とジョブキューを作成します。

aws batch create-compute-environment \
  --cli-input-json file://ce-gpu-ondemand.json \
  --region ap-northeast-1

aws batch create-job-queue \
  --job-queue-name batch-mi-gpu-queue \
  --priority 100 \
  --compute-environment-order order=1,computeEnvironment=batch-mi-gpu-ondemand \
  --region ap-northeast-1

詳細画面でキャパシティタイプが ON_DEMAND、許可されたインスタンスタイプが 3 種類になっていることを確認できます。

ジョブ定義を登録して投入する

GPU を要求するには resourceRequirements に GPU を足します。ここが Fargate との差分です。コンテナイメージは CPU ジョブと同じ Amazon Linux 2023 のままにしました。

{
  "jobDefinitionName": "batch-mi-gpu-nvidia-smi",
  "type": "container",
  "platformCapabilities": ["MANAGED_INSTANCES"],
  "ecsProperties": {
    "taskProperties": [
      {
        "executionRoleArn": "<タスク実行ロールの ARN>",
        "runtimePlatform": {
          "operatingSystemFamily": "LINUX",
          "cpuArchitecture": "X86_64"
        },
        "containers": [
          {
            "name": "main",
            "image": "public.ecr.aws/amazonlinux/amazonlinux:2023",
            "command": ["sh", "-c", "nvidia-smi"],
            "resourceRequirements": [
              {"type": "VCPU", "value": "2"},
              {"type": "MEMORY", "value": "4096"},
              {"type": "GPU", "value": "1"}
            ]
          }
        ]
      }
    ]
  }
}

このファイルを jd-gpu.json として保存し、登録したうえで GPU 用のキューに投入します。

aws batch register-job-definition \
  --cli-input-json file://jd-gpu.json \
  --region ap-northeast-1

aws batch submit-job \
  --job-name mi-gpu-nvidia-smi-1 \
  --job-queue batch-mi-gpu-queue \
  --job-definition batch-mi-gpu-nvidia-smi \
  --region ap-northeast-1

投入から 36.4 秒で実行が始まり、10 秒ほどで成功しました。

コンテナから GPU が見えることを確認する

ドライバのバージョンと GPU 名を CloudWatch Logs から確認します。手順は CPU ジョブと同じです。

aws batch describe-jobs --jobs <ジョブ ID> --region ap-northeast-1 \
  --query 'jobs[0].ecsProperties.taskProperties[0].containers[0].logStreamName' --output text

aws logs get-log-events \
  --log-group-name /aws/batch/job \
  --log-stream-name <ログストリーム名> \
  --region ap-northeast-1 --query 'events[].message' --output text

搭載されているのは NVIDIA T4 で、ドライバは 580.159.03 です。CUDA Version はドライバが対応する CUDA のバージョンを示します。CUDA ベースのイメージに差し替えなくても、nvidia-smi がそのまま実行できました。

実行結果（抜粋）

Thu Aug 27 01:07:38 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.159.03             Driver Version: 580.159.03     CUDA Version: 13.0     |
+-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
|=========================================+========================+======================|
|   0  Tesla T4                       On  |   00000000:00:1E.0 Off |                    0 |
| N/A   36C    P8             15W /   70W |       1MiB /  15360MiB |      0%      Default |
+-----------------------------------------+------------------------+----------------------+

CloudWatch Logs のコンソールでは、nvidia-smi の出力が枠線も含めて 1 行ずつ別のログイベントとして記録されていました。

起動したインスタンスも CPU 側と同じ手順で確認します。ECS のコンテナインスタンスを見ると、registeredResources に GPU が UUID 付きで登録されていました。

実行結果（抜粋）

  ecs.instance-type = g4dn.xlarge
  ecs.availability-zone = ap-northeast-1a

registeredResources:
   CPU    = 4096
   MEMORY = 15110
   GPU    = ['GPU-18a44874-1449-5e44-0c24-63c538fb9cb9']

列挙した 3 タイプのうち g4dn.xlarge が起動しました。CPU 側で spot が入っていた InstanceLifecycle は、こちらでは空です。capacityOptionType の指定どおりオンデマンドで起動していました。

AMI も CPU とは違うものが使われていました。CPU のときは ecs-managed-instances-standard-x86_64-... でした。GPU は ecs-managed-instances-nvidia-x86_64-... です。

実行結果

{
    "Name": "ecs-managed-instances-nvidia-x86_64-20260807152314",
    "Owner": "679336465495",
    "Desc": "ECS Managed Instances AMI (variant: nvidia, x86_64)",
    "Root": "/dev/xvda"
}

AMI はどちらの環境でも指定していません。GPU 利用では名前に nvidia が入った AMI が自動で選ばれていました。

まとめ

AWS Batch のコンピューティング環境でマネージドインスタンスが選べるようになりました。GPU や特権コンテナを EC2 の面倒を見ずに運用できます。実行開始までの待ち時間は 29 秒から 45 秒ととても早いです。設定は EC2 タイプと互換ではなく、スポットの指定方法もジョブ定義の書き方も変わります。料金は EC2 のインスタンス代の他に管理手数料がかかることが抑えておくポイントです。

おわりに

面倒見たくないし、起動が早い Fargate に寄せたいけれどパワー不足ということはよくあります。そんなかゆいところに手が届く選択肢が AWS Batch に登場したので試しました。思っていたより起動が速く、バッチ処理の待ち時間としては十分実用的でした。

AWS Batch が Amazon ECS Managed Instances をサポートしたので GPU と CPU インスタンスそれぞれ試してみた

はじめに

なにが嬉しいのか

Fargate では扱えないスペック要求でも GPU でも EC2 の面倒をみなくて済む

Fargate では使えない EC2 の購入オプションを適用できる

確認結果

3 タイプの使い分け

使う前に知っておきたいこと

コンピュートノード常時起動の設定はできない

maxvCpus について

ジョブキューではスポットをオンデマンドより前に置けない

インスタンスプロファイルのロール名は ecsInstanceRole で始める

14 日を超えて計算が必要なジョブには向いていない

料金は EC2 料金と管理手数料が発生します

Terraform はまだ対応していない

検証環境

CPU ジョブをスポットで動かす

CPU スポットのコンピューティング環境を作成する

ジョブキューを作成する

ジョブ定義を登録する

ジョブを投入する

起動したマネージドインスタンスを確認する

インスタンスを ECS 側から特定する

ホストは Bottlerocket でストレージは 2 個

GPU ジョブはオンデマンドで動かす

GPU オンデマンドのコンピューティング環境を作成する

ジョブ定義を登録して投入する

コンテナから GPU が見えることを確認する

まとめ

おわりに

参考

関連記事

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

EVENTS