Amazon SageMaker HyperPod の Slurm クラスターで非対応のはずのマネージメントコンソールからの AMI 更新を試してみた

はじめに

Amazon SageMaker HyperPod は、大規模な機械学習向けクラスターの構築や運用をマネージドに行えるサービスです。AMI 更新のコンソール操作は、公式ドキュメント上 Amazon EKS 統合クラスター限定とされ、Slurm クラスターには API または CLI 操作が必須とされていました。ところが今回検証した Slurm クラスターのコンソールには「AMI を更新」フォームが表示され、controller インスタンスグループに対する AMI 更新を試してみました。

出典: Update your AMI version in your SageMaker HyperPod cluster - Amazon SageMaker AI

確認結果

• 公式ドキュメントは Slurm クラスターのマネコンからの AMI 更新を非対応とし、API または CLI 操作を必須としていました
• ですが、マネコンにはAMI を更新画面があり、実際に更新ができました
• AMI 更新はインスタンスの再作成ではなく、ルートボリュームの置き換えの様子でした
• AMI の更新にかかった時間は約 8 分でした

検証環境

SageMaker HyperPod の Slurm クラスターは複数のインスタンスグループで構成されます。Slurm の制御プレーンを担うインスタンスグループが controller です。今回の検証ではこの controller インスタンスグループに対して AMI の更新をかけてみます。

Slurm クラスターの AMI 更新はマネコンから非対応となっている

AMI 更新のマネージメントコンソール操作は Amazon EKS 統合クラスター限定で、Slurm クラスターは API または CLI 操作が必要と明記されています。

Updating your AMI with the AWS console is available only for clusters integrated with Amazon EKS. If you have a Slurm cluster, you must use the SageMaker AI API or CLI operations.

出典: Update your AMI version in your SageMaker HyperPod cluster

ところが、今回検証した Slurm クラスターのコンソールでクラスター詳細画面を開くと「更新が利用可能です」という見出しの通知バナーが表示されました。3 個のインスタンスグループで AMI アップデートが利用可能である旨の説明と、「AMI をアップデート」ボタンがあります。ふーん、なるほど。

マネコンから AMI の更新ができた

「AMI を更新」ボタンを押すと「AMI を更新」という見出しのフォームが開きます。

「範囲」セクションでインスタンスグループを個別にチェックボックスで選択できました。「更新タイミング」セクションでは更新の開始方法を選べました。選択肢は「すぐに開始」「1 回限りのスケジュール」「定期的または 1 回限りの cron ベースのスケジュール」の 3 つでした。

今回は controller インスタンスグループのみを選択し「すぐに開始」を選んで実行しました。実行後、クラスター詳細画面には進行中を示す緑色のバナーが表示されました。

インスタンスは再作成されずルートボリュームだけが入れ替わった模様

更新前後で list-cluster-nodes を実行し、controller インスタンスグループの結果を比較しました。

aws sagemaker list-cluster-nodes --cluster-name <cluster-name> --instance-group-name-contains controller

変化するのは LastSoftwareUpdateTime と ImageVersionStatus だけです。

 {
     "InstanceGroupName": "controller",
     "InstanceId": "i-0a8df5f9f2b2f8aa3",
     "InstanceType": "ml.m5.xlarge",
     "LaunchTime": "2026-08-04T17:42:10.125000+09:00",
-    "LastSoftwareUpdateTime": "2026-08-04T17:42:10.125000+09:00",
+    "LastSoftwareUpdateTime": "2026-08-08T10:10:51.931000+09:00",
     "InstanceStatus": { "Status": "Running", "Message": "" },
-    "ImageVersionStatus": "UpdateAvailable"
+    "ImageVersionStatus": "UpToDate"
 }

InstanceId と LaunchTime が 1 秒も変わらなかった ことは、EC2 インスタンスが終了、再作成されていないということです。更新中、InstanceStatus.Status は SystemUpdating となり、完了すると Running に戻りました。ImageVersionStatus の UpdateAvailable から UpToDate への変化で、更新完了を判定できました。

AMI ステータス列は「アップデートが可能です」から「最新」になりました。更新の対象にしなかった他のインスタンスグループは当然ながらそのままです。

AWS 公式ドキュメントには、Patching（UpdateClusterSoftware）フローで発生するイベントの一覧があります。ここに「Root volume replacement」というイベントが、Slurm と Amazon EKS 共通のものとして定義されています。

Root volume replacement started | Root volume replacement started for Instance <instance-id> in IG <instance-group-name>.

出典: SageMaker HyperPod cluster events reference

このクラスターは NodeProvisioningMode が Continuous でないため、このイベント自体は直接確認できていません。ただし InstanceId と LaunchTime が不変だったため、この動作と一致しています。

AMI ID を確認したいが見つからなくて困った件

AWS CLI でdescribe-cluster、describe-cluster-nodeに AMI ID を返すフィールドはありませんでした。AMI バージョンに関する値も ImageVersionStatus のみでした。SageMaker AI のノードなので EC2 の describe-instances では当然ノードが見つかりませんでした。マネージメントコンソールからも確認できません。AMI ID を確認できたのは、SSM 経由で各ノードに接続し、EC2 インスタンスメタデータサービス（IMDS）を確認する方法だけでした。

SageMaker HyperPod のノードには、HyperPod 専用のターゲット形式で SSM 接続します。controller ノードへの接続コマンドは次のとおりです。<cluster-id> は実際のクラスター ID に置き換えます。describe-cluster が返す ClusterArn の末尾（cluster/ の後ろ）に含まれる ID です。

aws ssm start-session \
  --target "sagemaker-cluster:<cluster-id>_controller-i-0a8df5f9f2b2f8aa3" \
  --region ap-northeast-1

接続後、IMDSv2 のトークンを取得してから ami-id を読み出します。

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/ami-id

login（ユーザーがログインしてジョブを投入する役割のノード）と worker（ジョブを実行する計算ノード）は今回更新の対象にしていません。両インスタンスグループの AMI ID を取得し、controller の更新後の値と比較しました。取得できた AMI ID は次のとおりです。

login と worker は異なるインスタンスタイプでしたが、AMI ID は一致していました。更新前のこのクラスターはインスタンスタイプによらず全ノードが共通の AMI を使用していたことになります。controller の AMI ID だけが異なっていたのは、今回の作業で AMI が更新されたためです。

更新イベントの履歴確認をしたい

更新イベントを確認しようと list-cluster-events を実行したところ、次のエラーが返ってきました。

aws sagemaker list-cluster-events --cluster-name <cluster-name>

An error occurred (ValidationException) when calling the ListClusterEvents operation: ListClusterEvents is only supported for cluster with NodeProvisioningMode set to Continuous

エラーメッセージのとおり、このクラスターの NodeProvisioningMode は Continuous ではありません。この仕様によりこちらのコマンドは使えません。

Cluster events are available for HyperPod clusters with NodeProvisioningMode set to Continuous.

出典: SageMaker HyperPod cluster events reference

そこで更新の呼び出し時刻は CloudTrail から確認しました。

aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=UpdateClusterSoftware --max-items 5

sessionCredentialFromConsole が true になっていることから、この呼び出しがコンソール操作由来であることも確認できました。

{
    "EventName": "UpdateClusterSoftware",
    "EventTime": "2026-08-08T10:02:45+09:00",
    "EventSource": "sagemaker.amazonaws.com",
    "requestParameters": {
        "instanceGroups": [
            { "instanceGroupName": "controller" }
        ],
        "dryRun": false
    },
    "sessionCredentialFromConsole": "true"
}

呼び出し時刻は 2026-08-08T10:02:45+09:00 でした。更新完了を示す LastSoftwareUpdateTime は 2026-08-08T10:10:51.931000+09:00 でした。この差から、AMI 更新の所要時間は約 8 分となります。

まとめ

Amazon SageMaker HyperPod の Slurm クラスターは意外とマネージメントコンソールから AMI を更新できました。更新方式はルートボリューム置換で、InstanceId と LaunchTime は変えずに AMI だけが切り替わります。AMI ID の具体な値は SSM 経由の IMDS アクセスで確認できました。

おわりに

CapacityBlocks for ML で予約済みの GPU インスタンスを別の検証のためにクラスターをお借りしたのですが、AMI 更新があるのか？と気になったので試してみました。

参考

• UpdateClusterSoftware
• Update your AMI version in your SageMaker HyperPod cluster
• SageMaker HyperPod cluster events reference
• Accessing your SageMaker HyperPod cluster nodes