Azure Virtual MachinesのDCas_cc_v5、DCads_cc_v5、ECas_cc_v5、ECads_cc_v5は、2026年9月1日に廃止されました。期限までに別のVMサイズへResizeされなかった対象VMは停止（割り当て解除）の対象となり、廃止後は同シリーズを利用・購入できません。
すでに期限を過ぎているため、現在必要なのは単純な再起動ではありません。対象VMを洗い出し、ワークロードがNested VirtualizationやConfidential Computingを本当に必要としているかを確認したうえで、通常VMへのResizeまたは新しいConfidential VM・コンテナー環境への再展開を選ぶ必要があります。
特に注意したいのは、cc_v5が一般的なConfidential VMとは異なり、機密性のある子VMを動かすための親VMとして設計されている点です。vCPU数とメモリ容量だけを合わせて移行先を選ぶと、Nested Virtualizationが使えず、子VMを起動できない可能性があります。
cc_v5 Nested Confidential VM廃止で何が起きたのか
今回廃止されたのは、次の4つのVMサイズシリーズです。
| 対象シリーズ | 実際のサイズ名の例 | ローカル一時ディスク |
|---|---|---|
DCas_cc_v5 | Standard_DC16as_cc_v5 | なし |
DCads_cc_v5 | Standard_DC16ads_cc_v5 | あり |
ECas_cc_v5 | Standard_EC16as_cc_v5 | なし |
ECads_cc_v5 | Standard_EC16ads_cc_v5 | あり |
DC系は汎用ワークロード向け、EC系はメモリを多く使用するワークロード向けです。サイズ名にdを含むDCads_cc_v5とECads_cc_v5には、ローカル一時ディスクが付属します。(Microsoft Learn)
廃止による影響は次のとおりです。
| 項目 | 内容 |
|---|---|
| 廃止日 | 2026年9月1日 |
| 未移行VM | 停止（割り当て解除）の対象 |
| 廃止後の扱い | 同シリーズを利用・購入できない |
| 必要な対応 | サポート対象の別サイズへResize、または新環境へ再展開 |
| 対象範囲 | 単体VM、Virtual Machine Scale Sets、対象SKUを利用するサービス |
停止（割り当て解除）はVMやディスクの削除とは異なります。OSディスクとデータディスクはResizeによって変更されませんが、動的なパブリックIPアドレスは割り当て解除によって変わる可能性があります。(Microsoft Learn)
cc_v5は通常のConfidential VMと何が違うのか
cc_v5のccは、Confidential Child Capableを示します。親となるAzure VMの中でNested Virtualizationを利用し、AMD SEV-SNPで保護された子VMを実行するためのシリーズです。
重要なのは、cc_v5の親VM自体は、一般的なConfidential VMと同じセキュリティ構成ではないことです。cc_v5では親VMにStandardセキュリティタイプを指定し、その内部に機密性を持つ子VMを作成します。(Microsoft Learn)
一方、一般的なConfidential VMは、Azure上のVM自体をAMD SEV-SNPやIntel TDXで保護します。そのため、次の2つは同じ構成ではありません。
- cc_v5の親VM内で、機密性のある子VMを動かす
- Azure VM自体をConfidential VMとして動かす
Microsoftのドキュメントでは、非Confidential VMからConfidential VMへの単純なResizeはできないとされています。したがって、Standardセキュリティタイプのcc_v5から、通常のConfidential VMシリーズへ移行する場合は、サイズ変更だけで完了せず、新しいVMへの再展開が必要になるケースがあります。(Microsoft Learn)
まず対象VMとVM Scale Setsを洗い出す
対象リソースが1台だけとは限りません。複数のサブスクリプション、検証環境、停止中VM、Virtual Machine Scale Setsも含めて確認します。
Azureポータルの「Resource Graph Explorer」で、次のクエリを実行すると、cc_v5を使用するVMとVM Scale Setsを一覧化できます。
Resources
| where type in~ (
'microsoft.compute/virtualmachines',
'microsoft.compute/virtualmachinescalesets'
)
| extend vmSize = case(
type =~ 'microsoft.compute/virtualmachines',
tostring(properties.hardwareProfile.vmSize),
type =~ 'microsoft.compute/virtualmachinescalesets',
tostring(sku.name),
''
)
| extend normalizedSize = tolower(vmSize)
| where (
normalizedSize startswith 'standard_dc'
or normalizedSize startswith 'standard_ec'
)
| where normalizedSize endswith '_cc_v5'
| project
subscriptionId,
resourceGroup,
name,
type,
location,
vmSize
| order by subscriptionId asc, resourceGroup asc, name asc検索結果はCSVへ出力し、少なくとも次の情報を追加して管理します。
| 管理項目 | 確認内容 |
|---|---|
| システム名 | どの業務やサービスで使われているか |
| 管理者 | 移行判断と作業を担当する部署・担当者 |
| Nested Virtualization | Hyper-V、KVM、子VMを使用しているか |
| Confidential要件 | VMまたは子VMの機密性が必須か |
| 移行先 | Resize先または新しい実行基盤 |
| 移行方法 | Resize、再構築、コンテナー移行など |
| バックアップ | 復元可能なバックアップがあるか |
| 動作確認 | OS、ネットワーク、アプリの確認項目 |
Azure Kubernetes Serviceなどのマネージドサービスで対象SKUを利用している場合、基盤VMを直接変更するのではなく、サービス側の移行方法を確認してください。
移行先は「機密性」と「Nested Virtualization」で決める
cc_v5の移行先は、現在のvCPU数やメモリ容量だけでは決められません。次の2点を先に確認します。
- 親VM上で子VMを実行しているか
- VMまたは子VMにConfidential Computingが必要か
判断の目安は次のとおりです。
| 現在の利用目的 | 移行先の候補 | 基本的な移行方法 |
|---|---|---|
| 通常のOS・アプリのみ | Dasv5、Dadsv5、Easv5、Eadsv5など | 互換性を確認してResize |
| 機密性を必要としない子VMを実行 | Nested Virtualization対応の通常VM | Resizeまたは再構築 |
| Azure VM自体を機密化したい | DCasv6、ECasv6、DCesv6など | 新しいConfidential VMへ再展開 |
| Confidential Containerを実行したい | Confidential ACIなど | コンテナー環境へ移行 |
| AKSで機密コンテナーを実行したい | Confidential Container対応ノード | 新しいノード環境へ移行 |
| 機密性のある子VMを継続したい | アーキテクチャを含めた再設計 | Microsoftへの確認を含む個別対応 |
Microsoftの移行ガイドでは、通常ワークロードの候補としてDasv5、Dadsv5、Easv5、Eadsv5が案内されています。Confidential Computingが必要な場合は、v6世代のConfidential VMやConfidential Container環境が候補です。ただし、実際に利用できるシリーズ、リージョン、ゾーン、提供段階はサブスクリプションごとに確認する必要があります。(Microsoft Learn)
v6のConfidential VMはcc_v5の互換代替ではない
DCasv6やDCadsv6、DCesv6はConfidential VMですが、Microsoftのサイズ仕様ではNested Virtualizationがサポートされていません。
そのため、cc_v5内でHyper-VやKVMを使用して子VMを動かしていた環境を、v6シリーズへそのまま置き換えることはできません。子VMのワークロードを親VMへ統合する、複数のConfidential VMへ分割する、またはコンテナー化するといった構成変更が必要です。(Microsoft Learn)
Resizeで対応できるケースと再展開が必要なケース
Azure VMのResizeで対応できるかは、ポータルの候補一覧やaz vm list-vm-resize-optionsに目的のサイズが表示されるかだけでなく、セキュリティタイプやディスク構成も含めて判断します。
Resizeを選びやすいケース
次の条件を満たす場合は、既存VMのResizeを検討できます。
- Confidential Computingが不要
- cc_v5内で子VMを動かしていない
- 移行先が現在のリージョンとゾーンで利用できる
- 移行先がResize候補として表示される
- ディスク、NIC、最大IOPS、最大スループットの要件を満たす
- Windows VMではローカル一時ディスクの有無が互換条件を満たす
- SCSIとリモートNVMeの互換性に問題がない
Azure VMのResizeでは通常、VMの再起動が発生します。目的のサイズが現在のハードウェアクラスターに存在しない場合は、先にVMを停止して割り当て解除する必要があります。(Microsoft Learn)
新しいVMへの再展開を選ぶケース
次の場合は、単純なResizeではなく再展開を前提にします。
- cc_v5から通常のConfidential VMへ変更する
- セキュリティタイプを
StandardからConfidentialVMへ変更する - 現在のリージョンやゾーンから移動する
- Resize候補に目的のサイズが表示されない
- Windows VMで一時ディスクあり・なしの構成を変更する
- SCSIベースのVMからリモートNVMe対応VMへ変更する
- Nested Confidential VMを別のアーキテクチャへ移行する
- AKSやマネージドサービスの基盤として利用している
Windows VMは、ローカル一時ディスクを持つサイズ同士、または持たないサイズ同士でのResizeが基本です。Linux VMでは一時ディスクの有無をまたぐResizeもサポートされていますが、マウント先やアプリケーションの一時データ利用状況を確認してから実施してください。(Microsoft Learn)
Resize前に確認するチェックリスト
本番VMを変更する前に、次の項目を確認します。
| 確認項目 | 実施内容 |
|---|---|
| バックアップ | Azure Backupの復旧ポイントや必要なスナップショットを確認する |
| 現在の構成 | VMサイズ、OS、ディスク、NIC、IP、拡張機能を記録する |
| セキュリティタイプ | Standard、TrustedLaunch、ConfidentialVMのどれかを確認する |
| Nested Virtualization | Hyper-V、KVM、WSL、エミュレーターなどの利用を確認する |
| ディスク性能 | 最大IOPS、スループット、ディスク数を比較する |
| ネットワーク | NIC数、Accelerated Networking、動的IPを確認する |
| クォータ | 移行先VMファミリーのvCPUクォータを確認する |
| 容量 | 対象リージョン・ゾーンで実際に割り当て可能か確認する |
| 停止時間 | Resize、再起動、アプリ確認を含む作業時間を確保する |
| ロールバック | 元の構成へ戻せない場合の復旧手順を決める |
AzureのvCPUクォータは、リージョン全体の上限とVMファミリー単位の上限に分かれています。また、クォータが十分でも、データセンター側の物理容量が確保されているとは限りません。割り当てに失敗する場合は、別サイズ、別ゾーン、別リージョンも検討します。(Microsoft Learn)
Azureポータルでcc_v5 VMをResizeする手順
通常VMへの移行でResizeが可能な場合は、次の手順で作業します。
- Azureポータルで対象の仮想マシンを開きます。
- OSディスク、データディスク、NIC、現在のVMサイズを記録します。
- バックアップまたは必要なスナップショットを確認します。
- VMが実行中の場合は「停止」を選択し、停止（割り当て解除）まで待ちます。
- 左側のメニューから「サイズ」を開きます。
- 要件を満たすサポート対象サイズを選択します。
- 「サイズ変更」を実行します。
- VMを起動し、OSとアプリケーションを確認します。
移行先を選ぶ際は、単にvCPU数とメモリ容量を近づけるだけでなく、次の項目を比較してください。
- ローカル一時ディスクの有無
- Premium SSD対応
- 最大データディスク数
- ディスクIOPSとスループット
- NIC数とネットワーク帯域
- Accelerated Networking対応
- Nested Virtualization対応
- セキュリティタイプ
- リージョンと可用性ゾーン
Resize後は、ポータルに表示されるサイズだけで判断せず、VMが実際に起動し、アプリケーションが正常に処理できることまで確認します。
Azure CLIでResizeする手順
Azure CLIまたはAzure Cloud Shellを利用する場合は、最初にResize可能なサイズを確認します。
resourceGroup="<resource-group>"
vmName="<vm-name>"
newSize="<supported-vm-size>"
az vm list-vm-resize-options \
--resource-group "$resourceGroup" \
--name "$vmName" \
--query "[].name" \
--output table目的のサイズが一覧に表示されることを確認してから、停止、Resize、起動を実行します。
az vm deallocate \
--resource-group "$resourceGroup" \
--name "$vmName"
az vm resize \
--resource-group "$resourceGroup" \
--name "$vmName" \
--size "$newSize"
az vm start \
--resource-group "$resourceGroup" \
--name "$vmName"最後に、適用されたサイズと電源状態を確認します。
az vm show \
--resource-group "$resourceGroup" \
--name "$vmName" \
--show-details \
--query "{size:hardwareProfile.vmSize,powerState:powerState,privateIps:privateIps,publicIps:publicIps}" \
--output tableVMの割り当て解除、Resize、起動はMicrosoftの移行手順でも案内されています。目的のサイズが表示されない場合は、無理にサイズ名を指定せず、セキュリティタイプ、リージョン、ゾーン、クォータ、容量を再確認してください。(Microsoft Learn)
すでにDeallocateされているVMを復旧する流れ
期限までに移行できず、対象VMが停止（割り当て解除）になっている場合は、次の順序で対応します。
VMやディスクを削除しない
まず、対象VMを作り直そうとして削除しないことが重要です。OSディスク、データディスク、NIC、マネージドID、拡張機能など、復旧に必要な構成を確認します。
Resize候補を確認する
ポータルの「サイズ」またはaz vm list-vm-resize-optionsで、現在のVMから変更できるサイズを確認します。
通常VMで問題ない場合は、Dasv5やEasv5などを含め、必要なCPU、メモリ、ディスク性能を満たすサイズを選びます。
対応サイズへResizeして起動する
互換性のあるサイズが見つかった場合は、VMが割り当て解除された状態でResizeし、起動します。同じcc_v5サイズのまま起動を繰り返すのではなく、サポート対象サイズへの変更が必要です。
Resizeできない場合は新しいVMを構築する
Confidential VMへの変更や、Nested Virtualization構成の変更が必要な場合は、新しいVMを構築します。
一般的な流れは次のとおりです。
- 移行先のVMまたは実行基盤を作成する
- OS、ミドルウェア、拡張機能を設定する
- データディスクまたはバックアップからデータを移行する
- アプリケーションを起動して動作確認する
- DNS、ロードバランサー、接続先を切り替える
- 旧VMを一定期間保持してから削除する
Virtual Machine Scale Setsはモデル側も変更する
Virtual Machine Scale Setsでcc_v5を使用している場合、個別インスタンスだけを変更しても十分ではありません。
スケールセットのSKUとモデルをサポート対象サイズへ変更し、アップグレードポリシーに従って各インスタンスへ反映します。自動スケールによって新しいインスタンスが作成される可能性もあるため、旧cc_v5がモデルに残っていないことを確認してください。
AKSなどのマネージドサービスで利用している場合は、基盤のVMSSを直接変更せず、サポート対象サイズを使用する新しいノード環境を作成し、サービス側の手順でワークロードを移行します。cc_v5を利用するVM Scale Setsや関連サービスも今回の廃止対象に含まれます。(Microsoft Learn)
cc_v5移行で失敗しやすいポイント
vCPU数とメモリ容量だけで移行先を決める
同じvCPU数とメモリ容量でも、Nested Virtualization、ディスク性能、NIC数、セキュリティタイプは異なります。
特にcc_v5で子VMを動かしている場合、移行先がNested Virtualizationに対応していなければ、親VMは起動できても子VMは動きません。
DCasv6へそのままResizeできると思い込む
DCasv6はConfidential VMですが、cc_v5と同じNested Confidential VMの親環境ではありません。また、StandardセキュリティタイプからConfidential VMへの変更は、通常のResizeだけでは完了しません。
「Confidential」という名称が共通していることと、構成互換性があることは別問題です。
クォータの増加だけで容量を確保できると思う
クォータはサブスクリプションで使用できるvCPU数の上限です。データセンターで対象サイズを割り当てられる物理容量とは異なります。
本番移行前に検証VMを作成するなど、対象リージョンとゾーンで実際に割り当て可能か確認します。
動的パブリックIPを確認しない
割り当て解除によって動的パブリックIPアドレスが変わる可能性があります。IPアドレスを接続先やファイアウォールの許可リストへ直接登録している場合は、事前に静的割り当てを検討します。(Microsoft Learn)
VM Scale Setsや停止中の検証VMを見落とす
Azureポータルで稼働中VMだけを確認すると、停止中VMやVM Scale Setsを見落とします。Resource Graphでサブスクリプション全体を検索し、廃止サイズが残っていないことを確認してください。
cc_v5 VM廃止に関するよくある疑問
DeallocateされたVMのディスクは削除されますか
停止（割り当て解除）だけで、OSディスクやデータディスクが削除されるわけではありません。サポート対象サイズへResizeできれば、既存ディスクを利用して起動できる可能性があります。(Microsoft Learn)
cc_v5のまま再起動できますか
cc_v5シリーズは2026年9月1日に廃止され、以後は利用できません。同じサイズでの再起動ではなく、別のサポート対象サイズへのResizeまたは再展開が必要です。
DCasv6やECasv6へ変更すれば機能を維持できますか
VM自体のConfidential Computingには利用できますが、cc_v5と同じNested Confidential VM構成を維持できるとは限りません。v6のConfidential VMではNested Virtualizationがサポートされていないため、子VMを使用している場合はアーキテクチャの変更が必要です。(Microsoft Learn)
Resize候補に目的のサイズが表示されない場合はどうしますか
VMを割り当て解除した状態でもう一度候補を確認します。それでも表示されない場合は、セキュリティタイプ、ディスク構成、リージョン、ゾーン、クォータ、物理容量のいずれかが条件を満たしていない可能性があります。
別サイズへの変更、別環境への再展開、またはMicrosoftサポートへの確認を検討してください。
対象確認後、Resizeか再展開かを早急に決める
cc_v5 Nested Confidential VMは、2026年9月1日の廃止期限をすでに過ぎています。未対応のVMが残っている場合は、次の順序で対応してください。
- Resource GraphでVMとVM Scale Setsを検索する
- Nested VirtualizationとConfidential Computingの要否を確認する
- 通常VMへのResizeか、新環境への再展開かを決める
- クォータと実際の容量を確認する
- バックアップと停止時間を確保する
- Resizeまたは再展開を実施する
- OS、ディスク、ネットワーク、子VM、アプリを確認する
- cc_v5が残っていないことを再検索する
通常のアプリケーションしか動かしていないVMは、比較的容易に別のD系・E系サイズへ移行できます。一方、機密性のある子VMを動かしていた環境では、単純なResizeではなく、Confidential VMやConfidential Containerを使った構成変更が必要です。
最初に「子VMを使っているか」「機密性が必要か」の2点を確認することが、移行先の誤選択を防ぐ最も重要な判断基準です。
コメント