この記事では、ExpressRoute ゲートウェイの移行プロセスの概要を説明します。これにより、現在の SKU から同等以上の SKU に移行したり、Basic IP から Standard IP に移行したりできます。これにより、信頼性と可用性が向上しますが、ダウングレードはサポートされていません。
他のネットワーク サービスの Basic SKU パブリック IP アドレスのアップグレードに関するガイダンスについては、「 Basic から Standard SKU へのアップグレード」を参照してください。
Important
Basic SKU パブリック IP は 2025 年 9 月 30 日に廃止されます。 詳細については、公式告知を参照してください。 現在 Basic SKU パブリック IP を使用している場合は、提供終了日より前に Standard SKU パブリック IP にアップグレードしてください。
Gateway の SKU
ErGw1Az、ErGw2Az、ErGw3Az、および ErGwScale (プレビュー) SKU は、可用性ゾーン (Az) 対応 SKU と呼ばれます。 これらの SKU を使用すると、複数の可用性ゾーンにデプロイでき、ゾーン間でゲートウェイ リソースを分散することで回復性と高可用性が向上します。
これに対して、 Standard、 HighPerformance、 UltraPerformance の SKU は Az 対応以外です。 これらは通常、Basic パブリック IP アドレスで使用され、可用性ゾーンの配布はサポートされていません。
ゲートウェイ移行エクスペリエンス
ゲートウェイの移行エクスペリエンスを使用すると、同じ GatewaySubnet に 2 つ目の仮想ネットワーク ゲートウェイをデプロイできます。Azure では 新しいパブリック IP が自動的に割り当てられ 、手動で IP を作成する必要がなくなりますが、構成は古いゲートウェイから新しいゲートウェイに移行されます。両方のゲートウェイが同時に実行され、中断が最小限に抑えられますが、接続の中断が短時間発生する可能性があります。
移行後、古いゲートウェイとその接続が削除され、新しいゲートウェイに CreatedBy: GatewaySKUMigration というタグが付けられ、移行されたリソースとして識別されるため、削除しないでください。
サポートされている移行シナリオ
ガイド付き ExpressRoute ゲートウェイの移行エクスペリエンスにより、お客様は現在の SKU から同等以上の SKU に移行できます。 下位 SKU への移行 (ダウングレード) はサポートされていません。
VPN ゲートウェイと同じ仮想ネットワークに ExpressRoute ゲートウェイがデプロイされている場合は、ExpressRoute ゲートウェイ移行ツールを使用できます。 このプロセス中に、VPN Gateway トラフィックに予期される影響はありません。
Azure portal を使用して移行する方法について説明します。
PowerShell を使用して移行する方法について説明します。
信頼性と高可用性を強化するために、Az 対応 SKU に移行することをお勧めします。
新しいゲートウェイに移行する手順
- 検証: すべてのリソースが成功状態であることを確認します。 前提条件が満たされていない場合、検証は失敗し、移行を続行できません。
- 準備: Azure は新しい仮想ネットワーク ゲートウェイを作成し、 新しいパブリック IP を自動的に割り当てます。 新しいパブリック IP を割り当てて接続を再確立します。このプロセスには最大 45 分かかることがあります。新しいゲートウェイのカスタム名を指定することも、Azure は既定で元の名前に _migrated を追加します。 準備中、既存のゲートウェイは変更を防ぐためにロックされ、新しいゲートウェイと接続を 中止 および削除するオプションがあります。
Note
新しいゲートウェイは、既存のゲートウェイと同じリージョンに作成されます。 リージョンを変更するには、現在のゲートウェイを削除し、目的のリージョンに新しいゲートウェイを作成する必要があります。
- 移行: 古いゲートウェイから新しいゲートウェイにトラフィックを切り替えます。 この手順には最大 15 分かかる場合があり、接続が短時間中断される可能性があります。
- コミット: 元のゲートウェイとその接続を削除して、移行を完了します。 移行をキャンセルする必要がある場合は、最初に [移行 ] セクションの ラジオ ボタンを選択してトラフィックを元のゲートウェイに切り替え、[ 移行] をクリックし、最後に [ 中止 ] を選択して新しいゲートウェイとその接続を削除します。
Important
移行後、接続を検証して、すべてが期待どおりに機能していることを確認します。 準備手順の後に [中止 ] を選択すると、新しいゲートウェイと接続が削除されるため、古いゲートウェイに戻すことができます。
Limitations
ガイド付きゲートウェイの移行エクスペリエンスには、次の制限があります。
- ExpressRoute のみ: 移行ツールは 、ExpressRoute 仮想ネットワーク ゲートウェイ用に設計されています。 VPN ゲートウェイやその他の種類のゲートウェイはサポート されていません 。 - 同じ仮想ネットワーク要件: 移行は同じ 仮想ネットワーク内でのみサポートされます。 サブスクリプション間、リージョン間、またはクロスゲートウェイ型の移行 (VPN ゲートウェイ間など) はサポートされていません。
- ダウングレードなし: Az 対応 SKU から Az 対応 以外の SKU へのダウングレードはサポート されていません 。
- GatewaySubnet サイズ: 移行を続行するには、GatewaySubnet に /27 以上のプレフィックスが必要です。 詳細については、「サブネットの 複数のプレフィックスを作成する 」を参照してください。
- プライベート エンドポイント接続: ExpressRoute プライベート ピアリング経由で接続されたプライベート エンドポイント (PE) では、移行中 に接続の問題 が発生する可能性があります。 プライベート エンドポイントの接続に関するドキュメントで、これらの問題の軽減に関するガイダンスを参照してください。 プライベート エンドポイント接続。
- レガシ ゲートウェイ: 2017 以前 に作成または回線に接続された ExpressRoute ゲートウェイはサポートされていません。
- サポートされていない SKU: "既定" SKU を使用するゲートウェイは移行の対象ではありません。 ゲートウェイの移行の適格性を確認するには、Advisor 通知が必要です。
エラーのトラブルシューティングとベスト プラクティスの詳細については、「 ゲートウェイ移行のトラブルシューティング」を参照してください。
FAQ
GatewaySubnet に 2 番目のプレフィックスを追加するにはどうすればよいですか?
GatewaySubnet への複数のプレフィックスの追加は現在パブリック プレビュー段階であり、PowerShell 経由でのみサポートされています。 手順については、「 サブネットの複数のプレフィックスを作成する」を参照してください。
新しいゲートウェイの正常性を監視するにはどうすればよいですか?
新しいゲートウェイの監視は、古いゲートウェイの場合と同じです。 新しいゲートウェイは、独自のメトリックを持つ個別のリソースです。 移行中は、移行ツールを使用してトラフィック パターンを観察することもできます。
移行後に、既存の監視、アラート、顧客定義のメンテナンス期間、または診断設定が構成されている場合は、新しく作成されたゲートウェイでこれらを再構成する必要があります。
移行によってダウンタイムが発生しますか?
移行により、数分のダウンタイムが発生する可能性があります。 影響を最小限に抑えるために、メンテナンス期間中に移行を実行することを計画します。
新しいゲートウェイにコミットするまで、どのくらいの時間待機できますか?
移行の準備後にコミットするには、最大 15 日が必要です。 今回は、移行を終了する前に、接続を検証し、すべての要件が満たされていることを確認するために使用します。
ゲートウェイ SKU が移行の対象かどうかを確認するにはどうすればよいですか?
Azure Advisor は、ゲートウェイが対象であるか、移行が必要かどうかを通知します。 Azure portal で ExpressRoute ゲートウェイ リソースを確認することもできます。ゲートウェイが対象の場合は、ページの上部にバナーに 「ゾーン冗長 ExpressRoute ゲートウェイを実装する」というメッセージが表示されます。
移行後にゲートウェイがゾーン回復性を持つかどうかを検証するにはどうすればよいですか?
移行後にゲートウェイがゾーンの回復性を持つかどうかを確認するには:
- Azure Advisor を確認します。ゲートウェイにゾーン回復性がある場合は、ゾーン冗長ゲートウェイを推奨する Advisor アラートが表示されなくなります。
- リソース タグの確認: 移行されたゲートウェイには、ゾーン回復性の高いデプロイ モデルに移動されたことを示す既定のタグが
GatewaySKUMigration
ラベル付けされます。
これらのチェックにより、ゲートウェイのゾーン回復性が確認されます。
この変更をロールバックできますか?
はい。コミットされるまでです。 移行は、次の 4 つの主要な手順で構成されます。
検証 – ゲートウェイが移行の対象かどうかを確認します。 この段階で変更はありません。ロールバックするものはありません
準備 – 目的の構成で新しい仮想ネットワーク ゲートウェイを作成します。 手順 2. の後にプロセスを中止すると、新しいゲートウェイが削除されます。
移行 – 既存のゲートウェイから新しいゲートウェイに構成を転送します。必要に応じて、手順 3. の後で構成を既存のゲートウェイに戻すことができます。
コミット – 古いゲートウェイとその接続を使用停止にして、移行を完了します。 変更がコミットされると、ロールバックできなくなります。
移行中のトラフィックへの影響は何ですか? パケット損失やルーティングの中断はありますか?
移行プロセス中、トラフィックはシームレスに再ルーティングされます。 通常の条件下では、予想されるパケット損失やルーティングの中断はありません。
ゲートウェイの移行中に Basic SKU 回線のリージョン間接続が原因で準備手順が失敗した場合はどうすればよいですか?
Basic SKU 回線にリージョン間接続があるために準備手順が失敗した場合は、再試行する前にゲートウェイの移行を 中止 し、回線 SKU を アップグレード します。 この構成はサポートされておらず、回線 SKU がアップグレードされるまで移行は失敗し続けます。
次のステップ
- ゲートウェイ移行のトラブルシューティングで移行問題を解決する。
- Azure portal を使用して移行する方法について説明します。
- PowerShell を使用して移行する方法について説明します。