この記事では、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 にアップグレードしてください。
ゲートウェイ移行エクスペリエンス
ゲートウェイの移行エクスペリエンスを使用すると、同じ GatewaySubnet に 2 つ目の仮想ネットワーク ゲートウェイをデプロイでき、Azure によって新しいパブリック IP が自動的に割り当てられます。手動で IP を作成する必要はありません。構成は古いゲートウェイから新しいものに移行されますが、両方のゲートウェイが同時に実行されるため、中断は最小限に抑えられます。ただし、接続の中断が短時間発生する可能性はあります。
移行後、古いゲートウェイとその接続が削除され、新しいゲートウェイに CreatedBy: GatewaySKUMigration というタグが付けられ、移行されたリソースとして識別されるため、削除しないでください。
サポートされている移行シナリオ
ガイド付きの ExpressRoute ゲートウェイ移行エクスペリエンスを使用すると、現在の SKU から同等以上の SKU に移行できます。 下位 SKU (ダウングレード) への移行はサポートされていません。
VPN ゲートウェイと同じ仮想ネットワークに ExpressRoute ゲートウェイがデプロイされている場合は、ExpressRoute ゲートウェイ移行ツールを使用できます。 このプロセス中に、VPN Gateway トラフィックに予想される影響はありません。
Azure portal を使用して移行する方法について説明します。
PowerShell を使用して移行する方法について説明します。
信頼性と高可用性を強化するために、Az 対応 SKU に移行することをお勧めします。
ErGwScale (スケーラブル ゲートウェイ) への移行
ExpressRoute スケーラブル ゲートウェイ (ErGwScale) は、Azure 仮想ネットワークに柔軟で高帯域幅の接続を提供する新しい仮想ネットワーク ゲートウェイ SKU です。
Important
最大スケール ユニットが 1 の場合、最小スケール ユニットは 1 である必要があります。
最小スケール ユニットと最大スケール ユニットを設定することで、要件に従ってゲートウェイのスケーリングを構成できます。
- 固定サイズのゲートウェイを構成するには、 最小 スケール ユニットと 最大 スケール ユニットの両方を同じ値に設定します (たとえば、両方を 1 に設定し、両方を 20 に設定し、両方を 40 に設定します)。
- 自動スケールを有効にするには、 最小スケール ユニット を 2 以上に設定し、目的の 最大スケール ユニット (最大 40) を指定します。
これにより、ゲートウェイはワークロードの要件に基づいて自動的にスケーリングできます。
詳細については、「 スケーラブル ゲートウェイについて」を参照してください。
| Scenario | 最小スケール単位 | 最大スケールユニット | 自動スケールが有効になっていますか? |
|---|---|---|---|
| スケーリングを修正しました | 1 | 1 | いいえ |
| スケーリングを修正しました | 20 | 20 | いいえ |
| スケーリングを修正しました | 40 | 40 | いいえ |
| Autoscaling | 2 以上 | 最大 40 | イエス |
新しいゲートウェイに移行する手順
- 検証: すべてのリソースが成功状態であることを確認します。 前提条件が満たされていない場合、検証は失敗し、移行を続行できません。
- 準備: 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 通知が必要です。
- 互換性のない専用回線: ゲートウェイの移行は、仮想ネットワークに接続されている専用ハードウェア セキュリティ モジュール (HSM) では続行できません。 移行を続行するには、専用のハードウェア セキュリティ モジュール (HSM) の割り当てを解除します。 詳細なトラブルシューティング手順については、「 専用 HSM のトラブルシューティング」を参照してください。
エラーのトラブルシューティングとベスト プラクティスの詳細については、「 ゲートウェイ移行のトラブルシューティング」を参照してください。
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 を使用して移行する方法について説明します。