Azure VPN GatewayでBasic SKUパブリックIPがStandard SKUに移行できない原因と対処法【Standard/High Performance対応】

Azure VPN Gateway の Standard / High Performance SKU で Basic SKU のパブリック IP を使っていると、「Prepare」ボタンを押した瞬間に謎のエラーが出て移行できないケースがあります。本記事では、その原因を Azure の最新タイムラインと仕様から読み解きつつ、Standard SKU パブリック IP へ安全に移行するための実務的な方針と手順を整理します。

目次

Basic SKU パブリック IP を Standard SKU に移行できない典型パターン

まず、今回のような問い合わせで多い構成を整理します。

項目構成
VPN Gateway SKUStandard または High Performance(いずれもレガシー SKU)
Public IP SKUBasic SKU(廃止予定のパブリック IP)
GatewaySubnet/26(/27 以上が推奨なので要件はクリア)
操作Azure ポータルの仮想ネットワークゲートウェイ >[構成]>[移行]タブから「Prepare(移行準備)」を実行
結果バリデーションは成功するが、Prepare 実行でエラー

エラー メッセージの例は次のようなものです。

Failed to prepare for migration to standard IP based deployment.
Error: Migration type UpgradeDeploymentToStandardIP not allowed for the gateway

サブネットは /26 で余裕があるのに「not allowed」と言われるので、「自分の設計がどこかおかしいのでは?」と不安になりますが、実はこのエラーは構成ミスではなく、当該ゲートウェイ SKU に対してその移行パスがまだ有効化されていないことを示すメッセージです。

エラー「UpgradeDeploymentToStandardIP not allowed」の正体

Azure には仮想ネットワークゲートウェイ専用の移行 API があり、そのうち Basic SKU パブリック IP を Standard SKU に切り替えるためのモードが UpgradeDeploymentToStandardIP です。CLI や PowerShell からも同じ値を指定して Prepare を呼び出すようになっています。

このとき Azure 側は、次のような条件をチェックします。

  • 対象の VPN Gateway SKU が、いまサポートされている移行対象 SKU か
  • リージョンごとの機能ロールアウトが完了しているか
  • GatewaySubnet に十分な空き IP があるか(最低 3 IP 以上)

いずれかが満たされないと、「このゲートウェイに対して UpgradeDeploymentToStandardIP は使わせません」という意味で、今回のようなエラーが返ってきます。

特に 2025 年中は次のような制限が段階的に存在しました。

  • プレビュー初期:VpnGw1〜5(新 SKU・アクティブ/パッシブ構成)のみ Basic IP → Standard IP の移行がサポート
  • Basic VPN Gateway(ゲートウェイ SKU が Basic)は別タイムラインでサポート予定
  • Standard / High Performance(レガシー SKU)+ Basic IP は、最初は「バックエンドで自動移行する」方針で、手動移行は許可されていなかった

このため、Standard / High Performance SKU のゲートウェイで、プレビュー段階の「Basic IP 移行ウィザード」を実行すると、仕様上の制限として Migration type UpgradeDeploymentToStandardIP not allowed for the gateway が返されます。構成が悪いわけではなく、「まだその SKU 向けにはこの移行パスを開けていない」ことを示すエラーです。

2025 年 11 月時点の公式タイムラインを整理

このエラーを正しく解釈するには、Basic SKU パブリック IP とレガシー VPN Gateway SKU の廃止スケジュールを押さえておく必要があります。

Basic SKU パブリック IP のリタイアと猶予期間

パブリック IP 全体としては、Basic SKU は 2025 年 9 月 30 日付でリタイア扱いになりました。一方で、VPN Gateway など一部ワークロードでは、移行ツールの提供とあわせて猶予期間が延長されています。

Azure VPN Gateway の「What’s new」では、VPN Gateway 上の Basic SKU パブリック IP について、次のように案内されています。

イベント内容(2025 年 11 月時点)
Basic SKU パブリック IP 移行ツール GA2025 年 11 月末に Basic → Standard への移行ツールが一般提供(VpnGw1〜5 のアクティブ/パッシブおよびアクティブ/アクティブ、レガシー SKU を含む)
お客様主導の移行期間2025 年 11 月末〜 2026 年 3 月末まで、ポータルや PowerShell から Basic IP → Standard IP への移行を実行可能
VPN Gateway 上の Basic IP 廃止2026 年 4 月以降、VPN Gateway 上での Basic SKU パブリック IP は正式に廃止(Basic IP 自体は 3 月末まで猶予)

Standard / High Performance(レガシー SKU)ゲートウェイの扱い

Standard / High Performance は「レガシー SKU」として段階的に廃止予定であり、2025 年 10 月時点の公式ドキュメントでは、次のような整理になっています。

  • これらレガシー SKU は 2026 年 3 月 31 日に廃止予定
  • Basic IP 移行の一環として、Standard → VpnGw1AZ、High Performance → VpnGw2AZ に自動的に置き換えられる
  • ポータルから Basic IP → Standard IP を移行すると、そのタイミングでゲートウェイ SKU も AZ SKU へ自動アップグレードされる
  • ポータルによる Basic IP 移行体験は 2025 年 11 月中旬からレガシー SKU にも提供開始
  • 期限までに移行しなかった残りのレガシー SKU は、バックエンドから自動的に AZ SKU に移行される

つまり、Standard / High Performance SKU の VPN Gateway で Basic IP を使っている場合、最終的には「Basic IP → Standard IP への移行」を実行することで、IP もゲートウェイ SKU も新しい世代にまとめて置き換える、というのが現在の前提になっています。

なぜ今はポータルの「Prepare」が失敗するのか

プレビュー期は対象 SKU が限定されていた

2025 年前半〜中盤にかけて、Basic IP → Standard IP の移行はプレビューとして段階的に公開されていました。このフェーズでは、以下のような制限がありました。

  • 対象:VpnGw1〜5(アクティブ/パッシブ)のみ
  • Basic VPN Gateway(ゲートウェイ SKU が Basic)は対象外
  • Standard / High Performance(レガシー SKU)は「自動移行予定」とされ、ポータルからの Basic IP 移行はサポート外

この状態で Standard / High Performance のゲートウェイに対して「Prepare」を実行すると、バックエンド側で「この SKU はまだ UpgradeDeploymentToStandardIP を許可していない」と判定され、今回のエラーが返ってきます。

GatewaySubnet のサイズは今回のエラー原因ではない

Basic IP 移行ツールには、「GatewaySubnet が /28 以下だとエラーになる」「現在のプレフィックス内に最低 3 つの未使用 IP が必要」といった前提条件があります。

しかし、質問のケースでは GatewaySubnet は /26 であり、この条件は十分満たしています。したがって、今回のエラーはネットワーク設計が原因ではなく、単純に「その時点では Standard / High Performance SKU に対して Basic IP 移行が有効化されていなかった」ことが理由と考えるのが妥当です。

最新仕様では「お客様主導の Basic IP 移行」に一本化された

当初は「Standard / High Performance のゲートウェイはバックエンドで自動移行する」という案内もありましたが、2025 年 10 月に公開されたレガシー SKU の記事では、Basic IP の移行をポータルからお客様が実行する形に変更されたことが明記されています。

そのため、今後は Standard / High Performance でも、基本的には次の流れになります。

  1. ポータルの[移行]タブから「Basic IP → Standard IP への移行」をお客様が実行
  2. その処理の中で、ゲートウェイ SKU も Standard → VpnGw1AZ / High Performance → VpnGw2AZ へ自動アップグレード
  3. 移行の際は最大 10 分程度のダウンタイムが発生する見込み

つまり、プレビュー時代に Standard / High Performance でエラーになった「Prepare」は、そもそも想定外の使い方だったと言えます。現在はこの SKU 群向けにも正式な移行パスが提供されつつあるため、今から設計するのであれば最新のポータル体験を前提に考えるのが安全です。

実務での推奨移行戦略(Standard / High Performance + Basic IP)

基本方針:焦って手動移行しない

まず押さえておきたいのは、次の 2 点です。

  • Standard / High Performance + Basic IP の組み合わせは、現時点でもサポートされており、即座に停止するわけではない
  • Basic IP の退役は 2026 年 3 月末まで猶予期間が設けられており、その間にポータルからの移行体験が提供される

したがって、「エラーが出たから今すぐ VPN Gateway を削除して作り直す」といった乱暴な対応は避けるべきです。特に、以下のような影響が大きくなります。

  • ゲートウェイを作り直すとパブリック IP アドレスが変わるため、オンプレミス側の VPN 装置設定を全面的に更新する必要がある
  • 複数拠点のサイト間 VPN、VNet 間 VPN を組んでいる場合、すべての対向側設定に影響が及ぶ
  • ダウンタイムが長くなるだけでなく、ロールバックも複雑になる

多くのケースでは、ポータルから提供される Basic IP 移行機能を待ち、計画的なメンテナンスウィンドウで実行するのが最もリスクが小さい選択肢になります。

2025 年 11 月以降の標準的な移行ステップ

最新のドキュメントに基づく、Standard / High Performance + Basic IP 環境での標準的な移行フローをまとめると次の通りです。

フェーズ主な作業ポイント
事前準備GatewaySubnet のサイズと空き IP を確認(/27 以上推奨) 接続数やトラフィック量を把握し、メンテナンス時間帯を決定 オンプレミス装置側の運用担当にも周知特に /28 以下の場合はサブネット拡張が必要になる可能性がある
Prepareポータルの仮想ネットワークゲートウェイ >[構成]>[移行]タブから「Prepare」を実行 バックエンドで Standard IP や新しいゲートウェイ リソースの準備が行われるこの段階ではトラフィックへの影響は発生しない想定
Migrate「Migrate」を実行し、Basic IP → Standard IP への切り替えとゲートウェイ SKU の AZ SKU への移行を同時に実施最大 10 分程度のダウンタイムが発生する見込み
ValidateVPN トンネルの再接続を確認(オンプレミス装置側のログも確認) 必要に応じて疎通テスト用 VM からインターネット / オンプレミスへの通信を確認 Monitoring / Log Analytics のアラート状況を確認問題がなければ旧 Basic IP リソースは自動でクリーンアップされる

どこまで「待つ」ことが許されるか

スケジュール感としては、次のように捉えると設計しやすくなります。

  • 〜2025 年 11 月末:レガシー SKU 向けポータル移行体験が順次展開されるフェーズ
  • 2025 年 11 月末〜2026 年 3 月末:お客様主導で Basic IP → Standard IP を移行する推奨期間
  • 2026 年 4 月以降:VPN Gateway 上の Basic IP はサポート対象外となり、残っている環境はバックエンドで自動移行される可能性が高い

自社の業務カレンダーに合わせて、2026 年 3 月末までのどこかのメンテナンスウィンドウで計画的に移行するのが現実的な落としどころです。自動移行に任せることも不可能ではありませんが、

  • いつどの時間帯に切り替わるかを自分でコントロールできない
  • 本番障害と見分けがつきにくい時間帯に切り替えが行われる可能性がある

といった理由から、運用上はポータルからの計画移行を「必須タスク」として扱う方が安心です。

どうしても今すぐ Basic IP をやめたい場合の代替案

コンプライアンスやセキュリティ要件などで、「プレビューを待たずに今すぐ Standard IP に変えたい」というケースもあるかもしれません。この場合の現実的な選択肢は次の通りです。

  1. 既存の VPN Gateway をそのまま残しつつ、新しく VpnGw1/VpnGw2(または VpnGw1AZ/VpnGw2AZ)+ Standard IP のゲートウェイを別の VNet やサブネットに並行構築する
  2. オンプレミス側に新しいゲートウェイ IP の接続先を追加し、疎通確認
  3. 切り替え完了後に旧ゲートウェイを削除

この方法だと、

  • パブリック IP アドレスは変わってしまう(新しい IP を各所に展開する必要あり)
  • WAN 回線や VPN 装置の設定を二重管理する期間が発生

といった負荷がありますが、「既存のゲートウェイに手を入れたくない」「プレビュー機能を避けたい」といったポリシーを持つ環境では選択肢となります。

Basic SKU パブリック IP を残さない方がよい理由

ここまで読むと、「猶予があるなら Basic のままでもいいのでは?」と思うかもしれません。しかし、長期的には Basic IP を残さない方が圧倒的にメリットが大きいです。代表的な違いを整理します。

観点Standard SKU パブリック IPBasic SKU パブリック IP
可用性ゾーンゾーン冗長・ゾーナル・非ゾーナルを選択可能。ゾーン冗長 IP なら単一 AZ 障害にも耐えられる。可用性ゾーン非対応。リージョン障害だけでなく、単一 DC 障害の影響も受けやすい。
セキュリティ モデル「Secure by default」。NSG で明示的に許可した通信のみを通す前提。インターネットからのインバウンドをデフォルト許可。NSG を張り忘れると攻撃面が広がりやすい。
将来の機能追加Standard を前提とした機能(Standard Load Balancer、NAT Gateway など)が多数。新機能の対象外になるケースが増加。Basic 自体もリタイア済み。
サポート ライフサイクル現行 SKU として継続サポート。サービスとしては 2025 年にリタイア。VPN Gateway では 2026 年春までの猶予後に完全終了予定。

特にセキュリティ面では、Standard IP は「外部公開を前提としない閉域構成」をとりやすく、NSG と組み合わせることでゼロトラストに近い設計がしやすくなります。一方、Basic IP は「開けっぱなし前提」になりがちなので、長期的な運用監査の観点でも早期の廃止を強く推奨できます。

実務に役立つチェックリスト

最後に、Standard / High Performance + Basic IP の VPN Gateway を運用している場合に、今からやっておくと後で楽になるチェックポイントをまとめます。

構成確認チェックリスト

  • ゲートウェイ SKU
    • Standard / High Performance であること(Basic や VpnGw1〜5 と混在していないか)
  • パブリック IP
    • SKU が Basic / Standard のどちらか
    • DNS 名やオンプレミス側のホワイトリストにこの IP が使われているか
  • GatewaySubnet
    • プレフィックスが /27 以上であること
    • 未使用 IP が 3 つ以上残っていること
  • VPN 接続
    • サイト間 VPN・VNet 間 VPN・ポイント対サイト VPN の接続先一覧を洗い出しておく
    • オンプレミス装置側の管理者連絡先を整理しておく

移行実施時の運用チェックリスト

  • メンテナンス開始前
    • 重要システムの運用担当に影響時間を共有
    • Azure Monitor / Log Analytics で VPN 関連アラートを一時的に抑制するかどうか検討
  • Prepare 実行後
    • エラーが出ないことを確認(出る場合、GatewaySubnet の IP 空きや SKU を再確認)
  • Migrate 実行中
    • オンプレミス装置側でトンネル切断アラートが出ることを事前に伝えておく
    • ダウンタイムが想定以上に長い場合に備え、ロールバック方針を明文化しておく
  • Validate フェーズ
    • 主要拠点からの ping / RDP / HTTPS などで疎通確認
    • Standard IP への切り替え後、NSG で意図したポートだけが開いていることを確認
    • 監視アラートが平常状態に戻ることを確認

まとめ:エラーは「まだその移行パスは使えない」という仕様メッセージ

今回のポイントを改めて整理すると、次のようになります。

  • Migration type UpgradeDeploymentToStandardIP not allowed for the gateway は、サブネット設計ミスではなく、「そのゲートウェイ SKU / 時点では Basic IP → Standard IP 移行パスが有効化されていない」ことを示す仕様上のエラーである。
  • Standard / High Performance + Basic IP の組み合わせは、2026 年春まで猶予があり、その間にポータルからの Basic IP 移行体験が提供される。
  • ポータルの Basic IP 移行を実行すると、パブリック IP は Basic → Standard に変わり、同時にゲートウェイ SKU も VpnGw1AZ / VpnGw2AZ にアップグレードされる(IP アドレス自体は維持される想定)。
  • 無理にゲートウェイを削除・再作成すると IP アドレスが変わり、オンプレミス側を含む広範囲な再設定が必要になるため、原則として推奨されない。
  • Basic SKU パブリック IP は可用性・セキュリティ・将来性の面で不利なため、猶予期間のうちに Standard IP へ移行し、運用設計も「Secure by default」を前提とする構成に寄せていくのがベストプラクティスである。

つまり、「今出ているエラーを無理に解消しようとする」のではなく、Microsoft の最新タイムラインとポータルの機能提供状況を前提に、計画的に Basic IP 移行とゲートウェイ SKU の更新を進めるのが、本質的な解決策と言えます。

この記事を書いた人

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

コメント

コメントする

目次