Azure VPN Gateway（Standard〈レガシー〉）に Basic / Dynamic のパブリック IP をぶら下げている環境は、Basic SKU 廃止への対応と「IP アドレスを絶対に変えない」要件の両立が悩みどころです。本記事では 2025〜2026 年の最新方針を整理し、実運用で安全に IP を保持したまま Standard 化するための判断軸・具体手順・検証観点・落とし穴を一気通貫でまとめます。
結論（先に要点）
現行が VPN Gateway：Standard（レガシー）、紐付くパブリック IP が Basic / Dynamic の構成でも、Azure ポータルの「Basic IP → Standard IP への移行」機能（＝移行ツール／ウィザード）を使えば、同一のグローバル IP アドレスを保持したまま Standard（Static） に変換できます。変換の過程でゲートウェイは VpnGw1AZ（または VpnGw2AZ） に自動移行され、短時間（目安：最大で数分〜十数分）の影響が発生する場合があります。
スケジュール面では、Basic SKU 公開 IP の扱いとレガシー Standard/HighPerformance ゲートウェイの取り扱いが段階的に見直され、2026 年初頭〜3 月末を目処に顧客主導のポータル移行が基本になっています。未実施の場合は最終段で 自動移行が実施される想定ですが、業務影響の最小化と検証のため、計画的にポータルから移行することを強く推奨します。
前提と用語整理
- VPN Gateway SKU（レガシー）：Standard / High Performance。過去の SKU 体系。
- 新世代 SKU：VpnGw1/2/…（AZ を含む）。将来は AZ（可用性ゾーン）対応が主流。
- Public IP SKU：Basic（Dynamic/Static） と Standard（Static のみ）。
※Standard は static 固定が前提。Basic は Dynamic/Static の両方が存在。
最新方針の読み解き
- Basic SKU のパブリック IPは段階的に廃止が進み、Standard 化が前提になりました。
- レガシー Standard / High Performance ゲートウェイは、Basic IP → Standard IP への移行に合わせて VpnGw1AZ / VpnGw2AZ に自動移行される設計です。
- 顧客主導の移行ツール（ポータル）が提供され、短時間の停止（最大数分〜十数分）を見込むかわりに、IP アドレスは保持されます。
- 最終期日まで未対応の場合は Azure 側で自動移行が実施される見込みですが、事前検証なしで本番を迎えるリスクがあるため推奨しません。
「IP を変えない」を実現できる理由
移行ツールは、VPN Gateway に紐付く Basic の Public IP リソースを Standard（Static） に置換します。この置換は Azure の内部制御で行われ、実際の IP アドレスの数値は不変のまま、Dynamic → Static のフラグ切り替えや SKU の調整が完了します。したがって、オンプレミス側の VPN 装置やクライアント設定（接続先 IP）は変更不要です。
想定読者の現状に対するベストアンサー
現状：VPN Gateway は Standard（レガシー）、紐付くパブリック IP は Basic / Dynamic。
- 今すぐの強制作業は不要ですが、移行計画は前倒しで作成してください（検証・周知・保守要員アサインのため）。
- ポータルの「Basic IP → Standard IP への移行」を使えばIP は保持され、Dynamic → Static への切り替えは内部処理で完了します。
- 実施時は短時間の影響（最大数分〜十数分）を見込み、業務の谷間で切り替えましょう。
- 移行後、ゲートウェイが VpnGw1AZ / VpnGw2AZ に変わっていることと、Public IP が Standard（Static）になったことを確認します。
スケジュールと意思決定の指針
| 項目 | 推奨アクション | 補足 |
|---|---|---|
| 準備（即日〜） | 資産洗い出し・依存関係の棚卸・検証環境の確保 | ゲートウェイタイプ（Route/Policy）・接続数・BGP の有無・冗長化方式（Active-Active/Passive）を整理 |
| 移行ツール提供期間 | ポータルから顧客主導で移行 | 最大数分〜十数分の影響を想定。計画停止または冗長設計で吸収 |
| 最終期限 | 期限までに未対応ならAzure 側で自動移行 | 事前検証なしの切替はリスク。原則、計画移行を推奨 |
移行前の準備チェック
- ゲートウェイ サブネットのサイズ：/27 以上を推奨。小さすぎると移行が失敗する原因になります。
- 冗長化方式：Active-Active の場合、ツール対応状況はすでに改善されていますが、同時切替による瞬断を見込んだ上で作業計画を組みます。
- 監視・アラート：Network Watcher、Connection Monitor、Log Analytics（GatewayDiagnostics）で事前・事後の安定性を観測。
- 運用フロー：ヘルプデスク／NOC／ベンダ連絡手順、ロールバック想定、周知テンプレートを準備。
ポータルでの実行手順（概要）
- Virtual network gateway（対象ゲートウェイ）を開く。
- Overview/設定に表示される「Basic IP → Standard IP への移行」（または同義の案内）を開始。
- 「既存の IP を保持して Standard に変換」の選択肢を確認し、ウィザードを進行。
- 進行中は接続に短時間の影響が出る可能性があるため、監視しつつ待機。
- 完了後、SKU が VpnGw1AZ（または VpnGw2AZ）になり、Public IP が Standard / Staticになっていることを確認。
注：ゲートウェイの「SKU 変更」メニューから レガシー → 新世代 SKU へ直接アップグレードする操作は、基本的に 未対応です（従来は削除＆再作成が必要で IP が変わるため、今回の要件と矛盾）。必ず Basic → Standard IP の移行ツールを使ってください。
前後確認に使える CLI / PowerShell（例）
SKU と Public IP の事前確認（Azure CLI）
# VPN Gateway の SKU と世代を確認
az network vnet-gateway show \
--name <GatewayName> \
--resource-group <RG> \
--query "{sku:sku.name, generation:sku.tier, enableActiveActive:enableActiveActive}"
# 紐付く Public IP の SKU / 割り当て方式（Dynamic/Static）を確認
az network public-ip show
--name
--resource-group
--query "{sku:sku.name, allocationMethod:publicIPAllocationMethod, ip:ipAddress}" 移行後の検証ポイント（Azure CLI）
# VPN Gateway の SKU が VpnGw1AZ/VpnGw2AZ 系に変わったか
az network vnet-gateway show \
--name <GatewayName> --resource-group <RG> \
--query "{sku:sku.name}"
# 紐付く Public IP が Standard / Static かつ IP 数値が変わっていないか
az network public-ip show
--name --resource-group
--query "{sku:sku.name, allocationMethod:publicIPAllocationMethod, ip:ipAddress}" 影響時間（ダウンタイム）と抑制策
- 想定影響：顧客主導の移行では、最大で数分〜十数分の切替影響が発生し得ます。
- 抑制策：
- Active-Active の場合でも、切替フェーズでは両トンネルに断が及ぶ可能性を前提に保守時間帯で実施。
- BGP を使っているなら hold timer / keepalive の調整と、オンプレ側の再収束時間の見積りを事前に確認。
- 重要トラフィックは移行時間帯を避けるよう関係部門へ周知。
移行後に何が変わるか（Before / After）
| 項目 | Before | After | 備考 |
|---|---|---|---|
| VPN Gateway SKU | Standard（レガシー） | VpnGw1AZ（または VpnGw2AZ） | 世代アップにより可用性・性能が向上 |
| Public IP SKU | Basic（Dynamic） | Standard（Static） | IP 数値は同一だが割当方式は Static に |
| 可用性ゾーン | 非 AZ（多くは Regional） | AZ 対応（リージョン事情により挙動は最適化） | 将来のゾーン冗長性の恩恵を受けやすい |
| 運用 | Basic IP リソースに依存 | Gateway 側の IP 属性に集約 | スクリプトや監視参照先の更新が必要な場合あり |
運用チェックリスト（実作業の流れ）
| フェーズ | チェックポイント | 期待結果 |
|---|---|---|
| 事前 | Gateway Subnet が /27 以上か | 要件を満たし、移行エラーの芽を摘む |
| 事前 | 対象 Gateway が Standard（レガシー）で、Public IP が Basic/Dynamic であることを確認 | 対象特定の誤りを防止 |
| 事前 | 周知・保守計画・責任者明確化・ロールバック方針 | 影響最小化と迅速な対応が可能 |
| 実施 | ポータルの「Basic → Standard 変換」で既存 IP を保持オプションを選択 | IP 数値が変わらない |
| 実施 | 進行中の監視と接続性チェック（S2S / P2S） | 想定内の影響で収束する |
| 事後 | SKU が VpnGw1AZ/VpnGw2AZ、Public IP が Standard/Static であること | 変換成功の確証 |
| 事後 | スクリプト・IaC・監視の参照箇所（Basic IP リソース ID）を見直し | IP 属性の参照に寄せて整合性を確保 |
よくある質問（FAQ）
Q. Dynamic から Static に切り替わると、IP 数値は変わりますか？
A. いいえ。移行ツールは 数値としての IP は維持したまま、内部的に割当方式を Dynamic → Static へ切り替えます。
Q. P2S クライアントの再配布は必要？
A. 接続先 IP が同一のため、基本的に再配布は不要です（クライアント構成のダウンロードし直しは不要）。ただし VPN クライアント バージョンや認証方式の制約がある組織は事前検証を推奨します。
Q. ExpressRoute との共存に影響は？
A. ゲートウェイの SKU が世代アップするのみで、ER 共存の原理は同じです。切替の瞬断に備え、クリティカルな経路の代替やメンテ時間の周知を行ってください。
Q. 監視・セキュリティは変えた方がいい？
A. Standard IP は設計上「セキュア・バイ・デフォルト」モデルを採るサービスが多いですが、VPN Gateway の通信確立には Azure 管理面が関与するため、NSG の特別な追加開放は通常不要です。とはいえネットワーク監視（Log Analytics / Connection Monitor）とアラートのしきい値は移行後に再校正しましょう。
Q. レガシー SKU → 新 SKU への「SKU 変更」ボタンではダメ？
A. ダメです。レガシー → 新世代への直接アップグレードは原則不可で、従来は「削除＆再作成（＝IP 変更）」が必要でした。今回の要件（IP 不変）を満たすには、Basic → Standard IP 移行ツールを必ず利用してください。
落とし穴と回避策
- 誤解 1：「Azure が勝手に無停止で全部やってくれる」
→ 最新方針では 顧客主導ツールでの計画移行が前提です。自動移行に丸投げは、業務影響の可視化や周辺連携の検証ができずリスクが高い。 - 誤解 2：「Dynamic → Static に変えると IP が変わる」
→ 本移行では IP 数値を保持します。UI 上で割当方式が Static になるのは仕様です。 - 誤解 3：「Active-Active なら無停止」
→ 切替シーケンス上、瞬断が発生し得る前提で保守時間帯に実施ください。 - 誤解 4：「GatewaySubnet が小さくても大丈夫」
→ /27 以上を推奨。足りないと移行に失敗する要因になります。
サンプル周知テンプレート（社内向け）
件名：【通知】Azure VPN Gateway 公開IP Standard 化（IP 不変）
関係各位
下記メンテナンスで、VPN 接続に瞬断（最大数分〜十数分）が発生する可能性があります。
・対象：vnet-gw-prod（SKU：Standard → VpnGw1AZ へ更新）
・公開 IP：203.0.113.10（数値不変、Basic → Standard/Static に変換）
・日時：YYYY/MM/DD hh:mm - hh:mm（JST）
・影響：S2S/P2S ともに瞬断の可能性。切替後は自動復旧
・問い合わせ：ネットワーク担当 <[[email protected]](mailto:[email protected])>
以上、よろしくお願いいたします。 トラブルシューティング（代表例）
- 移行ボタンが見当たらない：ロールアウト状況や権限を確認。該当サブスクリプションのポリシー／RBAC で制限されていないか確認します。
- 移行に失敗する：GatewaySubnet のアドレス／サイズ、依存リソースのロック、リージョンの AZ サポート状況、リソース状態（Updating/Failed）をチェック。
- 切替後に一部トラフィックが戻らない：オンプレ装置のフェイルオーバー／BGP 再収束／SA ライフタイム再交渉を確認。必要ならトンネルの手動再確立。
実務に効く運用 Tips
- 観測の多層化：Gateway 側のメトリック（トンネル状態／パケットドロップ）に加え、アプリ視点の合成監視（HTTP/ICMP）を併用。
- IaC 反映：Bicep/Terraform の参照先を「Basic の Public IP リソース ID」から「Gateway の IP プロパティ」に寄せ直すと将来の変更に強くなります。
- 定常化：移行後 1〜2 週間はログを厚めに取り、異常傾向（再キーイング頻度/トンネル flap）を早期検知。
完全手順（詳細）
- 対象ゲートウェイ／Public IP を特定（タグ・命名規約・課金データからもクロスチェック）。
- GatewaySubnet を /27 以上に調整（必要なら事前に VNet 設計のアドレス再配分）。
- 保守計画の確定（業務の谷・周知・責任者・ロールバック）。
- ポータルで「Basic → Standard への移行」を開始。既存 IP を保持オプションを明示的に選択。
- 進行中は監視を継続。S2S/P2S の再収束を確認。
- 完了後、VpnGw1AZ / VpnGw2AZ 化と Standard / Static 化を確認。
- スクリプト・IaC・監視・台帳・設計書を更新。
- 事後レビュー（KPI：復旧時間、切替中パケット損失、問い合わせ件数）。
まとめ
- IP アドレスを保持したまま Basic → Standard に変換する方法は、Azure ポータルの移行ツールで実現可能。
- 変換の副作用として、VPN Gateway は VpnGw1AZ / VpnGw2AZ に自動移行され、将来性・可用性が向上。
- 短時間の影響（最大数分〜十数分）を見込みつつ、保守時間帯に計画実施するのが安全策。
- 期限切れ直前の自動移行に依存せず、検証と周知を終えたうえで前倒しで実行するのがベストプラクティス。
付録：設計判断早見表
| Gateway SKU | Public IP SKU | 推奨アクション | IP 変更 |
|---|---|---|---|
| Standard（レガシー） | Basic（Dynamic/Static） | 移行ツールで Basic → Standard 変換（内部で VpnGw1AZ/VpnGw2AZ 化） | なし |
| Standard（レガシー） | Standard（Static） | 必要に応じて SKU 調整（同系統内）。基本は現状維持で可 | なし |
| VpnGw1/2（非 AZ） | Standard（Static） | 将来的に AZ 版へ無停止で切替可能なケースあり | なし（同系統内） |
| Basic（ゲートウェイ） | Basic | 将来の方針に従い、専用の移行パス（IP は維持） | なし |
この記事の使い方
- 社内の稟議・周知のたたき台に。
- 現場作業の Runbook（前提チェック／実施／検証／事後）として。
- 監査・設計書のアップデート項目の棚卸に。
コメント