Azure の Basic SKU パブリック IP は廃止（retired）後の運用フェーズに入り、ExpressRoute や VPN Gateway に紐づく IP も「正しい手順で Standard SKU へ揃える」ことが重要になっています。この記事では、ゲートウェイ別の移行パターンと、未使用 IP の整理までを実務目線でまとめます。
結論：Basic SKU パブリック IP は「紐づき先」で移行手段が変わる
Basic SKU のパブリック IP をどう扱うかは、どのリソースに関連付いているかで手段が分かれます。まずは自分の環境がどのパターンに当てはまるかを判断し、該当する公式手順に寄せるのが最短です。
| 対象 | よくある状態 | 推奨アクション | ポイント |
|---|---|---|---|
| ExpressRoute 用 仮想ネットワーク ゲートウェイ | Gateway type: ExpressRoute / Public IP SKU: Basic | ExpressRoute Gateway Migration を実施 | Basic→Standard の IP 変更を「ゲートウェイ移行」に内包して実施。必要に応じて AZ SKU へも移行可能。 |
| VPN Gateway（VpnGw1-5 等） | Public IP SKU: Basic（※ゲートウェイ自体は Basic 以外） | VPN Gateway の Basic IP→Standard IP 移行（ポータルの Migrate 体験） | Microsoft 提供の移行体験を使えば IP アドレスを維持でき、AZ SKU へ移行される場合がある。 |
| VPN Gateway（Gateway SKU: Basic） | ゲートウェイも Public IP も Basic | 「What’s new」記載の自動化・最新タイムラインに沿って対応 | Basic VPN Gateway 構成が更新され、Basic public IP リソース参照の扱いが変わる可能性がある。 |
| 未使用（未アタッチ）の Basic SKU パブリック IP | どのリソースにも関連付けなし | 使うならアップグレード／使わないなら削除 | アップグレードは「静的」「未関連付け」が前提。Standard は secure by default を意識。 |
Basic SKU パブリック IP を放置すると何が起きるか
Microsoft Learn のガイダンスでは、Basic SKU public IP は 2025 年 9 月 30 日に retired とされ、利用中の場合は Standard SKU へ早期にアップグレードするよう案内されています。retired 後もしばらくは動作する可能性がありますが、サポート対象外・SLA 対象外となるリスクが明示されています。
また、Standard SKU のパブリック IP は「secure by default」のモデルで、フロントエンドとして使う場合は既定で閉じる挙動になるため、想定外の停止を避けるには NSG の考慮が必須です（特に VM や公開系サービスで顕著）。ゲートウェイ移行でも、周辺の運用（監視・許可リスト等）まで含めて設計し直す意識が重要です。
最初にやること：Basic SKU パブリック IP の棚卸し（インベントリ化）
移行手段の選択を誤らないために、まず「Basic の Public IP が何個あって、どこに紐づいているか」を一覧化します。特にゲートウェイ系は、単純な Public IP の SKU 変更では済まないケースがあるため、棚卸しが最重要です。
Azure ポータルでの簡易確認
- 「Public IP addresses」で SKU = Basic をフィルター
- 各 Public IP の「Associated to（関連付け先）」を確認
- 関連付け先が Virtual network gateway の場合は、ゲートウェイ種別（ExpressRoute / VPN）と SKU も確認
Azure Resource Graph での棚卸し（例）
運用で強いのは Resource Graph です。SKU と紐づき先（id）をベースに、移行計画表へ落とし込みやすくなります。
Resources
| where type =~ 'microsoft.network/publicipaddresses'
| extend skuName = tostring(sku.name)
| where skuName =~ 'Basic'
| project name, resourceGroup, location, skuName, ipAddress=tostring(properties.ipAddress),
associatedId=tostring(properties.ipConfiguration.id)
| order by resourceGroup asc, name ascポイントは、properties.ipConfiguration.id が空なら「未アタッチ」、値が入っていれば「何かに紐づき」です。Virtual network gateway 系へ辿れる場合は、そのゲートウェイの type/SKU へ展開して判断します。
ExpressRoute 用 仮想ネットワークゲートウェイ＋Basic SKU パブリック IP の移行
ExpressRoute 用の Virtual network gateway（Gateway type: ExpressRoute）に Basic SKU public IP が紐づいている場合、原則は Microsoft が提供する ExpressRoute Gateway Migration の仕組みに寄せて移行します。これにより、Basic→Standard の IP SKU 更改を含めて、ゲートウェイ移行を進められます。
ExpressRoute Gateway Migration でできること
- 現在のゲートウェイ SKU から 同等または上位 SKU へ移行（ダウングレード不可）
- Basic IP → Standard IP へ更新
- 必要に応じて Availability Zone 対応ゲートウェイ（AZ SKU） へ移行
- 同じ GatewaySubnet 内に「新ゲートウェイ」を並行展開し、段階的にトラフィックを切り替え
事前条件（ここで詰まりやすい）
- GatewaySubnet が /27 以上（/27, /26, /25… のように十分なサイズが必要）
- 移行プロセス中は、画面遷移や関連リソースの変更を避ける（移行失敗の原因になり得る）
- ヘルスが Succeeded の状態を維持し、関連リソースの更新を避ける
GatewaySubnet のサイズ不足は最頻出です。サイズが足りない場合、サブネットの作り直し（または複数プレフィックス追加など）を検討します。複数プレフィックスはプレビュー要素が含まれ、PowerShell/CLI 中心での操作が前提になる点も押さえておきます。
影響（ダウンタイムの目安）
公式には、移行中に数分程度の中断が発生する可能性が示されています。加えてポータル手順では、トラフィック移行ステップで最大数分のインタラプトが起きうる旨が明記されています。実環境では「ルーティング切替」「セッション再確立」「監視のノイズ」を前提に、メンテナンス枠を確保して行うのが安全です。
ポータルでの移行手順（要点）
詳細手順は公式ドキュメントに従う前提で、実務で迷うポイントだけ噛み砕くと以下です。
- Virtual network gateway を開く
- 設定メニューの Gateway SKU Migration（または同等の移行ブレード）を開く
- Validate で前提条件チェック（ここで落ちたら先にサブネット等を修正）
- Prepare（新ゲートウェイ・接続などの準備が作られる。時間がかかる）
- Migrate Traffic（実際のトラフィック切替。瞬断があり得る）
- Commit（旧ゲートウェイ／旧接続／旧 Public IP を削除して完了）
ExpressRoute Gateway Migration は「準備（Prepare）」で新リソースが作られ、切替（Migrate）後に「確定（Commit）」で旧リソースが片付く流れです。Commit を行わない場合、移行状態が継続するため、移行計画では「Commit までやる」ことを前提に段取りしてください。加えて、移行後は新ゲートウェイが別リソースとして存在するため、既存の監視や診断設定は新ゲートウェイ側へ付け直しが必要になります。
運用で効く注意点（ExpressRoute）
| 論点 | ありがちな落とし穴 | 対策 |
|---|---|---|
| 移行中の変更 | FastPath、route weight、接続プロパティを触って失敗 | 移行期間中は関連設定の変更を凍結。ゲートウェイ/接続の操作も極力しない。 |
| 同一回線に複数ゲートウェイ | 同一回線で並列に移行して失敗 | 同じ circuit にぶら下がるゲートウェイは 1 つずつ順番に移行。 |
| GatewaySubnet サイズ | /28 のままで Validate/Prepare で止まる | /27 以上へ拡張（必要なら複数プレフィックス等）。 |
| Commit 期限 | 移行したまま放置し、期限・運用上の不整合が発生 | 移行後は計画内で Commit まで完了。期限のある運用を前提にする。 |
VPN Gateway で使っている Basic SKU パブリック IP の扱い
VPN Gateway は「ゲートウェイ SKU が Basic かどうか」と「Public IP が Basic かどうか」で話が分岐します。さらに、Microsoft 側の移行ツール提供状況（リージョン展開や GA タイミング）にも影響を受けるため、最新の “What’s new in Azure VPN Gateway?” を基準に判断します。
最新タイムライン（2025/11/25 更新の “What’s new” ベース）
- VPN Gateway 全体：Basic IP の deprecation timeline が 2026 年 3 月末へ移動
- “Basic SKU public IP address migration”（Basic 以外の VPN SKU 向け）：ツールは Public Preview から始まっているが、GA は延期され、2026 年 1 月中旬ごろに追加情報が提示予定と記載
- Basic SKU Gateway（ゲートウェイ SKU が Basic）向け：Basic public IP を外す 自動化機能が 2026 年 2 月中旬に提供予定（IP は変わらず、接続影響なし）
- Basic SKU public IP の deprecated：2026 年 4 月と記載
上記のとおり、VPN Gateway 側は「期限が動く」前提で、公式の更新情報を追う運用が重要です。社内の移行計画書には、少なくとも “What’s new” の更新日と該当行を根拠として貼り付け、定期的に再確認できる形にしておくと炎上しにくくなります。
パターンA：VpnGw1-5（Active-Passive）で Basic Public IP を使っている場合
Microsoft Learn の手順では、VpnGw1-5 の Active-Passive（Active-Active は対象外）に対して、Basic SKU public IP を Standard SKU へ移行するポータル体験が案内されています。この移行では、IP アドレス自体は変えずに SKU を移行でき、同時に 非 AZ SKU → AZ SKU へ移行される場合があります（例：VpnGw2 → VpnGw2AZ）。
移行は「Prepare / Execute / Commit」の段階があり、Execute のタイミングで最大 10 分程度のダウンタイムが想定されています。全体としては環境によって最大 2 時間程度かかるケースもあるため、想定時間は短めに見積もらず、メンテ枠を確保して進めるのが安全です。
事前条件（VPN）
- GatewaySubnet の現在のプレフィックスに 少なくとも 3 つの未使用 IPが必要
- GatewaySubnet が /28 以下だとツールがエラーになる場合があるため、/27 以上への拡張を検討
- ポータルに Migrate タブが表示されない場合、機能がまだリージョンに展開されていない可能性がある（最新状況は “What’s new” を参照）
実務での進め方（VPN：ポータル移行）
- VPN Gateway（Virtual network gateway）を開く
- Migrate（または移行ブレード）で前提条件の確認
- Prepare：Standard 側の準備リソースを生成
- Migrate/Execute：SKU 移行を実行（ここが短時間の停止ポイント）
- Validate / Commit：移行結果の確認と旧 Basic public IP の削除
なお、Commit せずに放置すると「旧 Basic IP が pending 状態で残る」挙動が示されているため、移行ウィンドウの中で Commit まで完了する前提で運用計画を組んでください。
ExpressRoute と VPN が同じ VNet に共存している場合の順序
VPN 側の “About” ドキュメントでは、ExpressRoute と VPN が共存している場合、VPN 側の Basic IP → Standard IP を先に移行することを検討するよう推奨が書かれています。共存環境では「GatewaySubnet の余剰 IP」「移行作業の競合」がボトルネックになりやすいので、順序を決めて一つずつ進めるのが現実解です。
パターンB：VPN Gateway のゲートウェイ SKU が Basic（Basic SKU VPN Gateway）
ゲートウェイ自体が Basic SKU の場合は、手動で「Public IP リソースを Standard に付け替える」設計にしづらく、Microsoft の更新情報に従うのが安全です。“What’s new” では、Basic SKU Gateway については、Basic public IP を外す自動化機能が 2026 年 2 月中旬に提供予定で、IP は変わらず、接続影響もない旨が記載されています。
加えて、Basic public IP リソースを廃止する動きに合わせて、Basic VPN Gateway の構成が更新され、Basic public IP 参照がゲートウェイ側の属性として見えるようになる、といった記載もあります。運用スクリプトや ARM/Bicep、監視が「Public IP リソース ID」を参照している場合、将来的に動かなくなる可能性があるため、ゲートウェイの IP アドレス属性を参照するよう見直す準備を進めておくのが堅実です。
「VPN Gateway Basic SKU 自体が廃止されるのか？」については、別ドキュメントで Basic SKU は廃止されないと明記されています。一方で、Basic public IP が廃止パスにあるため、Basic SKU でも Standard public IP を使えるようにする取り組みが記載されています（時期はドキュメント更新日を必ず確認してください）。
どのリソースにも紐づいていない Basic SKU パブリック IP の扱い（未使用 IP）
未アタッチの Basic public IP は、移行作業の「取りこぼし」になりがちです。ですが、対応自体はシンプルで、基本は次の二択です。
今後も使う：Standard SKU へアップグレード
未アタッチ IP は、ポータル上のアップグレード導線（バナー）から Basic→Standard に更新できます。ただし、公式手順ではアップグレード要件が明確です。
- 静的（Static）割り当てであること（Standard は動的割り当て不可）
- どのリソースにも関連付いていないこと（アタッチ中はアップグレード不可）
- IP アドレスは維持される
- アップグレードは元に戻せない
- 多くの場合、アップグレード後も Availability Zone 情報は付かないため、ゾーン冗長が必要なら「新規に zone-redundant Standard IP を作る」判断も必要
また、Standard public IP は secure by default のため、フロントエンド用途では NSG を前提に設計します。未アタッチの段階では影響が出にくい一方、後から NIC 等に付けて公開する場合に「急に閉じて見える」事故が起きやすいので、アップグレード時点で注意書きを残しておくのがおすすめです。
CLI でのアップグレード例（未アタッチ前提）
az network public-ip update \
--resource-group <resource-group> \
--name <public-ip-name> \
--sku Standard今後使わない：削除して整理
未使用の Basic public IP は、コストと運用ノイズ（棚卸し対象）になります。利用予定がないなら削除が合理的です。削除前に、以下だけ最終確認してください。
- 本当に「Associated to」が空であること
- DNS 名（ラベル）を何らかのクライアントが参照していないこと
- NSG/Firewall の許可リストに「固定 IP として」登録していないこと
最後に：移行の実務チェックリスト（そのまま作業計画に転記できる形）
| フェーズ | チェック項目 | 狙い |
|---|---|---|
| 棚卸し | Basic Public IP の一覧、関連付け先、ゲートウェイ種別/SKU を確定 | 誤った移行手段（手動付け替え等）を防ぐ |
| 事前準備 | GatewaySubnet のサイズ（/27 以上）、未使用 IP（少なくとも 3 つ） | Validate/Prepare で詰まるのを防ぐ |
| メンテ計画 | ExpressRoute：数分の中断想定、VPN：Execute で最大 10 分想定 | 業務影響を現実的に見積もる |
| 移行中 | FastPath/route weight/接続設定などを変更しない、同一回線は順番に実施 | 移行エラーの予防 |
| 移行後 | 新ゲートウェイ側へ診断設定・監視・アラートの付け直し、運用手順書更新 | 「移行したのに監視が死んだ」事故を防ぐ |
| 期限管理 | VPN は “What’s new” の更新日と期限（End of Mar 2026 / Apr 2026）を追従 | 期限変更に振り回されない |
参考リンク（公式ドキュメント）
- About ExpressRoute Gateway Migration （URL:
https://learn.microsoft.com/en-us/azure/expressroute/gateway-migration） - ExpressRoute ゲートウェイ移行（ポータル手順） （URL:
https://learn.microsoft.com/en-us/azure/expressroute/expressroute-howto-gateway-migration-portal） - ExpressRoute ゲートウェイ移行：トラブルシューティングとベストプラクティス （URL:
https://learn.microsoft.com/en-us/azure/expressroute/gateway-migration-error-messaging） - What’s new in Azure VPN Gateway?（最新タイムライン） （URL:
https://learn.microsoft.com/en-us/azure/vpn-gateway/whats-new） - VPN Gateway：Basic Public IP 移行の考え方（About） （URL:
https://learn.microsoft.com/en-us/azure/vpn-gateway/basic-public-ip-migrate-about） - VPN Gateway：Basic Public IP → Standard Public IP 移行手順（How-to / Preview） （URL:
https://learn.microsoft.com/en-us/azure/vpn-gateway/basic-public-ip-migrate-howto） - Basic Public IP 廃止後のアップグレード ガイダンス （URL:
https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-basic-upgrade-guidance） - 未アタッチ Public IP の Basic → Standard アップグレード手順 （URL:
https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-upgrade） - サブネットに複数プレフィックスを追加（GatewaySubnet 拡張に使う場合あり） （URL:
https://learn.microsoft.com/en-us/azure/virtual-network/how-to-multiple-prefixes-subnet）
コメント