Azure VMware Solution AV36を利用している環境では、2027年9月30日までに移行計画を具体化し、AV36上のワークロードを退避する必要があります。今回のポイントは、単に「古いノードのサポートが終わる」だけではありません。公式情報では、2027年10月1日以降、対象のAV36 SDDCへアクセスできなくなるとされています。(Microsoft Azure)
特に注意したいのは、AV36 SKUが次世代のVMware Cloud Foundation（VCF）9に対応しない点です。BroadcomのVCFロードマップに合わせて、現在のAV36向けVCFバージョンのサポートが2027年9月30日に終了するため、AV36のまま延命する前提ではなく、別SKUへの移行、Azureネイティブ化、または別基盤への退避を早めに検討する必要があります。(Microsoft Azure)
Azure VMware Solution AV36のサポート終了で何が変わるのか
Microsoft AzureのAzure Updatesで公開・更新された「Retirement: Azure VMware Solution AV36 node End of Support on September 30, 2027」は、Azure VMware Solution（AVS）のAV36ノードを利用する組織に向けた重要な廃止・変更予告です。
今回の変更は、Microsoft単独のサービス整理というより、VMware Cloud FoundationのライフサイクルとBroadcom側のロードマップに合わせたものです。AV36で利用されている現行VCFバージョンのサポートが終了し、AV36 SKUはVCF 9に対応しないため、AV36を継続利用する設計は成立しにくくなります。(Microsoft Azure)
| 確認項目 | 内容 |
|---|---|
| 対象サービス | Azure VMware Solution |
| 対象SKU | AV36 |
| 公式情報の公開・更新日 | 2026年6月2日 |
| サポート終了日 | 2027年9月30日 |
| 重要な変更点 | AV36向け現行VCFバージョンのサポート終了、AV36のVCF 9非対応 |
| 実務上の影響 | 2027年10月1日以降、対象AV36 SDDCにアクセスできなくなる |
| 契約面の注意 | 個別のReserved Instance（RI）の有効期限にかかわらず、AV36 SDDCは期限後に廃止対象となる |
Microsoftの通知では、すべてのAV36 SDDCは個別のRI期限に関係なく2027年9月30日後に廃止され、2027年10月1日にはアクセスできなくなると説明されています。さらに、必要に応じた取り出しを支援するため、顧客データは最大60日間の限定期間で安全に保持されるとされています。これは「通常運用を継続できる猶予」ではなく、あくまでデータ取得支援のための期間と考えるべきです。(Microsoft Azure) (Microsoft Azure)
影響を受ける環境
影響を受けるのは、Azure VMware SolutionでAV36ノードを利用しているプライベートクラウド、つまりAV36ベースのSDDCです。
AVSは、Azure上でVMware vSphereベースのプライベートクラウドを利用できるサービスです。Microsoft Learnでは、AV36、AV36P、AV48、AV52、AV64などのホストタイプが示されており、AV36はIntel Xeon Gold 6140、576GB RAMを備えるホストとして整理されています。(Microsoft Learn)
確認すべき対象は、本番環境だけではありません。次のような環境も棚卸しに含めてください。
| 環境 | 見落としやすい理由 | 確認ポイント |
|---|---|---|
| 本番AVS環境 | 業務影響が大きいため把握されやすい | 重要システム、移行順序、停止可能時間 |
| 検証・開発環境 | 利用者が部門単位で分散しやすい | アプリチーム所有のVM、テンプレート、ISO |
| DR・待機系環境 | 平常時に稼働率が低く、棚卸しから漏れやすい | レプリケーション先、復旧手順、バックアップ世代 |
| 一時移行用のAVS環境 | 移行完了後も残っている場合がある | 不要リソース、残データ、課金状態 |
| 連携基盤 | AVS本体ではなく周辺設定に依存が残る | ExpressRoute、VPN、DNS、監視、バックアップ |
特に危険なのは、「本番VMは把握しているが、テンプレート、スナップショット、バックアップ、移行用ネットワーク、監視設定までは見ていない」というケースです。2027年10月1日以降にAV36 SDDCへアクセスできなくなる前提で、VMだけでなく運用資産も含めて退避対象を洗い出す必要があります。(Microsoft Azure)
管理者がまず確認すべきこと
AV36のサポート終了対応では、最初に「自社が本当にAV36を使っているか」「どのサブスクリプションに存在するか」「誰が所有しているか」を明確にします。
Azure Portalで確認する場合は、Azure VMware Solutionのプライベートクラウドを開き、SKU、リージョン、クラスター、ノード数、接続構成を確認します。Azure CLIを利用している環境では、az vmware private-cloud listやaz vmware private-cloud showでプライベートクラウド情報を確認できます。これらのコマンドはAzure CLIのvmware拡張に含まれています。(Microsoft Learn)
az vmware private-cloud list -o table特定のプライベートクラウドを詳しく確認する場合は、次のようにJSON出力でSKUや状態を確認します。実際の出力項目はCLI拡張やAPIのバージョンで変わる可能性があるため、まずは-o jsoncで全体を確認してください。
az vmware private-cloud show \
--resource-group <resource-group-name> \
--name <private-cloud-name> \
-o jsonc複数サブスクリプションを横断して調べる場合は、Azure Resource GraphでAVSプライベートクラウドを一覧化すると、見落としを減らせます。
resources
| where type =~ 'microsoft.avs/privateclouds'
| project subscriptionId, resourceGroup, name, location, skuName=tostring(sku.name), provisioningState=tostring(properties.provisioningState)棚卸しでは、少なくとも次の項目を一覧にしてください。
| 項目 | 確認する理由 |
|---|---|
| サブスクリプションID | 所有部門と課金責任を特定するため |
| リソースグループ | 管理単位とIaC管理の有無を確認するため |
| リージョン | 移行先SKUの提供状況やネットワーク再設計に影響するため |
| SKUとノード数 | AV36対象か、容量移行が必要かを判断するため |
| RIの期限 | 予算・契約調整に必要。ただしサービス期限の延長にはならない |
| VM一覧 | 移行対象、廃止対象、所有者不明VMを分けるため |
| ネットワーク構成 | ExpressRoute、NSX、DNS、FWルールの再設計に必要 |
| バックアップ・DR | 期限後に復旧できない設計を避けるため |
| 監視・運用ジョブ | 移行後の監視漏れや自動処理失敗を防ぐため |
RIの期限とサポート終了日は別物として扱う
今回の通知で最も誤解しやすいのが、Reserved Instance（RI）との関係です。
公式情報では、個別のRI有効期限にかかわらず、AV36 SDDCは2027年9月30日後に廃止されるとされています。つまり、RIの契約期間が残っているように見えても、それを理由にAV36環境の運用継続を前提にしてはいけません。(Microsoft Azure)
実務では、次の3点を分けて管理してください。
| 観点 | 確認内容 |
|---|---|
| 技術期限 | 2027年9月30日までにAV36から退避できるか |
| 契約・課金 | RI、VCFサブスクリプション、移行先SKUの費用をどう扱うか |
| 業務期限 | 本番停止、検証、監査、ユーザー受入の完了時期 |
「RIが残っているから後でよい」と判断すると、移行先の容量確保、ネットワーク変更、アプリ検証の時間が不足します。RIは会計・契約の論点であり、サービスアクセス期限の延長策ではない、という整理が重要です。
移行先を選ぶときの判断基準
AV36からの移行先は、単純に「新しいAVS SKUへ置き換える」だけではありません。アプリケーションの性質、VMware運用を継続する必要性、ネットワーク制約、コスト、運用体制を踏まえて選びます。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| AVSの別SKUへ移行 | vSphere運用、NSX、既存VMwareスキルを継続したい | SKUの提供リージョン、クォータ、VCFライセンス、性能差を確認 |
| Azure VMへ移行 | OS単位での移行が可能で、VMware依存が小さい | IP変更、バックアップ、監視、運用手順の再設計が必要 |
| Azure PaaSへ移行 | DB、Web、バッチなどをクラウドネイティブ化できる | アプリ改修、データ移行、性能検証、運用権限の見直しが必要 |
| オンプレミスまたは別VCF基盤へ戻す | レイテンシ、規制、既存ライセンスの都合が強い | ハードウェア調達、VCF契約、回線、DR設計に時間がかかる |
| 廃止・統合 | 使われていない検証VMや旧システムが多い | 所有者確認とデータ保持要件の確認が必要 |
AVSを継続する場合でも、利用可能なノードタイプはリージョンや提供状況に左右されます。MicrosoftのAVS価格ページでは、AV36P、AV48、AV52、AV64などのサイズが示されており、AVSの各サイズではBroadcomのポータブルVMware VCFサブスクリプションが必要とされています。価格ページ上のAVS料金はAzureインフラとAVSマネージドサービスを含みますが、Broadcomから必要となるVCFポータブルサブスクリプションは含まれないと説明されています。(Microsoft Azure)
AV64を選ぶ場合はEVCとクラスター設計に注意する
AV64は移行先候補になり得ますが、「AV36より新しいからそのまま簡単に移せる」と考えるのは危険です。
Microsoft Learnでは、AV64を既存のAV36、AV36P、AV52などで構築されたAVSプライベートクラウドの拡張に利用できる一方、AV64を追加すると異種環境になり、Enhanced vMotion Compatibility（EVC）の差によってvMotionに影響が出る場合があると説明されています。AV64からベースSKU側へ戻すvMotionでは、VMの作成・電源状態によってEVC互換性エラーが発生する可能性があり、回避策としてVMレベルのEVC設定やコールドvMotionが挙げられています。(Microsoft Learn)
また、AV64はストレッチクラスターのAVSプライベートクラウドではサポートされないと説明されています。ストレッチクラスター構成を利用している場合は、単純なノード差し替えではなく、DR設計や可用性設計の見直しが必要です。(Microsoft Learn)
移行計画で失敗しやすいポイント
AV36サポート終了対応で失敗しやすいのは、移行作業そのものよりも、周辺設定や業務調整を軽く見積もることです。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| VM一覧だけで判断する | DNS、監視、バックアップ、ジョブが移行後に動かない | VM以外の依存関係を一覧化する |
| 移行先SKUの容量確認が遅い | 希望リージョンでクォータや在庫が確保できない | Microsoft Account Teamへ早めに相談する |
| ネットワーク設計を後回しにする | ExpressRoute、NSX、FW、DNS変更で本番移行が止まる | L3/L4通信、名前解決、ルートを先に検証する |
| RI期限を技術期限と混同する | 2027年9月30日後も使えると誤認する | 契約期限とサービス期限を別管理する |
| データ保持期間をバックアップと誤解する | 期限後に取り出せる前提で移行を遅らせる | 期限前にバックアップ、エクスポート、復旧試験を終える |
| 開発・検証環境を後回しにする | 本番移行後にCI/CDや検証環境が壊れる | 非本番も本番と同じ移行計画に含める |
| アプリ所有者が不明 | 移行可否判断が進まない | VM単位で業務オーナーを割り当てる |
特に、最大60日間のデータ保持は「救済措置」として読むべきです。通常運用の継続、性能保証、任意タイミングでの復旧を意味するものではありません。2027年9月30日までに、自社側で取得すべきバックアップ、エクスポート、検証済みの復旧手順を完了させることが安全です。(Microsoft Azure)
管理者と開発者が期限前にやるべきこと
AV36環境の移行は、インフラ管理者だけでは完結しません。アプリケーションチーム、セキュリティ担当、ネットワーク担当、財務・調達担当を巻き込んで進める必要があります。
インフラ管理者が確認すること
まず、AV36プライベートクラウドをすべて棚卸しし、移行先候補と期限を付けます。Microsoftの公式通知でも、現在のAV36 SDDCを確認し、Microsoft Account Teamと連携することが推奨されています。(Microsoft Azure)
確認すべき項目は次のとおりです。
| 分類 | 確認内容 |
|---|---|
| AVS本体 | SKU、ノード数、クラスター、リージョン、使用率 |
| ネットワーク | ExpressRoute、VPN、Global Reach、NSXセグメント、FWルール |
| ID・権限 | vCenter、NSX、Azure RBAC、Entra ID連携 |
| 運用 | バックアップ、監視、ログ、パッチ、メンテナンス手順 |
| 契約 | RI、Broadcom VCFサブスクリプション、移行先コスト |
| 可用性 | DR構成、RPO/RTO、ストレッチクラスターの有無 |
開発者・アプリ担当が確認すること
開発者側では、アプリケーションがVMware環境にどの程度依存しているかを確認します。単にVMを別基盤へ移しても、設定ファイルや接続先、監視エージェント、ライセンス認証が古い環境を向いたままだと障害になります。
| 確認項目 | 具体例 |
|---|---|
| 接続先設定 | DB接続文字列、APIエンドポイント、固定IP参照 |
| 名前解決 | 内部DNS、FQDN、hostsファイル、証明書SAN |
| 認証 | AD/LDAP、サービスアカウント、シークレット保管場所 |
| ジョブ | バッチ、スケジューラ、CI/CDエージェント |
| 監視 | APM、ログ転送、メトリクス収集、アラート通知 |
| ライセンス | MACアドレス、ホストID、ドングル、ライセンスサーバー依存 |
| 性能 | IOPS、レイテンシ、CPU世代差、メモリ使用率 |
アプリ側の判断基準は、「VMとして移せるか」ではなく、「移行後に同じ業務結果を安全に出せるか」です。移行テストでは、ログイン、主要画面、バッチ、外部連携、障害時復旧まで確認してください。
おすすめの対応スケジュール
2027年9月30日までは時間があるように見えますが、AVSの移行は容量確保、設計、検証、業務調整に時間がかかります。特に大規模VMware環境では、2027年に入ってからの着手では遅くなる可能性があります。
| 時期 | やること |
|---|---|
| 2026年中 | AV36環境の棚卸し、所有者確認、RI・VCF契約確認、移行先方針の決定 |
| 2026年後半〜2027年前半 | 移行先SKU・リージョン・クォータ確認、ネットワーク設計、PoC、費用見積もり |
| 2027年前半 | 非本番環境の移行、アプリ検証、バックアップ・復旧テスト |
| 2027年中盤 | 本番移行リハーサル、停止計画、運用手順の更新 |
| 2027年9月まで | 本番移行完了、AV36上の残存データ確認、不要リソース削除 |
| 2027年10月1日以降 | AV36 SDDCへアクセスできない前提で監査・後処理のみ実施 |
移行計画では、最後の1か月を「作業期間」ではなく「予備期間」として扱うのが現実的です。移行先の性能問題、名前解決の不備、バックアップ設定漏れ、監視アラートの誤検知などは、本番移行直前に見つかることが多いためです。
まとめ：AV36利用環境は「確認」ではなく「移行計画」まで進める
Azure VMware Solution AV36のサポート終了は、情報収集だけで終わらせてはいけない変更です。2027年9月30日でサポートが終了し、2027年10月1日以降は対象AV36 SDDCへアクセスできなくなるため、AV36を使っている組織は移行計画を具体化する必要があります。(Microsoft Azure)
まずは、Azure Portal、Azure CLI、Azure Resource GraphでAV36プライベートクラウドを棚卸ししてください。次に、RIやVCFサブスクリプション、移行先SKUの提供状況、ネットワーク構成、アプリ依存関係を確認します。そのうえで、AVS別SKUへ移るのか、Azure VMやPaaSへ移行するのか、あるいは廃止・統合するのかを決める流れが安全です。
期限前に取るべき次の行動は明確です。自社のAV36 SDDC一覧を作り、各環境に業務オーナーを割り当て、Microsoft Account Teamへ移行先候補と容量確保を相談してください。AV36のままVCF 9へ進める前提ではなく、2027年9月30日までにAV36から退避する前提で計画を立てることが、今回の変更への最も確実な対応です。
コメント