Azure VPN Gateway で Basic SKU の Public IP が廃止されるという通知を受けたものの、「Dynamic から Static に変えられない」「Standard SKU にどう移行すればよいのか分からない」と悩んでいる方は多いと思います。本記事では、なぜ Azure ポータル上で割り当て方法がグレーアウトしているのかという技術的な理由から、Basic SKU から Standard SKU＋Static IP に手動で移行する具体的な手順、そして Microsoft が案内している公式スケジュールを整理し、いつまでに何をしておけば安心なのかを分かりやすく解説します。
Azure VPN Gateway と Basic SKU Public IP 廃止の全体像
まずは前提となる状況を整理します。現在、Azure では Basic SKU の Public IP アドレスが段階的に廃止される計画となっており、その影響を大きく受ける代表的なワークロードのひとつが Azure VPN Gateway です。
多くの環境では、オンプレミス拠点と Azure を Site-to-Site VPN で接続するために VPN Gateway が使われており、そのフロント側で Basic SKU の Public IP が利用されています。通知メールなどで「2026 年 1 月末で Basic SKU Public IP が廃止」と書かれていると、すぐにでも対応しないと VPN が止まってしまうように感じるかもしれません。
しかし実際には、Microsoft は廃止までの猶予期間を設け、さらに「実際の IP アドレスを維持したまま Basic Public IP を置き換えるための自動ツール」の提供を予定しています。そのため、今すぐにすべてを作り直す必要はありませんが、仕組みとスケジュールを理解したうえで「いつまでに」「どこまで」やるのかを決めておくことが重要です。
通知内容のポイント整理
| 項目 | 内容 |
|---|---|
| 対象 | Azure の Basic SKU Public IP アドレス（VPN Gateway で利用されているものを含む） |
| 廃止タイミング | 2026 年 1 月末に廃止予定 |
| 自動移行 | 2025 年 10 月頃を目安に、Basic Public IP を自動で置き換えるツール提供予定 |
| IP アドレス | 自動移行では、同一のグローバル IP アドレスを維持したまま新しい SKU に置き換えられる予定 |
| 緊急度 | 2026 年 1 月末までは既存接続は継続。すぐに通信が止まるわけではない |
この前提を踏まえた上で、「なぜ Public IP の Dynamic → Static を Azure ポータルから変更できないのか」を見ていきます。
なぜ VPN Gateway の Public IP を Dynamic から Static に変更できないのか
Azure ポータルの Public IP リソース画面では、「IP アドレスの割り当て」で Dynamic／Static の選択肢が表示されます。しかし、VPN Gateway に紐づいている Basic SKU の Public IP の場合、「Static」がグレーアウトして選べない、という状況がよく発生します。
仕様上の制約：VPN Gateway 作成時に固定される
最大のポイントは、VPN Gateway が Public IP を「作成時の設定のまま固定してしまう」設計になっていることです。より正確には、次のような制約が組み合わせで効いています。
| 観点 | 内容 |
|---|---|
| Public IP の SKU | Basic と Standard では機能やサポートされるシナリオが異なり、特にネットワークゲートウェイとの組み合わせに制約がある |
| 割り当て方法 | Dynamic / Static は Public IP リソースのライフサイクルに深く結びついており、一部の関連リソースでは後から変更できない |
| VPN Gateway 側の仕様 | 接続情報やトンネル、ルーティング情報が Public IP と密接に紐づくため、後からの割り当て方式変更をサポートしていない |
その結果、「Public IP リソース単体としては Dynamic / Static を切り替える UI が見えるが、実際には VPN Gateway と組み合わさった時点で変更不可」という状態になります。ポータルでグレーアウトしているのは、この「後からは変えられない」という仕様を UI 上で表現しているだけであり、不具合ではありません。
『Dynamic を Static にしたいだけなのに』が難しい理由
運用者からすると、「今の IP アドレスをそのまま維持したいだけ」「これ以上変わらないようにしたいだけ」というシンプルな要望に見えます。しかし Azure の内部実装では、Dynamic／Static の違いは単なるフラグではなく、以下のような意味合いを持ちます。
- Dynamic：必要に応じて割り当て・解放される前提のアドレス（実際には VPN Gateway では頻繁には変わらないものの、設計上は変わりうる）
- Static：リソースのライフサイクル中はアドレスが変わらないことを前提とする予約済みアドレス
VPN Gateway は、接続先機器（オンプレミス側 VPN 装置）の設定や、他の Azure リソースとの間でルーティングを行うハブのような立場にあるため、「IP 設定の変更＝トンネルの張り直し」になり得ます。これを既存のゲートウェイに対してオンラインで行うと、途中でトンネルダウンが発生したり、予期しない経路切り替えが起きるリスクがあります。
そのため、Azure の設計としては「既存の VPN Gateway にぶら下がっている Public IP の割り当て方式を変更することは許可しない」という、安全寄りの仕様になっていると考えるのが自然です。
ポータル UI がグレーアウトしている理由のまとめ
| 現象 | 理由 |
|---|---|
| Dynamic → Static 切替の選択肢が表示される | Public IP リソースとしての一般的な編集 UI が表示されているため |
| しかし選択肢がグレーアウトしている | VPN Gateway に関連付いている状態では、割り当て方法を変更する操作が許可されていないため |
| 回避策 | 既存ゲートウェイを直接変更するのではなく、新しい Public IP＋新しい VPN Gateway を構築して乗り換える |
つまり、「今ある VPN Gateway の Public IP を Dynamic から Static に変える」ことは仕様上できないため、「別のゲートウェイに移す」というアプローチが必要になります。
Microsoft が案内している公式対応とスケジュール
続いて、Microsoft が案内している Basic SKU Public IP 廃止に関する公式方針とスケジュールを整理します。ここを押さえておくと、「どこまでを手動でやるべきか」「いつまでに終わらせればよいか」が明確になります。
公式の大まかなロードマップ
| 時期 | イベント | 運用者がやること |
|---|---|---|
| 〜2025 年 9 月頃 | Basic Public IP はそのまま利用可能 | 現状把握、移行方針の検討、影響範囲の洗い出し |
| 2025 年 10 月頃 | Basic Public IP を自動で置き換えるためのツール提供予定 | ツールの提供状況を確認し、テスト環境で動作検証を行う |
| 2025 年 10 月〜2026 年 1 月 | 順次、自動置き換え／手動移行のいずれかを実施 | 本番環境への適用、監視・運用の調整、ドキュメント更新 |
| 2026 年 1 月末 | Basic SKU Public IP 廃止 | この時点までに対象 Public IP をすべて置き換え済みにしておく |
通知内容の重要なポイントは、「自動置き換えツールは実 IP アドレスを維持したまま Basic Public IP を置き換える」という位置づけになっている点です。つまり、多くのケースでは「Public IP の SKU だけが変わり、IP アドレスそのものは変わらない」形で移行できます。
ただし、VPN Gateway の構成や周辺のネットワーク設計によっては、自動ツールの対象外となるパターンや、事前調整が必要なパターンが出てくる可能性があります。特に、以下のような場合は、早めに構成を洗い出しておくことをおすすめします。
- 複数の VPN Gateway や ExpressRoute が複雑に接続されているハブ＆スポーク構成
- オンプレミス側ファイアウォールやルーターで高度なフィルタリング／NAT を行っている
- 監視ツールや外部システムが Public IP リソース自体を参照している
いつまでに何をすればよいかの実務的な目安
| フェーズ | 目安となる時期 | やること |
|---|---|---|
| 現状把握 | できれば 2025 年前半までに | Basic SKU Public IP の洗い出し、関連する VPN Gateway や VNet を棚卸し |
| 方針決定 | 2025 年夏頃までに | 自動ツールを前提にするか、手動で Standard SKU＋Static IP に移行するかを決定 |
| 検証・リハーサル | 2025 年 10〜11 月 | 検証環境で移行シナリオを試し、手順書やロールバック手順を整備 |
| 本番移行 | 遅くとも 2025 年末までに | 業務への影響が最も小さいタイミングで本番環境を移行し、監視設定も更新 |
このように逆算していくと、「2026 年 1 月末ギリギリに駆け込みで作業する」のではなく、十分な余裕を持って計画・検証・本番移行を行うことができます。
Basic SKU から Standard SKU＋Static IP に手動で移行する手順
次に、「自動ツールを待つのではなく、こちらから先に Standard SKU＋Static IP へ移行したい」という場合の具体的な手順を解説します。ここでは、もっとも一般的な「既存 VPN Gateway を置き換える」パターンを前提とします。
全体イメージ
やりたいことをざっくり図式化すると次のようになります。
- 現状：Basic SKU Public IP ＋ Basic / 旧 VPN Gateway
- 移行後：Standard SKU Public IP（Static）＋新 VPN Gateway
- オンプレミス側 VPN 装置の接続先 IP を、新しいゲートウェイの IP に切り替える
つまり、「VPN Gateway を一度作り直し、そのフロントに新しい Static IP をぶら下げる」というイメージです。既存ゲートウェイを直接書き換えることはできないため、「新旧並行運用 → 切り替え → 旧環境の削除」という流れになります。
ステップ 1：現状構成の棚卸し
まずは、移行対象となる VPN Gateway の周辺情報を整理します。最低限、以下の項目は事前に洗い出しておきましょう。
| 項目 | 確認内容 |
|---|---|
| 対象 VPN Gateway | どの VNet に属し、どのサブネット（GatewaySubnet）に配置されているか |
| Public IP | Basic SKU で Dynamic 割り当てになっているか、他のリソースと共有していないか |
| Site-to-Site 接続 | 接続先オンプレミスの IP、共有キー、IKE/IPsec 設定、BGP 有無など |
| Point-to-Site 接続 | クライアントアドレスプール、認証方式（証明書／Azure AD など）、VPN クライアントの配布方法 |
| VNet 間接続 | 他の VNet との VNet-to-VNet 接続の有無 |
| 監視・運用 | ログ収集、アラート、死活監視ツールの設定 |
特に、オンプレミス側の機器設定（トンネル数、事前共有キー、暗号スイート）を正確に把握しておかないと、新ゲートウェイ側での再設定に時間がかかります。可能であれば、既存設定をそのまま再現できるようにメモしておくとスムーズです。
ステップ 2：Static 設定の Standard SKU Public IP を作成
次に、新しい Public IP リソースを作成します。ポイントは以下の通りです。
- SKU：Standard
- 割り当て方法：Static
- ゾーン：可用性要件に応じてゾーン冗長などを選択
- リージョン：既存 VPN Gateway と同じリージョンに作成
ポータルから作成してもよいですし、IaC を使っている場合は ARM/Bicep/terraform などで既存定義に追加しても構いません。
<!-- 例：Bicep での Public IP 定義例（イメージ） -->
resource vpnGwPublicIp 'Microsoft.Network/publicIPAddresses@2023-04-01' = {
name: 'vpn-gw-pip-standard'
location: resourceGroup().location
sku: {
name: 'Standard'
}
properties: {
publicIPAllocationMethod: 'Static'
}
}
ここで割り当てられた Static IP アドレスが、今後オンプレミス側 VPN 装置から接続してくる先頭 IP となります。
ステップ 3：新しい VPN Gateway を Standard SKU Public IP でデプロイ
次に、新しい VPN Gateway を作成します。注意点は次の通りです。
- 接続したい VNet と同じリージョン、同じ GatewaySubnet を利用する
- Gateway SKU は VpnGw1 以上（要件に応じて VpnGw2 など）を選択
- Public IP として、前ステップで作成した Standard SKU＋Static の Public IP を紐付ける
Azure では 1 つの VNet に作成できる VPN Gateway は 1 つだけという制約があり、既存のゲートウェイがある場合は同一 VNet に新ゲートウェイを増設することはできません。そのため、実際には次のいずれかのパターンを検討することになります。
| パターン | 概要 | 特徴 |
|---|---|---|
| A：同一 VNet で置き換え | 旧ゲートウェイを削除 → 新ゲートウェイを同じ VNet / GatewaySubnet に作成 | シンプルだが、切り替え作業中は VPN が停止するダウンタイムが発生 |
| B：一時的な別 VNet 経由 | 一時的に別 VNet＋ゲートウェイを用意し、ピボットとして利用してから本番側を作り直す | 構成が複雑になる代わりに、ダウンタイムを短縮しやすい |
中小規模環境や、夜間にメンテナンス時間を取れる環境であれば、パターン A（同一 VNet で置き換え）が現実的です。ここではパターン A を前提として話を進めます。
ステップ 4：旧ゲートウェイから新ゲートウェイへ接続設定を移行
新しい VPN Gateway が作成できたら、旧ゲートウェイに存在していた接続設定を新ゲートウェイ側にも再現していきます。主な作業項目は次の通りです。
- Site-to-Site 接続（接続先 IP、共有キー、BGP 設定など）
- Point-to-Site 設定（アドレスプール、ルート配布、証明書、クライアント構成ファイル）
- VNet-to-VNet 接続（他の VNet にある VPN Gateway との接続）
オンプレミス側の VPN 装置の設定を変更する前に、新ゲートウェイ側にすべての接続設定を作り込んでおき、「切り替えの瞬間にやるのはオンプレ側の接続先 IP の変更だけ」という状態にしておくと、ダウンタイムを最小限にできます。
Point-to-Site を利用している場合は、新ゲートウェイ側で再生成した VPN クライアントを配布し直す必要が出てきます。クライアント数が多い場合は、移行期間を設けて段階的に切り替えていく計画を立てるとよいでしょう。
ステップ 5：オンプレミス側の VPN 装置設定を切り替え
新ゲートウェイ側の準備が整ったら、メンテナンス時間を確保した上でオンプレミス側 VPN 装置の接続先 IP を切り替えます。
- 既存トンネルを graceful に切断（可能なら）
- 接続先 IP を旧ゲートウェイの IP から、新しい Standard SKU Public IP の IP へ変更
- 同じ事前共有キーや暗号方式を利用してトンネルを再接続
- 疎通確認（Ping、業務アプリケーション、監視など）
複数拠点がある場合は、一拠点ずつ順番に切り替えることで、「一部拠点だけ一時的に旧ゲートウェイ／新ゲートウェイが混在している」状態も作れます。業務影響を最小化するためには、テスト用拠点で事前に切り替えを試すことも重要です。
ステップ 6：旧 Basic SKU VPN Gateway を削除
すべての拠点・接続が新ゲートウェイへ切り替わり、十分な運用確認期間を経て問題がないことを確認できたら、旧 Basic SKU の VPN Gateway とそれに紐づく Basic Public IP を削除します。
- 削除前に、念のため旧ゲートウェイの構成エクスポートを取っておく
- 監視ツールや IaC 定義から、旧リソースに対する参照を削除
- コスト管理の観点からも、不要なゲートウェイや Public IP は残さない
これで、「Standard SKU＋Static IP を利用した新しい VPN Gateway への移行」が完了します。
自動ツールを待つか、手動移行するかの判断材料
ここまで読むと、「自動ツールを待てば実 IP アドレスを維持したまま Basic Public IP を置き換えてくれるなら、わざわざゲートウェイを作り直さなくても良さそう」と感じるかもしれません。一方で、手動移行を選ぶメリットもあります。
自動ツールを待つ場合のメリット・デメリット
| 項目 | メリット | デメリット |
|---|---|---|
| メリット | IP アドレスを変えずに置き換え可能なため、オンプレ側の設定変更がほぼ不要 | ― |
| 運用コスト | Azure 側の自動処理がメインで、作業工数を抑えられる | ツールの提供時期や仕様に依存する |
| リスク | 公式ガイドに沿って実施すれば、サポート観点で安心感がある | 特殊な構成（高度なネットワーク構成）では適用に注意が必要な場合がある |
| スケジュール | 2026 年 1 月末まで猶予があるため、計画的に進めやすい | ギリギリまで待ちすぎると、想定外の問題が起きたときの余裕がなくなる |
手動で早期移行する場合のメリット・デメリット
| 項目 | メリット | デメリット |
|---|---|---|
| メリット | 自社の都合に合わせて構成を整理しながら移行できる（ネットワーク設計の見直しの好機） | オンプレ側設定変更やダウンタイム調整が必要 |
| 標準化 | Standard SKU＋Static IP への早期統一で、将来の運用や拡張がシンプルになる | 環境によっては作業規模が大きくなる |
| 検証 | 自分たちの手でステップを検証するため、内部ノウハウが蓄積される | 手順設計やリハーサルに時間がかかる |
結論としては、以下のような方針が現実的です。
- 規模が小さい／中程度の環境：手動移行も視野に入れつつ、自動ツールの仕様が判明したタイミングで最終判断
- 大規模・ミッションクリティカルな環境：早めに検証環境で自動ツールと手動移行の両方を試し、「最悪自分たちで移行できる」状態を確保しておく
運用上の注意点：IP 参照方法や監視の見直し
最後に、Basic SKU Public IP 廃止に伴って見直しておきたい運用面のポイントを紹介します。特に、スクリプトや監視ツールで Public IP リソースを直接参照しているケースでは注意が必要です。
Public IP リソースではなくゲートウェイの IP 属性を参照する
スクリプトや IaC、監視ツールなどで「Basic Public IP リソースそのもの」を前提にしている場合、今後の変更で影響を受ける可能性があります。推奨されるのは、「VPN Gateway の構成情報から IP アドレスを取得する」設計にしておくことです。
| パターン | 望ましい参照先 | 理由 |
|---|---|---|
| 監視ツールでの疎通確認 | VPN Gateway が持つ Public IP アドレス | Public IP リソースが将来置き換えられても、ゲートウェイ側の IP は変わらない場合が多いため |
| IaC での依存関係 | VPN Gateway リソース → その Public IP の ID | Public IP の SKU や細かいプロパティは後から変更される可能性があるため |
| ログ・監査用の記録 | 実際に利用されるグローバル IP アドレス | SKU ではなく「どの IP から通信が来るか」が重要となるケースが多いため |
監視・アラート条件の見直し
Public IP の SKU やアドレス割り当て方式が変わると、監視・アラート設定に影響する場合があります。例えば：
- Public IP の状態（割り当て状況）を監視している場合：SKU 変更に伴うメトリックの変化に対応しているか
- VPN Gateway のトンネル状態を監視している場合：新ゲートウェイに移行した後も正しくメトリックが取得できているか
- ログ分析（Azure Monitor / Log Analytics 等）で IP をキーにしている場合：新旧 IP の切り替え期間をどう扱うか
移行作業の一部として、「監視・アラートのテスト」も必ず計画に含めておくと安全です。
ドキュメントと運用手順の更新
Basic SKU Public IP 廃止への対応は、一度きりのイベントではありますが、ネットワーク基盤に関わる大きな変更でもあります。作業が完了したら、次のような情報をドキュメントとして残しておきましょう。
- いつ、どの環境で、どのような手順で移行を行ったか
- 旧構成と新構成の違い（図解があるとベスト）
- オンプレミス側設定の変更内容と、関係部門との調整履歴
- 今後同様のイベントがあった場合に流用できるチェックリスト
これらを残しておくことで、次に似たようなライフサイクル・イベント（別サービスの SKU 廃止など）が起きたときにも、スムーズに対応できるようになります。
よくある疑問への Q&A
Q1. 今すぐに VPN Gateway を作り直さないと危険ですか？
A. 通知にある通り、2026 年 1 月末までは Basic SKU Public IP を使った接続は継続される想定であり、「明日にも VPN が止まる」といった緊急性はありません。ただし、スケジュールには余裕を持つべきなので、2025 年中には具体的な移行計画を立てておくことをおすすめします。
Q2. 自動置き換えツールを使えば、本当に IP アドレスは変わりませんか？
A. Microsoft からの案内では、「実際の IP アドレスを維持したまま Basic Public IP を置き換えるツール」が提供される予定とされています。ただし、例外的な構成やエッジケースが存在する可能性もゼロではないため、重要な環境では検証環境で一度試してから本番に適用するのが安全です。
Q3. Dynamic から Static に変えられないのはバグではないのですか？
A. 仕様です。VPN Gateway と組み合わさった Public IP の割り当て方式は、後からの変更をサポートしていません。既存ゲートウェイを直接編集するのではなく、新しい Standard SKU＋Static IP を割り当てたゲートウェイを構築して乗り換える、というアプローチが推奨されます。
Q4. どうしてもダウンタイムを出せない場合はどうすればよいですか？
A. 完全にゼロダウンタイムにするのは難しいケースが多いですが、次のような工夫で影響を最小化できます。
- 複数トンネル構成を活かし、旧ゲートウェイと新ゲートウェイを段階的に切り替える
- オンプレ側で冗長な VPN 装置を用意し、一方ずつ接続先を切り替える
- 業務影響の少ない時間帯に切り替え作業を行い、事前に利用者へ周知する
それでも難しい場合は、設計レベルからネットワーク冗長構成を見直すことも検討ポイントになります。
Q5. ExpressRoute を併用している場合、何か追加で注意すべき点はありますか？
A. ExpressRoute Gateway と VPN Gateway が同一 VNet に混在しているケースや、Failover 目的で VPN を使っているケースでは、ルーティングや優先度の設計を十分に理解した上で移行する必要があります。ExpressRoute 側の経路広告やプレフィックスに影響がないか、必ず事前に検証しましょう。
まとめ：『変えられない』ではなく『作り直して乗り換える』発想で
本記事の内容をまとめると、次のようになります。
- VPN Gateway に紐づいた Basic SKU の Public IP は、Dynamic → Static への変更が仕様上できないため、ポータルの選択肢がグレーアウトしている
- Microsoft は Basic SKU Public IP を 2026 年 1 月末で廃止する予定で、それまでに自動置き換えツール（2025 年 10 月頃提供予定）や手動移行で Standard SKU へ移行する必要がある
- 早期に Standard SKU＋Static IP へ移行したい場合は、新しい Public IP リソースと新しい VPN Gateway を構築し、Site-to-Site／Point-to-Site／VNet 間接続を順次切り替える
- 運用面では、Public IP リソースそのものではなく「ゲートウェイの IP 属性」を参照するよう監視やスクリプトを見直すと、今後の変更にも強い設計になる
Azure のネットワーク基盤は、一度構築してしまうと「普段はあまり触らない」部分だからこそ、ライフサイクルの節目にきちんと向き合っておくことが重要です。今回の Basic SKU Public IP 廃止を、「VPN Gateway 周辺の設計や運用を整える良いきっかけ」と捉え、段階的に Standard SKU＋Static IP への移行を進めていきましょう。
コメント