Azure ExpressRoute ゲートウェイで Basic SKU Public IP を利用している場合、廃止スケジュールに備えた対応が必須になっています。本記事では、Gateway SKU Migration ツールを使って Standard SKU Public IP へ安全に移行する方法を、設計意図や注意点も交えて詳しく解説します。手順だけでなく、運用上のベストプラクティスやよくある疑問にもまとめて回答します。
背景：Basic SKU Public IP 廃止と ExpressRoute ゲートウェイへの影響
Azure では段階的に Basic SKU Public IP の新規作成が停止され、将来的な廃止がアナウンスされています。これにより、次のような構成を利用している環境では対応が避けられません。
- ExpressRoute ゲートウェイ（可用性ゾーン非対応 SKU）
- ゲートウェイに紐付く Public IP が Basic SKU
多くの管理者が悩むポイントは次のようなものです。
- Gateway SKU Migration ツールは「ゲートウェイ SKU だけ」変更するものなのか？ Public IP の SKU まで自動で更新されるのか？
- 一般的な「Public IP の Basic → Standard へのアップグレード手順」は、ExpressRoute ゲートウェイでも使えるのか？
- ツールを使っても、最終的にはゲートウェイ再作成や BGP ピア設定のやり直しが必要なのでは？
結論から言うと、ExpressRoute ゲートウェイに紐付いた Basic SKU Public IP は、Gateway SKU Migration ツールだけでインプレースに Standard SKU Public IP に置き換え可能です。さらに、同じツールのウィザード内で、ゲートウェイ自体を可用性ゾーン対応の SKU（AZ SKU）に引き上げることもできます。
ExpressRoute ゲートウェイと Public IP SKU の基本整理
ExpressRoute ゲートウェイとは
ExpressRoute ゲートウェイは、オンプレミス環境と Azure 仮想ネットワーク（VNet）を専用線または閉域網経由で接続するための Virtual Network Gateway の一種です。VPN Gateway と異なり、インターネット VPN ではなく、キャリアやサービスプロバイダーを経由したプライベート接続を前提としています。
代表的な役割は次の通りです。
- ExpressRoute 回線（Circuit）と VNet の関連付け（トラフィック終端）
- オンプレミスルーターとの BGP ピアリング
- ルートテーブル（UDR）やオンプレ側の経路と連携した経路制御
このゲートウェイに対して Azure は Public IP を割り当てますが、ExpressRoute 特有の制約があるため、一般の VNet 内リソースに紐付く Public IP アドレスと扱いが異なる点が重要です。
Basic / Standard SKU Public IP の違い
ここで、ExpressRoute ゲートウェイに限らず Azure 全体での Public IP SKU の違いをざっくり整理します。
| 項目 | Basic SKU Public IP | Standard SKU Public IP |
|---|---|---|
| 可用性ゾーン対応 | 非対応（ゾーン指定不可） | ゾーン冗長／ゾーン指定が可能（リージョンによる） |
| セキュリティモデル | 既定でオープンな構成が多い | 原則「閉じる」が前提（NSG などと組み合わせる設計） |
| スケーラビリティ | レガシー扱い、今後機能拡張は期待薄 | 最新機能の対象。新サービスは Standard 前提が多い |
| 新規作成可否 | 段階的に制限・廃止予定 | 今後の標準 |
| 主な用途 | 初期の Azure リソース向け | 現行推奨構成全般（LB/VM/ゲートウェイなど） |
ExpressRoute ゲートウェイの Basic SKU Public IP は、この「レガシー側」に分類されるため、廃止前に Standard SKU へアップグレードしておく必要があるというわけです。
よくある 3 つの疑問と結論まとめ
疑問 1：Gateway SKU Migration ツールはゲートウェイ SKU だけを変える？
結論：いいえ。Gateways SKU Migration ツールは、ゲートウェイに紐付く Basic SKU Public IP も自動的に Standard SKU Public IP に置き換えます。
管理者が混乱しやすいポイントですが、ツールの役割は次の 2 つを包含しています。
- ExpressRoute ゲートウェイそのものの SKU 変更（例：非 AZ → AZ SKU）
- 紐付く Public IP の SKU 変更（Basic → Standard）
つまり、
- 「ゲートウェイ SKU は今のままで、Public IP だけ Standard にしたい」
- 「どうせなら可用性ゾーン対応 SKU へ引き上げたいので、ゲートウェイと Public IP をまとめて新構成にしたい」
といったどちらのパターンも、同じ Migration ツールでカバー可能です。
さらに、Migration ツールは次のような設計になっています。
- 既存構成をベースに、並行して新ゲートウェイ（新 SKU）＋ Standard SKU Public IP を作成
- テストフェーズ中は旧構成を維持したまま疎通確認が可能
- 問題なければ既存トラフィックを新構成へ切り替え
- Commit 後に旧 Basic SKU Public IP を自動解放
そのため、運用者は「ツールを起動してウィザードに従う」だけで、ゲートウェイと Public IP の両方をまとめてアップグレードできます。
疑問 2：Public IP だけ個別にアップグレードできないのか？
結論：ExpressRoute ゲートウェイに紐付く Public IP は、一般的な Public IP のアップグレード手順ではサポートされていません。Migration ツールを使うことが唯一かつ公式な方法です。
通常の仮想マシンや Load Balancer などに付いている Public IP は、Basic から Standard へのアップグレードに関して、次のような手順が紹介されることがあります。
- 新しい Standard SKU Public IP を作成
- 元リソースから Basic SKU Public IP を切り離す
- Standard SKU Public IP を付け替える
しかし、ExpressRoute ゲートウェイではこのやり方は想定されていません。理由は以下のような点にあります。
- ゲートウェイの Public IP は、Azure 内部の制御プレーンと密接に連携している
- 単純な「紐付けの付け替え」では整合性を保てないケースがある
- ExpressRoute 固有の制約や依存関係（回線、ピアリング、経路）を考慮する必要がある
このため、Azure 公式としてサポートされる方法は、ExpressRoute Gateway Migration ツールを用いた一括移行のみになります。個別の Public IP アップグレード手順を無理に流用すると、将来的なサポートが受けられない構成になるリスクがあるため、避けるべきです。
疑問 3：ゲートウェイ再作成や BGP 設定のやり直しは必要？
結論：基本的には不要です。Migration ツールは既存構成をインプレースで移行する設計であり、ExpressRoute 回線や BGP ピア設定を手作業で再構成する必要はありません。
ツールは次のような流れで動作します。
- 既存の ExpressRoute ゲートウェイ構成（Circuit、接続、BGP 設定など）を内部的にコピー
- 新 SKU のゲートウェイと Standard SKU Public IP を用意
- テストフェーズ中に経路・疎通を検証
- Commit 操作でトラフィックを新構成へ切り替え
この間、ExpressRoute Circuit 自体の再作成や、オンプレミスルーター側の BGP ピア再設定は原則不要です。BGP ピアリングのパラメーター（ASN、アドレス、パスワードなど）はツール側で引き継がれます。
また、Migration ウィザードには 「Abort（切り戻し）」 機能も用意されており、テスト中に問題を見つけた場合は、即座に旧構成へ戻すことが可能です。
Gateway SKU Migration ツールの全体像と構成イメージ
移行前後の構成イメージ
Migration ツールを使った場合の構成変化を、シンプルな表で整理します。
| 項目 | 移行前 | 移行後（例） |
|---|---|---|
| ゲートウェイ SKU | ErGw1 / ErGw2 / ErGw3 など（非 AZ） | ErGw1AZ / ErGw2AZ / ErGw3AZ など（任意で AZ 対応に変更可能） |
| Public IP SKU | Basic SKU Public IP | Standard SKU Public IP（自動で置き換え） |
| ExpressRoute Circuit | 既存回線を利用 | 同一回線を継続利用（再作成不要） |
| BGP ピア設定 | 既存設定 | ツールにより自動引き継ぎ |
| オンプレ FW / ルーター設定 | 既存設定 | 基本的に変更不要（テストで確認） |
このように、「ExpressRoute 回線やオンプレ設定を極力触らずに、Azure 側のゲートウェイと Public IP を世代交代させる」のが Gateway SKU Migration ツールの役割です。
移行手順サマリと詳細解説
ここでは、Azure Portal のウィザードを前提に、実際の操作イメージを整理します。環境によっては PowerShell や CLI ベースで実施するケースもありますが、考え方は同じです。
事前チェック：移行前に必ず確認すべきポイント
まず、次の事前チェックを行います。
| 確認項目 | 内容 | ポイント |
|---|---|---|
| 対象ゲートウェイの特定 | Azure Portal で対象 ExpressRoute ゲートウェイを開き、「Gateway SKU Migration」メニューを確認 | メニューが表示されない場合は、リージョンや SKU が対象外の可能性 |
| Public IP SKU の確認 | ゲートウェイに紐付く Public IP を開き、SKU が Basic であることを確認 | 既に Standard の場合は、Migration の目的は「AZ 化」のみになる |
| サブスクリプションの権限 | 所有者 / 共同作成者レベルの権限があるか確認 | ゲートウェイ作成・削除、Public IP 管理権限が必要 |
| クォータ・制限 | VNet ゲートウェイ数、Public IP 数のサブスクリプション上限を確認 | Migration 中に一時的に余分なリソースを確保する場合がある |
| メンテナンス時間帯 | 業務影響が少ない時間帯を設定 | 理論上はダウンタイムなし想定だが、念のためメンテ窓を確保 |
特に、サブスクリプションのクォータ不足は Migration 実行中にエラーを招く要因になりやすいので、事前に Azure サポートやポータルからクォータ引き上げを済ませておくと安心です。
移行開始：Gateway SKU Migration の起動
事前チェックが完了したら、Azure Portal から Migration を開始します。
- 対象の ExpressRoute ゲートウェイを開く
- メニューから「Gateway SKU Migration」あるいは類似の項目を選択
- ウィザードの最初の画面で、現在の SKU と Public IP 情報を確認
- 新しいゲートウェイ SKU を選択（例：ErGw2AZ など）
- Public IP の SKU が自動的に Standard に変更されることを確認
- 設定内容を確認し、「Start Migration」を実行
ここで選択するゲートウェイ SKU によって、可用性ゾーン対応かどうかが決まります。「現状から最小限の変更で Public IP だけ Standard にしたい」場合は、同等性能帯の SKU を選択するとよいでしょう。
テストフェーズ：疎通確認と BGP モニタリング
Migration を開始すると、Azure 側で新しいゲートウェイと Standard SKU Public IP の準備が進みます。設定完了後、ウィザード上で テストフェーズ（Validation/Test フェーズ） に入ります。
このフェーズで実施すべきことは次の通りです。
- オンプレミス側ルーターで BGP セッション状態を確認
- ExpressRoute 経由で到達する主要な Azure リソースへの疎通確認（Ping、HTTP/HTTPS、アプリケーションレベルの確認など）
- 経路テーブル（BGP テーブル）の変化有無を確認し、期待通りのプレフィックスがアドバタイズされているかをチェック
特に BGP の状態は、次のような観点で監視すると安心です。
| 監視項目 | 確認内容 | 想定される問題と対処 |
|---|---|---|
| BGP セッション状態 | オンプレ側で Established 状態が維持されているか | Flap が多い場合は Abort も検討し、原因調査を優先 |
| 受信ルート数 | 旧構成時と比較して大きな差がないか | 極端に減少している場合は経路フィルタリング設定を要確認 |
| 送信ルート数 | オンプレ側から広告しているプレフィックス数に変化がないか | ExpressRoute ゲートウェイでのルート処理に問題がないか確認 |
| アプリケーション疎通 | 業務アプリケーションのレスポンスやエラー有無 | タイムアウト増加などがあれば Commit を保留し原因分析 |
もしテストフェーズで問題が見つかった場合、Migration ウィザードから 「Abort」操作を実行することで、旧ゲートウェイ構成に即座にロールバックできます。この際、ExpressRoute 回線やオンプレミス設定は元のまま維持されるため、影響範囲を最小限に抑えられます。
Commit：本番切り替えとクリーンアップ
テストフェーズで問題がなければ、「Commit」 を実行して新構成を正式に採用します。この時点で次のような変更が確定します。
- ExpressRoute トラフィックの終端が新ゲートウェイ（新 SKU）へ切り替え
- Basic SKU Public IP が解放され、Standard SKU Public IP が正式利用開始
- 旧ゲートウェイ関連リソースがクリーンアップ
Commit 後は、再度戻すためには別途 Migration 操作を行う必要があるため、テストフェーズ中に十分な確認を行うことが重要です。Commit 直後は、次のような追加確認を実施しておくと安心です。
- 主要アプリケーションの動作確認（ユーザー視点の操作も含めて）
- 監視ツールでのメトリック・アラート状況確認
- ログ（Firewall、ルーター、Azure Monitor）の異常有無確認
移行時の注意点とベストプラクティス
Gateway SKU Migration ツールは「ほぼ自動」で移行できるとはいえ、運用上の工夫でリスクをさらに下げることができます。
メンテナンス時間帯の確保
設計上はダウンタイムなしを想定しているものの、現実には次のような要因で短時間の影響が出る可能性があります。
- BGP 経路の再収束時間
- オンプレ側のルーターやファイアウォールでのセッション再確立
- アプリケーション側の長時間セッションタイムアウト
そのため、業務トラフィックが比較的少ない時間帯にメンテナンスウィンドウを確保し、その範囲内で Migration を実行するのが安全です。
BGP セッション・ログのモニタリング
テストフェーズから Commit 直後にかけて、オンプレ側と Azure 側の BGP セッションを重点的に監視します。具体的には、次のような情報を事前に把握し、比較できるようにしておくと便利です。
- Migration 前後の BGP ピア IP、ASN、パスワード
- 平常時の受信／送信ルート数（ベースライン）
- Firewall での BGP 関連トラフィックログ（ポート 179）
Migration 中に BGP セッションが不安定になる場合、テストフェーズの段階で Abort を実行し、その後オンプレネットワークチームと連携して原因を切り分けるとよいでしょう。
Rollback 計画の明文化
Abort 操作が用意されているとはいえ、「いつ Abort するのか」「誰の判断で行うのか」を事前に決めておくことが重要です。例えば、次のようなルールを決めておくとスムーズです。
- 業務影響が 10 分以上継続する障害が発生した場合は Abort
- クリティカルシステムの疎通確認が 1 つでも NG の場合は Abort
- Abort の判断はネットワーク担当とシステムオーナーが合意の上で行う
また、Rollback 時にも影響する可能性がある要素として、DNS の TTL やオンプレ FW の長期セッションなどがあります。これらが長すぎると、新旧構成切り替え後も一部の通信が古い情報を引きずるケースがあるため、重要なシステムについては TTL を短くしておくなどの工夫も検討してください。
可用性ゾーン対応（AZ SKU）への移行をどう考えるか
Basic SKU Public IP 廃止への対応だけが目的であれば、最低限の変更で済ませることも可能です。しかし、せっかく Migration ツールを使うのであれば、ExpressRoute ゲートウェイの可用性ゾーン対応（AZ SKU）への移行もあわせて検討する価値があります。
AZ SKU へ移行するメリット
- リージョン内部の障害（特定ゾーン障害）に対する耐性向上
- 将来のプラットフォーム機能拡張の恩恵を受けやすい
- 「ExpressRoute ゲートウェイ自体の単一障害点」を減らせる
特に、ミッションクリティカルなシステムで ExpressRoute を利用している場合、可用性ゾーン非対応のまま運用を続けることは、障害リスクの観点で好ましくありません。Migration ツールなら、Public IP の SKU 変更と同時に AZ SKU へ移行できるため、構成変更の手間をまとめて実施できる点も利点です。
AZ SKU にする際の注意点
AZ SKU 自体は Azure 側の冗長化ですが、次のようなポイントも合わせて確認しておくと、トータルの可用性設計としてバランスが取れます。
- オンプレ側ルーター／回線も冗長構成になっているか
- ExpressRoute 回線自体の冗長性（プライマリ／セカンダリ）
- VNet 内の重要リソースが可用性ゾーンを意識した配置になっているか
ExpressRoute ゲートウェイだけを AZ 化しても、オンプレ側や VNet 側が単一構成のままでは、全体としての可用性は限定的です。Migration のタイミングをきっかけに、ネットワーク全体の冗長化設計を見直すことをおすすめします。
Standard SKU Public IP への移行後に確認すべきポイント
Migration を完了し、Standard SKU Public IP に切り替わった後にも、いくつか確認しておきたいポイントがあります。
料金・コストモデルの変化
Standard SKU Public IP は、Basic と比較して料金モデルや課金単位が異なる場合があります。ExpressRoute ゲートウェイ全体としても、SKU を上げることで月額料金が増加するケースがあります。
- 事前に料金計算ツールなどで概算コストを試算しておく
- Migration 後 1〜2 か月の請求を確認し、想定値と大きな差がないかをチェック
監視・アラートの閾値見直し
AZ SKU や新しい Public IP に切り替わることで、パフォーマンスや遅延特性がわずかに変化することがあります。これにより、既存の監視閾値が適切でなくなる場合があります。
- ネットワーク遅延のベースラインを Migration 前後で比較
- パケットロスやエラー率のアラート閾値が厳しすぎないか確認
ドキュメント・図面の更新
最後に、システム構成図や運用ドキュメントの更新を忘れないようにしましょう。
- ゲートウェイ SKU 名を最新のものに更新
- Public IP の SKU とアドレス情報を更新（アドレスが変わったかどうかも含めて）
- 障害対応手順書に「Gateway SKU Migration 実施済み」である旨を追記
これにより、数年後に担当者が変わっても、「なぜこの SKU なのか」「どのタイミングで切り替えたのか」が分かるようになり、運用の継続性が高まります。
まとめ：追加リソース作成や設定やり直しなしで安全に移行する
ここまでの内容を整理すると、Basic SKU Public IP 廃止への対応として押さえておくべきポイントは次の通りです。
- Gateway SKU Migration ツールを使えば、ExpressRoute ゲートウェイに紐付く Basic SKU Public IP は自動的に Standard SKU Public IP に置き換えられる
- 一般的な「Public IP の個別アップグレード手順」は ExpressRoute ゲートウェイには適用されず、Migration ツールが唯一かつ公式サポートされた方法である
- ツールは既存構成をインプレースで移行する設計のため、ExpressRoute 回線の再作成や BGP ピア設定のやり直しは原則不要
- テストフェーズと Abort 機能により、問題発生時には旧構成へ安全に切り戻し可能
- メンテナンス時間帯の確保、BGP セッションのモニタリング、Rollback 基準の明文化などの運用工夫により、リスクをさらに低減できる
- この機会に、可用性ゾーン対応 SKU への移行やネットワーク全体の冗長化見直しも合わせて検討すると、中長期的なメリットが大きい
Basic SKU Public IP の廃止は、単なる「やらされタスク」にも見えますが、見方を変えれば ExpressRoute ネットワーク基盤を一段アップグレードする良いチャンスでもあります。Gateway SKU Migration ツールを活用し、追加のリソース作成や手動再設定に追われることなく、計画的かつ安全に Basic → Standard SKU Public IP への移行を完了させていきましょう。
コメント