Azure BatchのD/Ds/Dv2/Dsv2/Ls廃止：影響・期限・移行手順

Azure BatchでD-series、Ds-series、Dv2-series、Dsv2-series、Ls-seriesを使用している場合、2028年5月1日までに新しいVMシリーズへ移行する必要があります。期限後は新規プールを作成できないだけでなく、既存プールのスケールアウトもできなくなり、プールが0ノードへ強制的に縮小される可能性があります。

今回の変更はAzure Batch自体の廃止ではありません。対象となるのは、Batchプールのコンピューティングノードに指定しているVMシリーズです。まず既存プールのvmSizeを確認し、代替サイズの性能、リージョン、クォータ、料金を比較したうえで、余裕を持って移行テストを始めましょう。

Azure BatchのVMシリーズ廃止で何が変わるのか

2026年6月11日に公開されたAzureの公式情報では、Azure Batchプールで使用される次のVMシリーズが、2028年5月1日に廃止されると案内されています。

D-series
Ds-series
Dv2-series
Dsv2-series
Ls-series

VMシリーズ自体の廃止予定は以前から公表されていましたが、今回の更新では、Azure Batchプールに起こる具体的な影響が明記されました。(Microsoft Azure)

確認項目	2028年5月1日まで	2028年5月1日以降
既存プール	原則として継続利用可能	使用不能になる可能性がある
新規プールの作成	新規採用は非推奨	対象シリーズでは作成不可
既存プールのスケールアウト	移行完了までは可能	不可
ノード数	通常どおり管理可能	強制的に0ノードへ縮小される可能性がある
残存VM	稼働を継続	停止・割り当て解除され、SLA対象外になる

Microsoftは、現在から2028年5月1日までを移行期間とし、期限到来時には対象プールが利用できなくなる可能性があると説明しています。(Microsoft Azure)

影響を受けるユーザーと受けないユーザー

影響を受けるのは、Azure Batchアカウントの有無だけではなく、プールのVMサイズに対象シリーズを指定している環境です。

特に、次の環境は確認が必要です。

常時稼働するBatchプール
ジョブ実行時だけノードを増やす自動スケールプール
現在は0ノードだが、必要時に再度スケールアウトするプール
Infrastructure as Codeやスクリプトで対象VMサイズを指定している環境
専用ノードまたはSpotノードで対象VMシリーズを使用する環境
開発・検証用として停止したまま残している古いプール

現在のノード数が0でも安全とは限りません。期限後にノードを追加できなければ、ジョブやタスクの定義が残っていても処理を実行できません。

一方、Dsv5やDasv6、Lsv3など、廃止対象とは異なる新しい世代をすでに使用しているプールは、今回の告知による直接の移行対象ではありません。VM名に「D」や「Ls」が含まれるだけで判断せず、世代番号を含む正式なvmSizeを確認してください。

対象プールを確認する方法

Azure Advisorで確認する

最初に確認したいのがAzure Advisorです。

Azureポータルで次の順に開きます。

Azure Advisorを開く
「推奨事項」から「信頼性」を選ぶ
フィルターで「推奨事項のサブカテゴリ」を選ぶ
「サービスのアップグレードと提供終了」を指定する
Batchアカウントに関する推奨事項を確認する

対象環境では、「Migrate Azure Batch Pools from D, Ds, Dv2, Dsv2, Ls Virtual Machines」という推奨事項が表示される場合があります。Advisorでは、廃止日や影響を受けるリソースも確認できます。(Microsoft Learn)

ただし、Advisorの対象リソース情報は常にすべての環境を網羅するとは限りません。表示がない場合も、各Batchプールの設定を直接確認してください。

Azure CLIでVMサイズを一覧表示する

Azure CLIでは、Batchアカウントへログインした後、プールIDとVMサイズを一覧表示できます。

az batch account login \
  --name <Batchアカウント名> \
  --resource-group <リソースグループ名>

az batch pool list \
  --query "[].{Pool:id,VMSize:vmSize}" \
  --output table

az batch pool listは、指定したBatchアカウント内のプールを一覧取得するコマンドです。出力されたvmSizeを、対象シリーズと照合します。(Microsoft Learn)

IaCを使用している場合は、実環境だけでなく、Bicep、ARMテンプレート、Terraform、CLIスクリプト、アプリケーション設定も検索してください。実環境だけを変更しても、次回デプロイで古いVMサイズへ戻される可能性があります。

移行先のVMシリーズを選ぶ基準

Microsoftの移行ガイドでは、主に次の代替シリーズが案内されています。

現在のシリーズ	主な移行候補
D、Ds、Dv2、Dsv2	Dsv5、Ddsv5、Dasv5、Dadsv5、Dsv6、Dasv6、Dsv7、Dasv7など
メモリ要件が大きいD系ワークロード	Esv6、Edsv6、Easv6、Eadsv6など
Ls	Lsv3、Lasv3、Lsv4、Lasv4

これは単純な名称の置き換え表ではありません。同じvCPU数でも、メモリ容量、ディスク性能、ローカルストレージ、ネットワーク性能が異なります。(Microsoft Learn)

移行先は、次の順番で選ぶと失敗を減らせます。

CPUとメモリから候補を絞る

現在のノードについて、次の実績値を確認します。

CPU使用率の平均値とピーク値
メモリ使用量
同時実行タスク数
1ジョブあたりの処理時間
ノード不足による待ち時間

現在と同じvCPU数だけを基準にすると、メモリ不足や過剰スペックが起こります。タスク単位の必要メモリと、1ノードで同時に動かすタスク数から逆算してください。

ディスク構成を確認する

新しいVMシリーズでは、SCSIからNVMeへディスクコントローラーが変わる場合があります。特にv6やv7世代を選ぶ場合は、OSイメージ、ドライバー、デバイス名、起動スクリプトの互換性を確認します。

Lsシリーズから移行する場合は、ローカルNVMeの容量だけでなく、IOPS、スループット、タスク終了時のデータ退避方法も確認してください。

Microsoftは、v6シリーズではNVMe対応OS、Generation 2、MANA対応OSなどが必要になり、リージョンやゾーンによっては必要な容量を確保できない場合があると案内しています。(Microsoft Learn)

リージョンとクォータを確認する

移行先VMがAzure全体で提供されていても、現在のリージョンでAzure Batchから利用できるとは限りません。

利用可能なSKUは、次のコマンドで確認できます。

az batch location list-skus \
  --location <リージョン名> \
  --output table

Azure BatchではVMシリーズごとにコアクォータが設定されます。移行先シリーズのクォータが不足していると、プールを作成できても必要なノード数までスケールできません。移行テストの前に、リージョン内の対応状況とクォータ申請を済ませてください。(Microsoft Learn)

既存プールを更新するか、新規作成するか

Azure Batchでは、現在の管理プレーンAPIを使用すると、既存プールのVMサイズを更新できます。

Batch Management Plane APIのバージョン2024-07-01以降では、プールを0ノードにしたうえでvmSizeを更新できます。VMサイズを含む多くのプロパティは、アクティブなノードが残っている状態では更新できません。(Microsoft Learn)

ただし、本番環境では、次の理由から新しいプールを並行作成する方法が安全です。

旧プールを残したまま比較テストできる
問題が起きた場合に切り戻しやすい
StartTaskやアプリケーションパッケージを段階的に検証できる
OSイメージやネットワーク設定も同時に見直せる
実行中タスクへの影響を避けやすい

短時間の停止を許容でき、構成差分がVMサイズだけであれば既存プールの更新も選択肢になります。複数の設定を同時に変更する場合や、長期間使われてきたプールでは、新規作成のほうがトラブルを切り分けやすくなります。

安全に移行する手順

現在の構成を保存する

次の設定をJSONやIaCとして保存します。

VMサイズとOSイメージ
ノードエージェントSKU
専用ノード数とSpotノード数
自動スケール式
StartTask
アプリケーションパッケージ
仮想ネットワークとサブネット
パブリックIPの設定
マネージドID
コンテナ構成
タスクスロット数
暗号化とディスク設定

移行先プールを小規模に作成する

最初から本番と同じ台数を用意せず、1～2ノードでプロビジョニングを確認します。

特にStartTaskの終了コード、ノードの状態、ストレージへの接続、コンテナイメージの取得を確認してください。

実際のタスクで性能を比較する

単純なベンチマークだけでなく、本番データに近い代表タスクを実行します。

確認する値は次のとおりです。

タスクの処理時間
ノードの準備時間
CPUとメモリのピーク
ディスク読み書き時間
ネットワーク転送量
タスク失敗率
1ジョブあたりの概算料金

新しいVMの時間単価が高くても、処理時間が短くなればジョブ全体の料金は下がる場合があります。時間単価だけでなく、1回の処理を完了する総コストで比較することが重要です。

ジョブの実行先を切り替える

テスト完了後、ジョブ作成処理やスケジュール設定が参照するプールIDを新しいプールへ切り替えます。

切り替え後は、旧プールをすぐに削除せず、一定期間0ノードで残すと切り戻しが容易です。ただし、関連するディスクやネットワークリソースに料金が発生していないか確認してください。

料金で確認すべきポイント

Azure Batchのジョブスケジューリング機能自体に追加料金はなく、主にVM、ストレージ、ネットワークなど、実際に使用する基盤リソースに対して課金されます。(Microsoft Learn)

移行前後では、次の項目を比較します。

VMの従量課金単価
専用ノードとSpotノードの構成
OSによる料金差
マネージドディスクの種類と容量
リージョン間データ転送
Azure Savings Plan
Azure予約
ジョブ実行時間の変化

対象となる旧VMシリーズの既存予約は、原則として元の契約期間が終了するまで有効です。一方、2026年7月1日以降に満了する対象シリーズの予約は、購入または更新できないと案内されています。予約終了後に何も対策しないと従量課金へ移行し、想定外のコスト増につながる可能性があります。(Microsoft Learn)

移行時に失敗しやすいポイント

VMサイズだけを変更して移行完了と判断する

世代変更によって、OS、NVMe、ネットワーク、ローカルディスクの仕様が変わります。ノードが起動しただけで完了とせず、実際のタスクを最後まで実行してください。

自動スケールを確認しない

移行先のクォータ不足や容量不足により、目標ノード数まで増えない場合があります。自動スケール式の評価結果だけでなく、実際の割り当て状態を確認します。

IaCやアプリ側の設定を更新し忘れる

ポータル上で新しいプールを作っても、デプロイテンプレートやアプリケーションが古いvmSizeや旧プールIDを参照していれば、次回実行時に問題が再発します。

期限直前まで移行を待つ

移行期限が近づくほど、同じ移行先SKUに需要が集中し、クォータ申請や容量確保に時間がかかる可能性があります。少なくとも本番移行は2028年に入る前に完了させ、期限までを予備期間として残すのが安全です。

今すぐ実施したいチェックリスト

Azure AdvisorでBatchの廃止推奨事項を確認する
全BatchプールのvmSizeを一覧化する
IaCやスクリプト内の旧VMサイズを検索する
D系またはLs系の移行候補を選定する
対象リージョンでのSKU提供状況を確認する
移行先VMシリーズのコアクォータを確認する
OS、NVMe、Generation 2、MANAの互換性を確認する
小規模な新プールで本番相当タスクを実行する
処理時間とジョブ単位の料金を比較する
予約やSavings Planを含むコスト計画を見直す
2028年5月1日より十分前に本番切り替えを完了する

今回の変更で最も重要なのは、期限後も既存プールをそのまま使い続けられると考えないことです。まずvmSizeを確認し、対象プールが見つかったら、移行先の選定、クォータ確認、小規模テストの順に進めてください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure BatchのD/Ds/Dv2/Dsv2/Ls廃止：影響・期限・移行手順

Azure BatchのVMシリーズ廃止で何が変わるのか

影響を受けるユーザーと受けないユーザー