Azure VMware Solution を AV36 ノードで運用している管理者が最初に確認すべきことは、「自社の AVS Private Cloud が AV36 を使っているか」「Azure Service Health や Azure Advisor に影響対象として表示されているか」「移行先ノードとクォータを確保できるか」の3点です。
今回の Azure VMware Solution AV36 Node Retirement は、すぐに全ワークロードが停止するという話ではありません。ですが、AV36 を前提にしたキャパシティ計画、Reserved Instance、vCenter/HCX 移行、監査ログ、社内周知を放置すると、期限直前に移行先ノードが確保できない、ネットワーク延伸が間に合わない、業務停止の承認が取れないといった実務上のリスクが出ます。
なお、Azure Updates の対象情報は更新される可能性があります。Azure Updates の ID 503883 では AV36 Node Retirement に関する表示が確認でき、一覧上では「September 30, 2027」表記や、当初の 2028 年 6 月 30 日からの変更に関する説明が見える場合があります。一方で「September 30, 2028」として参照される一覧もあります。管理者は記事や二次情報だけで期限を固定せず、必ず Azure Updates、Azure Service Health、Azure Advisor の自テナント通知で最終確認してください。(Microsoft Azure)
Azure VMware Solution AV36 Node Retirement の要点
Azure VMware Solution AV36 Node Retirement は、AVS で使われる AV36 ノードを対象にした Retirement、つまり廃止・提供終了系の通知です。管理者の視点では、「使っているかどうか」だけでなく、「どの業務システムが載っているか」「どの契約や予約に紐づいているか」「どの移行方式で移せるか」を確認する必要があります。
| 確認項目 | 管理者が見るべきポイント |
|---|---|
| 対象サービス | Azure VMware Solution |
| 対象ノード | AV36 ノードを使用する AVS Private Cloud / クラスター |
| 分類 | Retirement |
| 主な確認元 | Azure Updates、Azure Service Health、Azure Advisor、Service Retirement Workbook |
| 影響の中心 | サポート期限、移行計画、クォータ、予約、運用監査、社内周知 |
| すぐ行うこと | AV36 利用有無の棚卸し、公式期限の再確認、Microsoft アカウントチームまたはサポートへの相談 |
特に注意したいのは、AVS のノード移行は通常の仮想マシンサイズ変更のように単純ではない点です。Azure VMware Solution は vSphere、vSAN、NSX、HCX、ExpressRoute、バックアップ、監視、DR 設計が絡むため、アプリケーション担当者を巻き込んだ計画が必要です。
まず AV36 を使っている環境を棚卸しする
最初の作業は、Azure ポータル上の AVS リソースを見て「AV36 がどこに存在するか」を特定することです。サブスクリプションが複数ある組織では、担当者の記憶に頼らず、Azure Advisor や Service Health も併用してください。
Azure Advisor のサービス廃止・アップグレード推奨では、退役予定日、退役対象機能、影響を受けるリソースを確認できます。また Service Retirement Workbook では、サブスクリプション、リソースグループ、場所で絞り込み、影響の大きい廃止予定を確認・共有できます。(Microsoft Learn)
| 棚卸し項目 | 確認場所 | 判断基準 |
|---|---|---|
| AV36 ノードの有無 | Azure ポータルの Azure VMware Solution リソース、クラスター情報 | AV36 が含まれる場合は移行計画の対象 |
| 影響対象リソース | Azure Advisor、Service Retirement Workbook、Service Health | 公式通知に表示される対象を優先 |
| リージョンと可用性ゾーン | AVS リソースの場所、Microsoft Learn のホストタイプ対応表 | 移行先 SKU が同一リージョンで使えるか確認 |
| ワークロード一覧 | vCenter、CMDB、監視ツール、バックアップ台帳 | 業務重要度、停止可否、依存関係で分類 |
| Reserved Instance | Cost Management、予約管理、契約管理台帳 | 期限、更新可否、移行先コストを確認 |
| ネットワーク依存 | NSX、ExpressRoute、HCX、DNS、FW ルール | L2 延伸や通信経路変更の要否を確認 |
棚卸しでは、単に「AV36 がある」と記録するだけでは不十分です。業務システム名、所有部門、RTO/RPO、保守時間帯、バックアップ方式、移行テスト可否まで紐づけておくと、後続の判断が速くなります。
公式期限は Service Health と Advisor で再確認する
今回のような Retirement 情報では、公開ページ、検索結果、Advisor の廃止予定表、Service Health の通知で表示タイミングや日付表記がずれる場合があります。管理者は、記事タイトルに含まれる日付だけで社内計画を確定しないでください。
確認の優先順位は次のように考えると安全です。
| 優先度 | 確認元 | 目的 |
|---|---|---|
| 高 | Azure Service Health の Health advisories | 自社テナント・サブスクリプションに対する正式な影響通知を確認 |
| 高 | Azure Advisor のサービス廃止推奨 | 影響を受けるリソース単位で確認 |
| 中 | Azure Updates ID 503883 | 発表内容、分類、変更履歴の確認 |
| 中 | Microsoft Learn の AVS ドキュメント | 移行先 SKU、HCX、クラスター操作の制約確認 |
| 低 | ブログ、SNS、社内転送メール | 初動の参考。最終判断には使わない |
Service Health の Health Advisory では、対象サービスやリソースが表示される場合があります。Microsoft Learn では、Health Advisory の影響リソース情報をポータルやプログラムから確認できることが説明されています。(Microsoft Learn)
権限と責任分担を先に決める
AV36 の移行対応では、Azure 管理者だけで完結しません。vCenter 管理者、ネットワーク担当、セキュリティ担当、課金・契約担当、業務アプリ担当がそれぞれ必要になります。
| 役割 | 主な担当 |
|---|---|
| Azure 管理者 | AVS リソース、クォータ、Service Health、Advisor、Activity Log の確認 |
| vSphere / AVS 管理者 | vCenter、クラスター、データストア、仮想マシン移行の計画 |
| ネットワーク担当 | ExpressRoute、NSX、ファイアウォール、DNS、L2 延伸の確認 |
| セキュリティ担当 | 権限棚卸し、監査ログ、変更管理、アクセスレビュー |
| 契約・課金担当 | Reserved Instance、予算、移行先 SKU のコスト確認 |
| アプリ担当 | 停止許容時間、テスト観点、業務影響、リリース判定 |
HCX を使う場合、サイトペアリングや Service Mesh の構成が必要になります。Microsoft Learn では、HCX Cloud Manager へ接続する際に CloudAdmin ロールの資格情報を使う手順や、外部 ID ソースのサービスアカウント利用が推奨されることが説明されています。個人アカウントで恒久運用しないことが重要です。(Microsoft Learn)
監査ログと変更証跡を残す
Retirement 対応は、単なる技術移行ではなく、監査対象になりやすい変更です。特に金融、公共、医療、製造などでは、「なぜ移行したのか」「誰が承認したのか」「いつ検証したのか」を後から説明できる状態にしておく必要があります。
Azure 側では、Activity Log を Log Analytics、Event Hubs、Storage へエクスポートして長期保管できます。Microsoft Learn では、Activity Log の既定保持期間や、Log Analytics への送信による長期保持・クエリ活用が説明されています。(Microsoft Learn)
確認しておきたい監査項目は次の通りです。
| 監査項目 | 残すべき証跡 |
|---|---|
| 公式通知の確認 | Azure Updates、Service Health、Advisor の確認日とスクリーンショット |
| 影響範囲 | 対象 AVS Private Cloud、クラスター、VM、業務システム一覧 |
| 変更承認 | CAB、システムオーナー承認、業務停止承認 |
| 移行テスト | テスト結果、性能比較、ロールバック手順 |
| 権限管理 | 一時権限の付与・削除、CloudAdmin 利用者、サービスアカウント |
| 作業ログ | Azure Activity Log、vCenter タスク、HCX 移行履歴 |
| 完了判定 | 旧 AV36 依存がなくなったことの確認結果 |
Azure Activity Log を Log Analytics に送っている場合は、次のような観点で AVS 関連の操作を抽出できます。
AzureActivity
| where TimeGenerated > ago(180d)
| where ResourceProviderValue =~ "MICROSOFT.AVS"
| project TimeGenerated, SubscriptionId, ResourceGroup, Resource, OperationNameValue, ActivityStatusValue, Caller
| order by TimeGenerated descこのクエリはあくまで出発点です。実運用では、組織の命名規則、対象サブスクリプション、承認番号、変更チケット番号と紐づけてください。
移行先ノードと構成制約を確認する
AV36 からの移行では、AV36P、AV48、AV52、AV64 などの候補を検討することになります。ただし、どの SKU が使えるかはリージョン、可用性ゾーン、在庫、クォータ、既存構成によって変わります。
Microsoft Learn の AVS ドキュメントでは、リージョンと可用性ゾーンごとのホストタイプ対応表が提供されており、日本リージョンの対応状況も掲載されています。また、特定の可用性ゾーンへの配置を希望する場合は Microsoft に Service Request を開く必要があること、ホストタイプによっては利用可能性が制限されることも説明されています。(Microsoft Learn)
さらに、クラスター内での SKU 混在にも注意が必要です。Microsoft Learn では、AV36、AV36P、AV52 を同一クラスター内で混在させないこと、AV64 クラスターの追加には一定の条件があることが説明されています。(Microsoft Learn)
| 移行方針 | 向いているケース | 注意点 |
|---|---|---|
| 既存 AVS 内に新クラスターを追加 | 同一リージョン内で段階移行したい | SKU 混在制約、クォータ、管理ネットワークを確認 |
| 新しい AVS Private Cloud へ移行 | 構成を整理したい、リージョン変更も検討したい | HCX、ExpressRoute、IP 維持、DNS 切替の設計が必要 |
| Azure ネイティブへ移行 | VMware 依存を減らしたい | OS、ミドルウェア、運用監視、バックアップ方式の再設計が必要 |
| オンプレミスへ戻す・別基盤へ移す | 契約・規制・性能要件で AVS 継続が難しい | ネットワーク、データ移行、運用体制の再構築が必要 |
「新しい SKU のほうが高性能だから移せばよい」と単純に判断しないでください。vCPU、メモリ、vSAN 容量、ストレージポリシー、FTT、ネットワーク帯域、バックアップウィンドウ、ライセンス条件まで見て、移行後の実効キャパシティを確認する必要があります。
HCX を使う場合の移行方式を選ぶ
AVS のワークロード移行では、VMware HCX を使うケースが多くなります。Microsoft Learn では、HCX Enterprise Edition の移行方式として Cold Migration、HCX vMotion、Bulk Migration、Replication Assisted vMotion、OS Assisted Migration が挙げられています。方式によって停止時間とスケールが違うため、業務要件に合わせて選ぶ必要があります。(Microsoft Learn)
| HCX 移行方式 | 停止時間の目安 | 向いている用途 |
|---|---|---|
| Cold Migration | 長め | 停止可能な小規模 VM、検証環境 |
| HCX vMotion | ほぼなし | 小規模・重要 VM の個別移行 |
| Bulk Migration | 短め | 多数 VM の並列移行 |
| Replication Assisted vMotion | ほぼなし | 停止を抑えつつ複数 VM を移行したい場合 |
| OS Assisted Migration | 変換に伴う停止あり | VMware 以外の仮想化基盤からの移行など |
AVS 間の移行でも HCX は利用できます。Microsoft Learn では、AVS Private Cloud 間の移行で HCX を使い、必要に応じて IP アドレスを維持しながら移行できることが説明されています。(Microsoft Learn)
ただし、L2 延伸は便利な反面、長期間残すとネットワーク障害時の切り分けが難しくなります。移行期間だけ使う設計にし、最終的にはルーティング、DNS、ファイアウォールルールを整理する方針を決めておきましょう。
Reserved Instance とコストの確認を後回しにしない
AV36 の Retirement 対応で見落としやすいのが、Reserved Instance と予算です。移行先ノードの性能が上がっても、台数、予約期間、ライセンス、データ転送、バックアップ、監視の費用が変わる可能性があります。
確認すべき項目は次の通りです。
| コスト確認項目 | 見るべき内容 |
|---|---|
| AV36 RI の期限 | いつまで有効か、途中解約や更新の扱いはどうなるか |
| 移行先 SKU の価格 | 同じ台数で足りるか、性能差により台数を減らせるか |
| 追加クラスター期間 | 並行稼働期間の二重コスト |
| ネットワーク費用 | ExpressRoute、データ転送、追加接続 |
| バックアップ・監視 | 新環境分のライセンスやログ増加 |
| VMware / VCF 関連 | 契約条件、BYOL、既存契約との整合 |
ここで重要なのは、技術移行計画と課金計画を分けないことです。移行テストのために一時的に新旧クラスターを並行稼働させる場合、その期間のコストを事前に承認しておかないと、途中で計画が止まります。
社内周知では「AVS終了」と誤解させない
社内向けの説明では、「Azure VMware Solution が終わる」と伝えると誤解を招きます。正しくは、「AVS の AV36 ノードが Retirement 対象であり、対象環境は期限までに移行計画が必要」という説明にしてください。
周知文には、次の要素を入れると伝わりやすくなります。
| 周知項目 | 書く内容 |
|---|---|
| 何が起きるか | AV36 ノードの Retirement に伴い、対象 AVS 環境の移行計画が必要 |
| すぐ止まるのか | 直ちに停止する通知ではないが、期限前に対応が必要 |
| 影響範囲 | 対象システム、VM、部門、利用者 |
| 依頼事項 | アプリ影響確認、停止可能時間、テスト協力 |
| 今後の予定 | 棚卸し、設計、検証、本番移行、旧環境削除 |
| 問い合わせ先 | インフラ担当、アプリ担当、変更管理窓口 |
周知の例文は次のようにすると、過度に不安を煽らずに行動を促せます。
Azure VMware Solution の AV36 ノードが Microsoft の Retirement 通知対象となっています。
現時点で直ちに業務システムが停止するものではありませんが、対象 AVS 環境は期限までに移行計画を策定する必要があります。
各システム担当者は、対象 VM、業務影響、停止可能時間、移行テストの可否を確認してください。
公式期限と影響対象は Azure Service Health / Azure Advisor の通知をもとに確定します。管理者向けチェックリスト
AV36 Node Retirement 対応では、次の順番で確認すると抜け漏れを減らせます。
| チェック | 確認内容 |
|---|---|
| □ | Azure Updates ID 503883 の最新表示を確認した |
| □ | Azure Service Health の Health advisories を確認した |
| □ | Azure Advisor / Service Retirement Workbook で影響リソースを確認した |
| □ | AV36 を使う AVS Private Cloud、クラスター、VM を一覧化した |
| □ | 業務システム、オーナー、重要度、停止可能時間を紐づけた |
| □ | Reserved Instance、契約、予算、並行稼働コストを確認した |
| □ | 移行先 SKU の候補、リージョン、クォータ、可用性を確認した |
| □ | Microsoft アカウントチームまたはサポートに相談した |
| □ | HCX、vMotion、Bulk Migration など移行方式を選定した |
| □ | ExpressRoute、NSX、DNS、ファイアウォールの変更点を洗い出した |
| □ | バックアップ、DR、監視、ログ転送の移行後構成を確認した |
| □ | Azure Activity Log、vCenter タスク、HCX 履歴を保管する設計にした |
| □ | 本番移行前のリハーサルとロールバック手順を用意した |
| □ | 社内周知と変更承認のスケジュールを決めた |
| □ | 旧 AV36 環境の削除条件と完了判定を定義した |
よくある失敗と回避策
期限だけをカレンダーに入れて終わる
Retirement 対応で最も危険なのは、「期限はまだ先だから後でよい」と考えることです。AVS の移行では、移行先クォータ、ネットワーク設計、アプリテスト、承認会議が必要です。期限から逆算し、少なくとも検証環境での移行リハーサルを早めに実施してください。
移行先ノードがすぐ確保できると思い込む
AVS のホストタイプは、リージョンや可用性ゾーンによって提供状況が変わります。Microsoft Learn でも、ホストタイプによっては利用可能性が制限されること、特定ゾーン配置には Service Request が必要な場合があることが説明されています。(Microsoft Learn)
移行計画を作る前に、移行先 SKU のクォータと在庫見込みを確認してください。
同一クラスターで自由に SKU を混在できると思う
AVS では、SKU の扱いに制約があります。Microsoft Learn では、AV36、AV36P、AV52 を同一クラスター内で混在させないことが説明されています。移行先を「既存クラスターに追加すればよい」と決め打ちせず、新規クラスター追加、別 Private Cloud、Azure ネイティブ移行のどれが適切かを比較してください。(Microsoft Learn)
L2 延伸を恒久構成にしてしまう
HCX のネットワーク延伸は、停止時間を抑えるために有効です。しかし、移行後も延伸を残し続けると、通信経路が複雑になり、障害時の切り分けやセキュリティ監査が難しくなります。移行後に DNS、ルーティング、ファイアウォール、監視設定を整理する完了条件を決めておきましょう。
削除前の確認が甘い
AVS のクラスター削除は取り返しがつかない操作です。Microsoft Learn でも、クラスター削除は実行中のワークロードやコンポーネントを終了させ、データを復旧できない不可逆操作として注意されています。旧 AV36 クラスターを削除する前に、バックアップ、監視、ログ、DR、アプリ受入確認を完了させてください。(Microsoft Learn)
次に取るべき行動
Azure VMware Solution AV36 Node Retirement で最初にやるべきことは、移行作業ではなく「正確な対象と期限の確定」です。Azure Updates の記事名や一覧表示だけで判断せず、Azure Service Health、Azure Advisor、Service Retirement Workbook で自社環境への影響を確認してください。
そのうえで、AV36 を使う AVS Private Cloud を一覧化し、移行先 SKU、クォータ、HCX 移行方式、ネットワーク変更、Reserved Instance、監査ログ、社内承認を1つの計画にまとめます。特に本番システムを載せている場合は、移行テスト、性能確認、ロールバック手順、完了判定を早めに作っておくことが重要です。
AV36 Retirement は、単なるノード更改ではありません。AVS 環境の棚卸し、契約整理、運用標準化、監査強化を同時に進める機会として扱うと、期限対応だけでなく、将来のクラウド運用リスクも減らせます。
コメント