Azure VPN Gateway / ExpressRoute Gateway をレガシー SKU から新しい SKU（可用性ゾーン対応）へ移行する時、「静的割り当てのパブリック IP は本当に維持できるのか？」は運用・接続設計の核心です。本記事では、VPN と ExpressRoute それぞれの挙動差、IP が変わる条件、Basic Public IP 廃止に向けた現実的な進め方をまとめます。
結論：静的でも「変わる」と「変わらない」がある
先に結論だけ整理すると、Public IP が「静的割り当て」でも、移行方式によって IP の扱いが分かれます。
- VPN Gatewayは、SKU アップグレードやポータルの移行機能で済む場合、Public IP を維持できるケースが多い。
- 一方で、削除→再作成が必須になる移行（代表例：旧レガシー SKU から新 SKU へ）では、静的でも Public IP は変わる。
- ExpressRoute Gatewayのガイド付き移行は、新しいゲートウェイを並行作成して切り替える方式のため、Public IP は新規割り当てになりやすい（＝変わる前提で計画する）。
まず整理：ゲートウェイ SKU と Public IP SKU は別レイヤー
混乱の原因になりやすいのが、「ゲートウェイの SKU」と「Public IP の SKU（Basic/Standard）」が別物だという点です。ゲートウェイの SKU を変えても、Public IP の SKU を放置していると、廃止・非推奨の影響を受けます。
| 項目 | 何を表す？ | 移行時に効いてくるポイント |
|---|---|---|
| ゲートウェイ SKU（例：VpnGw1 / VpnGw1AZ / Standard / ErGw1Az など） | ゲートウェイの性能・冗長性（AZ 対応など） | 「アップグレードで済むか」「再作成が必要か」で Public IP の扱いが変わる |
| Public IP の SKU（Basic / Standard） | Public IP リソースの機能・可用性・セキュリティモデル | Basic の廃止（Retire/Deprecate）により、同じ IP を使い続けたいなら早期に Standard 化が重要 |
VPN Gateway：SKU 変更・AZ 対応で Public IP はどうなる？
VPN Gateway は「移行方式」が複数あり、ここを取り違えると “静的なのに IP が変わった” が起きます。以下の表で、現場で遭遇しやすいパターンを整理します。
| 変更パターン | Public IP は変わる？ | ダウンタイム目安 | 運用上の要点 |
|---|---|---|---|
| 同系列の SKU アップグレード（例：VpnGw1 → VpnGw2 など） | 変わらない | 約 45 分（目安） | オンプレ側の IP 変更は不要。ウィンドウ確保と再接続確認を実施 |
| 同 tier で非 AZ → AZ（例：VpnGw1 → VpnGw1AZ） | 変わらない | 原則なし（同 tier の AZ 切替はダウンタイムなしの扱い） | 「AZ SKU ＝必ず作り直し」と決めつけない。アップグレード対象か確認 |
| Basic Public IP → Standard Public IP（ポータルの移行機能を利用） | 変わらない | 最大 10 分程度（顧客操作の移行） | 要件（GatewaySubnet の空き IP など）を満たすと IP 維持しやすい |
| レガシー SKU（Standard / High Performance）→ 新 SKU（VpnGw1AZ 等） | 変わる | 削除→再作成のため停止 | 同じ Public IP オブジェクトを指定しても IP が変わる挙動が明記されている |
| VPN Gateway Basic SKU → 他 SKU | 変わる | 削除→再作成のため停止 | Basic Gateway SKU はアップグレード不可（作り直し前提） |
「AZ SKU にすると必ず IP が変わる」は、今は正しくないケースがある
古い情報では「AZ SKU へ移行すると再作成されるので Public IP は変わる」と説明されがちですが、VPN Gateway の新しい運用では、アップグレードで AZ SKU へ切り替えできる経路が明示されており、その場合は Public IP は変わらない扱いです（例：VpnGw1 → VpnGw1AZ）。
逆に、レガシー SKU（Standard / High Performance）から新 SKU へ「変更」する場合は、削除→再作成が必要であり、さらに同じ Public IP リソースを指定しても IP は変わると明記されています。ここが “静的なのに変わった” 事故の典型です。
VPN Gateway：非 AZ SKU（VpnGw1-5）から AZ SKU への流れと、作成制限・自動移行の考え方
VpnGw1-5 の非 AZ SKU は、冗長性の観点から AZ SKU へ寄せる方針が明確になっています。重要なのは「いつまでに何が起きるか」を把握し、IP 維持が必要なら先に手を打つことです。
- 非 AZ の VpnGw1-5 は、新規作成が 2025 年 11 月 1 日以降できなくなる旨が案内されています。
- 2025 年 9 月～2026 年 9 月の期間に、既存の非 AZ ゲートウェイは AZ SKU へ移行され得る（目標は 2026 年 9 月 16 日）。
- Standard Public IP を使っている非 AZ SKU の AZ 移行は、ダウンタイムなしが想定と記載されています。
VPN Gateway：Basic Public IP を「同一 IP のまま」Standard 化する実務ポイント
「Public IP を変えたくない」場合、最優先で検討したいのがVPN Gateway 向けの Basic→Standard 移行機能（ポータルの移行エクスペリエンス）です。通常の Public IP 単体アップグレードは “リソース未関連付け” が条件になりがちですが、VPN Gateway は関連付け解除が難しいため、専用の移行導線が用意されています。
- VPN Gateway の Basic Public IP 移行は、移行エクスペリエンスを使うことでゲートウェイ IP が変わらない前提で設計されています。
- 一方、手動で削除→再作成を選ぶと、結果としてIP が変わる可能性が高く、オンプレ機器の再設定が必須になります。
- 移行中は最大 10 分程度のダウンタイムが見込まれる点は、変更管理に組み込んでおくべきです。
移行の前提条件でよく詰まるポイント（GatewaySubnet）
VPN Gateway の Basic→Standard 移行（ポータル移行）は、事前チェックに通るかどうかで勝負が決まります。特に GatewaySubnet です。
- 移行エクスペリエンスの前提として、GatewaySubnet に最低 3 つの空き IPが必要（不足時はサブネット拡張が必要）。
- 既存が /28 などで窮屈な場合は、/27 以上へ拡張（もしくは追加プレフィックス）を検討します。
Azure ポータル上で「Migrate（移行）」タブが出るかどうかは環境差があるため、まずはゲートウェイの Configuration で移行 UI の有無を確認し、表示されない場合は（機能ロールアウトや条件未達の可能性があるので）別経路の計画が必要です。
ケーススタディ：VpnGw1（non-AZ）＋ Basic Public IP の本番環境を「IP維持」で守る
ここでは、質問で挙がっている構成を “現場のあるある” として扱い、判断の勘所を具体化します。
| 要素 | 例 | リスク／論点 |
|---|---|---|
| VPN Gateway 名 | prod-vpn-gateway | オンプレ側がこの Public IP を対向先として参照している可能性が高い |
| ゲートウェイ SKU | VpnGw1（non-AZ） | AZ SKU へ集約される流れ。作成制限・移行期間の影響を受ける |
| Public IP | vpn-gateway-ip（Basic / Static） | Basic IP の廃止・非推奨の影響を受ける。IP維持には移行経路が鍵 |
推奨アプローチ（IP を変えたくない場合）
IP 維持を最優先にするなら、考え方はシンプルです。「削除→再作成」に落ちないルートを選びます。
- まず Public IP を Standard 化する（可能なら移行エクスペリエンス）
- VPN Gateway の移行機能を使えるなら、そのルートが “IP維持” の王道です。
- GatewaySubnet の空き IP やサイズ要件を先に潰します（ここを後回しにすると当日詰みます）。
- 次に SKU を AZ へ（アップグレードで済むならアップグレードで）
- 同 tier の非 AZ → AZ（例：VpnGw1 → VpnGw1AZ）は、ダウンタイムなし・Public IP 不変の扱いが明記されています。
- 非 AZ SKU の自動移行が走る期間があるため、手動で先回りする場合は “何を目的に先回りするのか（性能UPなのか、期限回避なのか）” を決めて実施します。
- 移行後の検証（ここが抜けると結局障害になる）
- S2S：IKE/IPsec トンネル状態、BGP（使用している場合）の再収束、スループットとパケットロス
- P2S：クライアント配布方式（証明書/Entra ID など）ごとの再接続
- 監視：ゲートウェイのメトリック、ログ、アラートの継続性
運用メモ：最低限ここだけは “事前に見える化” しておく
当日バタつきがちなため、移行前に「現状の SKU と Public IP の紐づき」をコマンドで残しておくと、関係者説明が一気に楽になります。
az network vnet-gateway show -g <RG> -n <VPNGW_NAME> \
--query "{gatewayType:gatewayType,sku:sku.name,ip:ipConfigurations[].publicIPAddress.id}" -o jsonこの “before/after” を残しておくと、IP が変わっていないことの証跡にも、変わってしまった時の調査の入口にもなります。
VPN Gateway の Basic Public IP 廃止：いま押さえるべき期限感
Basic Public IP 自体は 2025 年 9 月 30 日に Retire とされつつも、実運用上は「サービスごとの移行猶予」「移行機能の提供状況」が絡みます。Microsoft Learn のガイダンスでは、Retire 後も Basic IP を使い続けることは可能だが非サポート（SLA 対象外）になる点が明記されています。
VPN Gateway に関しては、移行ツール提供と合わせて廃止時期が延長され、少なくとも2026 年 3 月末までの延長が示されています（ただし “タイムラインは変更され得る” 旨の注記もあります）。
| テーマ | 主な日付（目安） | 何が起きる？ | 推奨アクション |
|---|---|---|---|
| Basic Public IP の全体方針 | 2025/09/30 | Retire とされ、以後は非サポート（SLA 外）になり得る | Standard 化を前提に移行計画を確定 |
| VPN Gateway の Basic IP（移行ツールあり） | ～2026 年 3 月末（目安） | VPN 向け Basic→Standard 移行を進めるための猶予が示されている | IP 維持が必要なら、ポータル移行エクスペリエンスを優先検討 |
| VpnGw1-5（非 AZ）の新規作成制限 | 2025/11/01 | 非 AZ の VpnGw1-5 が新規作成不可 | 新規は AZ SKU を前提に設計 |
| 非 AZ → AZ への移行フェーズ | 2025/09～2026/09 | 既存ゲートウェイが AZ SKU へ移行され得る（目標日 2026/09/16） | Standard IP 化を先行し、移行後検証を手順化 |
ExpressRoute Gateway：Public IP の考え方が VPN と根本的に違う
ExpressRoute Gateway の Public IP は、VPN のように “対向機器が叩くエンドポイント” ではありません。Microsoft の説明では、Public IP はコントロールプレーン用途（内部用途）として言及されることが多く、データパスはあくまでプライベートに流れます。
さらに近年は、ExpressRoute ゲートウェイの Public IP を “ユーザーが管理するリソース” として扱わない方向へ進んでおり、Microsoft が Public IP をバックエンドで自動割り当て・管理する（Auto-assigned public IP）という記載も追加されています。これにより、作成・運用の手間は減りますが、運用側は「Public IP を固定資産として扱う」発想を捨てる必要が出てきます。
ExpressRoute Gateway の移行：なぜ IP が変わる前提になるのか
ExpressRoute のガイド付き移行は、仕組みとして “置き換え” です。ドキュメントでは、移行ツールが2 台目のゲートウェイをデプロイし、そこへ新しい Public IP が自動割り当てされることが明記されています。つまり、同じ Public IP を握り続ける設計ではないのが前提です。
また、ExpressRoute 側では Basic Public IP の retirement（2025/09/30）が明記されており、Basic を使っている構成は早急な移行が必要です（現時点ではすでに期限を過ぎているため、動いていても “未対応のまま温存” は避けるべきです）。
ExpressRoute ガイド付き移行の流れ（現場目線の要点）
| フェーズ | 何が起きる？ | 影響 | 現場の注意点 |
|---|---|---|---|
| Validation | 移行要件（GatewaySubnet など）をチェック | 影響なし | /27 以上のサブネットなど、ネットワーク設計が原因で落ちやすい |
| Prepare | 2 台目のゲートウェイを作成し、並行稼働の準備 | 最大 45 分程度かかり得る | “時間がかかる＝止まっている” ではない。進捗監視と説明が重要 |
| Migrate | 切り替え。新ゲートウェイへ移行 | 最大 15 分程度の停止があり得る | Private Endpoint など影響が出やすい通信は事前周知と停止計画が有効 |
| Commit | 旧ゲートウェイを削除し、新構成を確定 | 最終確定 | Commit を最大 15 日保留できるため、検証と承認のために使える |
「Public IP が変わる」ことで実際に困るのはどこ？
ExpressRoute はデータパスがプライベートなので、VPN のように “対向装置の接続先 IP を書き換える” 事故は起きにくい一方、次のような運用があると影響が出ます。
- 監視・棚卸しが Public IP リソース（または Public IP の表示値）に依存している
- 運用バッチや IaC が「Public IP リソースを前提」にしている（Auto-assigned 化で見え方が変わる）
- セキュリティ運用で “ゲートウェイの Public IP” を許可リスト的に扱ってしまっている（実態はコントロールプレーン用途）
このため ExpressRoute では、移行前に「誰が何のためにその IP を参照しているか」を棚卸しし、参照を “ゲートウェイリソース” 側へ寄せるのが安全です。
VPN と ExpressRoute：変更影響の比較（現場での“面倒さ”はここが違う）
| 観点 | VPN Gateway | ExpressRoute Gateway |
|---|---|---|
| Public IP の役割 | インターネット越しの VPN エンドポイント（対向装置が参照） | 主にコントロールプレーン用途（データはプライベート） |
| IP が変わると致命傷？ | なりやすい（対向装置・FW・NAT・許可設定が連鎖） | なりにくい（ただし運用・監視・IaC の参照があると影響） |
| IP を維持する現実的手段 | アップグレード or Basic→Standard 移行エクスペリエンス | 移行ツールが新 IP を割り当てるため、基本は “変わる前提” で運用設計を見直す |
| ダウンタイムの出方 | SKU により 0～45 分＋（移行ツールは最大 10 分程度の記載） | Prepare に時間がかかり、切替（Migrate）で最大 15 分程度の停止があり得る |
実務チェックリスト：失敗しないための準備と検証
共通（VPN/ExpressRoute 共通）
- 現状棚卸し：ゲートウェイ SKU / Public IP SKU / GatewaySubnet のサイズと空き / 監視・IaC の依存先
- 変更管理：影響範囲、切替手順、ロールバック/ロールフォワード方針、連絡網
- 事前検証：可能なら検証環境で同じ移行を一度やる（特に ExpressRoute は手順が長い）
VPN Gateway（IP維持を狙う場合）
- Public IP が Basic の場合：ポータルの移行エクスペリエンスが使えるか確認（Configuration 画面）
- GatewaySubnet の空き IP（最低 3）を確保／不足なら拡張
- 移行後：S2S トンネル、BGP、P2S の再接続、スループット、ログ/メトリックの継続性を確認
ExpressRoute Gateway（移行後の“見え方”変更に備える）
- GatewaySubnet は /27 以上を推奨（移行要件として言及がある）
- 切替時の停止（最大 15 分程度）を前提に、Private Endpoint など影響の出やすい通信を事前に周知・抑制
- Auto-assigned public IP の記載があるため、移行後は「Public IP リソース前提」の運用をやめ、ゲートウェイリソース中心の監視へ寄せる
よくある落とし穴と回避策
落とし穴： “静的 IP だから絶対変わらない” と信じてしまう
静的は “その Public IP リソース内では固定” という意味であって、移行方式が削除→再作成に落ちれば別 IP になる可能性があります。レガシー SKU から新 SKU へ切り替えるケースでは、同じ Public IP を指定しても IP が変わる旨が明記されています。
落とし穴： GatewaySubnet を放置して当日 Validation で落ちる
VPN も ExpressRoute も、移行は “サブネット設計” に強く依存します。/27 以上の推奨や空き IP の要件に早めに着手し、当日はゲートウェイ側の作業に集中できる状態にしておくのが安定です。
落とし穴： ExpressRoute の Public IP を許可リスト運用している
ExpressRoute の Public IP は内部用途として語られることが多く、さらに自動割り当て・Microsoft 管理の方向へ進んでいます。特定 IP を “固定資産” として許可リストに組み込む運用は、長期的に破綻しやすいので、参照点を「ゲートウェイリソース」「回線・BGP・ルートの健全性」に寄せるのが安全です。
まとめ：期限対策は「Public IP を守る」より「変わっても困らない運用」を作る
VPN Gateway は、移行方式を正しく選べば Public IP を維持できる余地があります（アップグレード、または Basic→Standard 移行エクスペリエンス）。一方、ExpressRoute Gateway は新ゲートウェイへの置き換えが前提になりやすく、Public IP を固定資産として扱う発想を捨てた方が安全です。どちらも共通して言えるのは、Basic Public IP 廃止の流れの中で「いま動いているから放置」ではなく、手順化・検証・監視の見直しまで含めて移行を完了させることが、最終的に運用コストと障害リスクを下げます。
コメント