Azure の Public IP アドレス リソースには、Basic および Standard の 2 種類の SKU が用意されています。

Azure VPN Gatewayにおいては、環境によって Basic SKU の Public IP アドレスが利用されているケースがあります。

Basic SKU の Public IP アドレスは順次サービス終了が予定されているため、Basic SKU から Standard SKU へのマイグレーション作業が必要となります。

1. マイグレーションの対象となるGatewayの条件

マイグレーションの対象となるGatewayの条件は、下記の表のとおりです。

VPN Gatewayの SKU は、Azure ポータルで対象のGateway リソースを選択し、［概要］画面からご確認いただけます。

また、Public IP アドレスの SKU については、Public IP アドレスのリンクをクリックし、［概要］画面からご確認いただけます。

これらをご確認のうえ、ご利用中のGatewayがマイグレーション対象に該当するかをご確認ください。

2. マイグレーションの手順

2-1. マイグレーションの流れ - 検証

実際のマイグレーション作業の流れについてご案内いたします。

マイグレーションは、「検証」「準備」「移行」「コミット」の 4 つのステップで進行します。

マイグレーション ツール画面を開くには、Azure ポータルで対象の VPN Gateway Gateway リソースを選択し、［構成］→［Migrate to Standard IP］をクリックしてください。

移行ツールを開くと、自動的に構成の検証が実行されます。

問題がなければ「Succeeded」と表示され、「検証」は完了となります。

2-2. マイグレーションの流れ - 準備

次に［Prepare］をクリックすると、マイグレーションの準備が開始され、移行先の VPN Gatewayが作成されます。

このステップの完了にはおおよそ 30 分程度かかりますが、本ステップ中に通信影響は発生しません。

準備が完了すると、次のステップである［Migrate］および［Abort］が表示されます。

なお、P2S 接続に “cloudapp.net” で終わる FQDN を使用して VPN Gatewayへ接続されている場合は、準備完了後に [VPN クライアントのダウンロード] を選択し、

更新された VPN クライアント プロファイル（ZIP ファイル）をダウンロードしてください。

その後、ダウンロードしたプロファイルを使用して再接続を行い、ポイント対サイト（P2S）接続が可能であることを確認してください。

*(※ご利用中の VPN Gatewayが対象であるかどうかの確認方法は Gatewayでレガシ DNS が使用されているかどうかを確認する をご参照ください。

2-3. マイグレーションの流れ - 移行

次のステップは「Migration」です。
この段階で作業をキャンセルする場合は、［Abort］をクリックしてください。

これにより、準備ステップで作成されたリソースが削除され、作業開始前の状態に戻ります。

作業を進める場合は、［Migration］をクリックします。

本ステップにて、実際の Public IP アドレスの SKU 移行作業が実行され、最大で約 5 分程度の通信断が発生する可能性があります。

※移行を行っている途中で VPNGateway の状態が Failed で表示されることがございますが、完了時には Succeeded に変わりますのでご安心ください。

なお、SKU を変更しても、VPN Gatewayで使用されている Public IP アドレス自体は変更されませんのでご安心ください。

移行が完了すると、最後のステップとして［Commit］および［Abort］のボタンが表示されます。

ツール上には新しいGatewayでのトラフィック処理状況が表示されますので、トラフィックが正常に流れていることをご確認ください。

（※ P2S 接続のみの環境ではトラフィック処理状況は表示されないため、クライアントから移行後の VPN Gatewayへ P2S 接続が可能か確認してください。）

万一、問題が確認された場合は、［Abort］を選択することで作業前の状態に戻すことが可能です。

2-4. マイグレーションの流れ - コミット

トラフィックが正常に流れていることを確認できましたら、［Commit］をクリックしてください。

なお、［Commit］実行後は切り戻しができませんので、ご注意ください。

このステップでは、移行により不要となったリソースのクリーンアップ処理が実行されます。

本処理にはおよそ 15 分程度かかります。

［Commit］が完了すると、VPN Gatewayで使用されている Public IP アドレスの SKU が Standard に変更され、マイグレーション作業は完了となります。

3. まとめ

VPN Gatewayで Basic SKU の Public IP アドレスを使用している場合のマイグレーション手順についてご紹介しました。

本マイグレーション作業は、すべて Azure Portalから実行可能です。

公式ドキュメントには、より詳細な情報や補足事項も記載されていますので、作業を実施される前にあわせてご確認ください。

Basic SKU パブリック IP アドレスを VPN Gateway 用に Standard SKU に移行する方法

Note

2026 年 3 月現在、本記事で解説している方法は EnableApplicationGatewayNetworkIsolation 機能が有効化された Application Gateway には使用できず、以下のエラーが発生することを確認しています。

Cannot change Application Gateway's GatewayIpConfiguration '/subscriptions/<subscriptionName>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/applicationGateways/<applicationGatewayName>/gatewayIPConfigurations/<gatewayIPConfigName>' subnet property '/subscriptions/<subscriptionName>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<virtualNetworkName>/subnets/<subnetName>' when the gateway is enabled with NetworkIsolation.

EnableApplicationGatewayNetworkIsolation 機能は、Application Gateway v2 でプライベート デプロイを利用する際に有効化が必要な機能です。この機能をサブスクリプションに登録すると、それ以降に作成したすべての Application Gateway v2 で NetworkIsolation が有効化されます。

NetworkIsolation が有効化された Application Gateway v2 ではサブネットの変更はできませんので、上述のエラーが発生した場合は Application Gateway v2 を再作成してください。

こんにちは、Azure テクニカル サポート チームの薄井です。
今回は Application Gateway V1 および V2 でサブネットを変更する方法についてご紹介します。

残念ながら現在の Azure ポータルからは、すでにデプロイした Application Gateway のサブネットを後から変更することはできません。
サブネットを変更する必要性が生じたら、新しく Application Gateway を作り直すしかありません。

しかし Azure PowerShell を使うことで、 Application Gateway を作り直すことなく、既存のサブネットの設定を変更することができます。

サブネット変更方法

※ 弊社検証環境でも動作の確認を行っておりますが念のため、お客様環境におかれましても事前に検証環境で動作をご確認のうえ本番環境への適用をお願いいたします。

※ Application Gateway のフロントエンド IP 構成において、プライベート IP アドレスが固定で設定されている場合は、プライベート IP アドレスと関連するリスナー設定等を削除しておく必要があります。

1. あらかじめ同一 VNET 内に変更先の新しいサブネットを作成しておきます。

2. Azure PowerShell または ポータルより Cloud Shell を起動し、以下のコマンドレットを入力します。（<>の部分は環境に合わせて変更が必要となります）

3. 構成を変更する対象のサブスクリプションを指定します。

1

Select-AzSubscription -SubscriptionId <サブスクリプション ID>

4. 構成を変更する対象の仮想ネットワークを指定します。

1

$VNet = Get-AzVirtualNetwork -Name <対象の仮想ネットワーク> -ResourceGroupName <変更対象のリソースグループ>

5. 変更先のサブネットを取得します。

1

$Subnet = Get-AzVirtualNetworkSubnetConfig -Name <変更先のサブネット名> -VirtualNetwork $VNet

 
4. 変更対象の Application Gateway を取得します。

1

$gw=Get-AzApplicationGateway -name <変更対象の Application Gateway 名> -ResourceGroupName <変更対象のリソースグループ>

5. サブネットの変更を加えます。

1

$gw2=Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $gw -Name "appGatewayIpConfig" -Subnet $Subnet

6. 稼働中の Application Gateway を停止します。※ 停止に数分かかります

1

Stop-AzApplicationGateway -ApplicationGateway $gw

7. Application Gatewayを設定、開始します。※ 開始に 10 分以上かかります

1

Set-AzApplicationGateway -ApplicationGateway $gw2

8. 開始後に以前と同様に Web サーバへアクセスできるか確認します。

以上、ご参考になれば幸いです。

その他の Application Gateway のサブネットに関連する情報

Application Gateway のサブネットについて関連する情報が以下のページにあります。
併せてご参考いただければと思います。

• アプリケーション ゲートウェイ構成の概要 > サブネットのサイズ
• アプリケーション ゲートウェイ構成の概要 > アプリケーション ゲートウェイ サブネット上のネットワーク セキュリティ グループ
• Application Gateway に関してよく寄せられる質問

本記事では、Application Gateway V1 SKU から V2 SKU への移行に関するよくあるお問い合わせについてご紹介します。

なお、Application Gateway V1 につきましては、2026 年 4 月 28 日にリタイアすることが決まっております。この日以降、ご利用の Application Gateway V1のリソースはすべて停止される見込みとなります。
つきましては、期日までに計画的に Application Gateway V2 への移行をご実施いただけますよう、何卒お早めにご検討をいただけますと幸いでございます。

Application Gateway V2 への移行のガイドはこちらをご参照ください。

目次

• 移行スクリプトに関するよくあるお問い合わせ

  • 移行スクリプトを使用してプライベートのフロントエンド IP のみを構成する Application Gateway V2 に移行可能か
  • 移行スクリプトを実行中にサブネット delegation エラーが表示される
  • プライベート Application Gateway 利用時に PublicIpResourceId は不要か
  • 拡張複製スクリプトと従来スクリプトの違い
  • V1 と V2 の証明書設定の違いについて
  • 移行時の WAF 構成について
  • 作成される WAF ポリシーの CRS バージョンとアップグレード可否
  • バックエンドサーバーを V1/V2 両方に関連付けても問題ないか
  • 移行スクリプト実行中に V1 の設定変更が可能か
  • 移行スクリプト実行中にバックエンドサーバーを変更してよいか
  • 移行スクリプト実行中の通信影響について

• トラフィックの移行に関するよくあるお問い合わせ

  • DNS 切り替え後に完全に V2 へ切り替わるまでの時間
  • V1 と V2 の並行稼働は可能か
  • 移行後に V2 を経由していることを確認する方法

• V1 と V2 の仕様差分に関するよくあるお問い合わせ

  • V1 と V2 の機能差分について
  • NSG/UDR など通信要件の違いについて
  • V2 の推奨サブネットサイズについて
  • 停止時の課金の違い

• その他

  • V1 と同じプライベート IP を V2 で利用できるか
  • V1 から V2 への料金比較方法

移行スクリプトに関するよくあるお問い合わせ

移行スクリプトを使用してプライベートのフロントエンド IP のみを構成する Application Gateway V2 に移行することは可能ですか？

A. はい、可能です。
Application Gateway V2 のフロントエンド IP アドレスをプライベートのみとする構成は
プライベート Application Gateway と呼ばれ、事前に以下の作業を行うことでご利用いただけます。

• 事前にサブスクリプションに対してプレビュー機能で EnableApplicationGatewayNetworkIsolation を有効化する。

• 事前にプライベート Application Gateway (V2) をデプロイするサブネットに Microsoft.Network/applicationGateways の委任設定を追加する。

詳細はこちらの公開技術情報をご確認ください。
※ EnableApplicationGatewayNetworkIsolation 機能はお客様に任意で登録いただく機能のため、サブスクリプションの [プレビュー機能] のページに配置されておりますが、プライベート デプロイ機能自体はすでに GA (General Availability) 済みの機能です。

移行スクリプトを実行中に「 Application Gateway deployments must have subnet delegation configured to Microsoft.Network/applicationGateways」というエラーが表示されました。どうすればいいですか？

A.
サブスクリプションに対して EnableApplicationGatewayNetworkIsolation 機能を有効化した状態で V2 を作成する場合、フロントエンド IP アドレスがパブリック IP のみ関連づいているか、プライベート IP のみ関連づいているかを問わず、移行先のサブネットで「Microsoft.Network/applicationGateways」へのサブネット委任の設定が必要となります。

そのため、移行スクリプト実行前に V2 を作成予定のサブネットに対してサブネットの委任の設定をすることで回避できます。なお、移行元の V1 のサブネットではサブネット委任の設定は必要ございません。

プライベート Application Gateway を利用する場合、「拡張複製スクリプト」（AzureAppGWClone.ps1）のパラメーターにある PublicIpResourceId は記載不要でしょうか？

A.
はい、「拡張複製スクリプト」のパラメーター「PublicIpResourceId」については、省略可能なパラメーターであり、プライベート Application Gatewayとしてご利用いただく場合、このパラメーターは不要です。

「拡張複製スクリプト」（AzureAppGWClone.ps1）と「従来の複製スクリプト」（AzureAppGWMigration.ps1）の違いは何でしょうか？

A.
拡張複製スクリプトでは以下の対応が可能となりました。

• パブリック IP アドレスの取り扱い：
  プライベート Application Gateway 環境の移行にあたりパブリック IP アドレスを一時的に付与する必要がなくなりました。
  （従来の複製スクリプトでは作成時に一時的にパブリック IP アドレスを付与、作成後に手動で削除する必要がありました）

- HTTPS リスナーで利用する TLS 証明書の取り扱い：従来の複製スクリプトで必須であった TLS 証明書の手動指定が不要となりました。拡張複製スクリプトでは既存の V1 環境にアップロードされている TLS 証明書が自動で V2 環境に反映される動作になりました。

- HTTP 設定で利用するバックエンド接続用の信頼されたルート証明書の取り扱い：Application Gateway とバックエンド サーバー間を HTTPS で通信し、かつ自己署名証明書のように、既知の証明書認証局から発行されていないサーバー証明書をバックエンド側で利用している場合、V2 では HTTP 設定の箇所でルート証明書をアップロードする必要があり、従来の移行スクリプト実行時に明示的に指定する必要がありました。先日 Application Gateway V2 とバックエンド サーバー間を HTTPS で通信する構成において、[証明書の検証をスキップさせる機能](https://learn.microsoft.com/ja-jp/azure/application-gateway/configuration-http-settings?tabs=backendhttpsettings#backend-https-validation-settings)が登場しました。拡張複製スクリプトではこの機能に対応しているため、バックエンド用の証明書を手動指定する必要がなくなりました。

「拡張複製スクリプト」（AzureAppGWClone.ps1）を用いて Application Gateway V1 から V2 へ移行したところ、Application Gateway V1 ではバックエンド設定の証明書設定にて認証証明書が設定されていましたが、Application Gateway V2 では、該当の設定が見当たりません。V1/V2 で同じ設定となっているのでしょうか？

A.
Application Gateway V1 では認証証明書そのものをバックエンド設定に登録する構成であったのに対して、V2 では信頼されたルート証明書を登録する構成に変更になりました。
このため、Application Gateway V1 と V2 では以下の通り証明書検証の動作が異なります。

• V1 の提供終了に関する FAQ

Application Gateway での証明書検証の動作

V1 SKU - Application Gateway V1 は認証証明書を使用します。 このメカニズムは、Application Gateway で構成された証明書と、バックエンド サーバーによって提示される証明書との完全一致を実行します。 さらに、V1 では、TLS ハンドシェイク中にサーバー名表示 (SNI) を使用できない場合は、既定またはフォールバック証明書の使用がサポートされます。

V2 SKU - 既定では、Application Gateway V2 はより包括的な検証を実行します。 完全な証明書チェーンと、バックエンド サーバー証明書のサブジェクト名が検証されます。詳細情報

また、V1 と V2 の証明書検証動作の互換性を維持するため、拡張複製スクリプトを実行した後の Application Gateway V2 では、バックエンド サーバー側の証明書チェーン、有効期限、SNI などの検証が無効化された状態となっています。これは拡張複製スクリプトを用いて Application Gateway を移行した際の想定された動作です。
バックエンド サーバーから提示される証明書の検証が必要な場合には、Application Gateway V2 への移行後、改めて、バックエンド設定へルート証明書をアップロードくださいますようお願いいたします。

• Azure Application Gateway と Web Application Firewall を V1 から V2 に移行する
  ※ 「1. 拡張複製スクリプト」の “推奨事項” の箇所をご参照ください。

  ・このスクリプトは、複製中に既定でバックエンド TLS 検証を緩和します (証明書チェーン、有効期限、SNI 検証なし)。 より厳密な TLS 検証または認証証明書が必要な場合、お客様は Application Gateway V2 の作成後に更新して、信頼されたルート証明書を追加し、要件に従ってこの機能を有効にすることができます。

移行スクリプトを実行して Application Gateway V1 をV2 に移行した場合、WAF はどのように構成されるでしょうか？

A.
Application Gateway V2 の WAF 設定には現在以下の ２種類の管理方式があります。

• 従来の WAF 構成： WAF ポリシーを利用せず、Application Gateway リソース自体に WAF 設定を保持する方式（V1 はこの方式のみ対応しています。）
• WAF ポリシー構成： 専用リソースとして WAF ポリシーを作成し、Application Gateway に関連付ける方式

移行スクリプトを実行して Application Gateway V2 を作成した場合、WAF ポリシー構成として作成されます。このとき V1 で設定していた構成を元にした WAF ポリシーが自動で作成され 、Application Gateway に関連付けられます。

「拡張複製スクリプト」（AzureAppGWClone.ps1）を使用した場合、スクリプトで作成された WAF ポリシーには既定のルールセット として CRS 3.0 が設定されていますがアップグレードする必要はあるでしょうか？

A.
はい、CRS 3.0 は 2027 年 2 月 26 日までサポートされておりますが、お早めにアップデートをご検討ください。WAF ポリシーのアップグレード手順に関しましては、以下の公式ドキュメントを参考にしていただければ幸いです。

• CRS または DRS ルールセットのバージョンをアップグレードする

なお、今回のように古いバージョンから最新のバージョンへルールセットを変更する場合、マネージド ルールの内容も最新のセキュリティ状況に即した内容にアップデートされます。

そのため、診断ログを有効にしたうえで、まずは「検知モード」でしばらくご利用いただき、お客様にて診断ログをご確認後、誤検知がある場合はルールの無効化等でチューニングをご実施いただいたえで、「防止モード」への変更をされることを推奨いたします。

WAF のチューニングにつきましては、以下のブログ記事もご参照いただけますと幸いでございます。

• Application Gateway WAF の誤検知対応

Application Gateway V2 を作成した時点で、バックエンドサーバーが Application Gateway V1 および V2 の両方に関連付けられる構成となりますが、バックエンド サーバーが複数のバックエンドプールへ関連付けられていても問題はないでしょうか？

A.
はい、1 つのバックエンド サーバーを、V1 および V2 の両方の Application Gateway のバックエンド プールとして指定することは問題ございません。

移行スクリプト実行中に移行元の Application Gateway V1に対して設定変更や再起動などを行うことは可能でしょうか？

A.
移行スクリプト実行中には、移行元の Application Gateway V1 に対して操作を行うことは推奨されません。公式ドキュメントにも下記の通り記載がございます。

• V1 から V2 に移行する - 注意事項

移行中は、V1 ゲートウェイまたは関連付けられているリソースに対して他の操作を試みないでください。

移行スクリプト実行中に移行元の Application Gateway V1に関連付けされているバックエンド サーバーに対して設定変更や再起動などを行うことは可能でしょうか？

A.
移行スクリプト実行中にバックエンド サーバー側の設定変更や再起動を実施しても、移行への影響は想定されませんが、予期せぬ問題を防ぐ意味合いでも、移行スクリプト実行中の操作は控えていただくことをお勧めいたします。

移行スクリプト実行中に通信影響はあるでしょうか？

A.
いいえ。「拡張複製スクリプト」および「従来の複製スクリプト」の実行中に通信影響はございません。また、移行スクリプトを実行中も、移行元の Application Gateway V1 を経由してバックエンド サーバーに通信することが可能ですのでご安心ください。

トラフィックの移行に関するよくあるお問い合わせ

DNS レコードの更新で通信を切り替える場合、DNS の設定を変更してから Application Gateway V2 経由での通信に完全に切り替わるまでどの程度の時間がかかるでしょうか？

A.
切り替わるまでの時間につきましては DNS レコードの TTL に大きく依存いたしますが、明確な目安などはございません。切り替わり時間は TTL 値 ＋ マージンが必要とご理解いただけますようお願いいたします。

• V1 から V2 に移行する - Traffic Migrationに関する推奨事項

Standard V1 または WAF V1 ゲートウェイに (A レコードを使って) 関連付けられているフロントエンド IP アドレスを指すカスタム DNS ゾーン (例: contoso.com)。 Standard_V2 アプリケーション ゲートウェイに関連付けられているフロントエンド IP または DNS ラベルを指すように、DNS レコードを更新できます。 DNS レコードに構成されている TTL によっては、すべてのクライアント トラフィックが新しい V2 ゲートウェイに移行するまでに時間がかかる場合があります。

なお、DNS 切り替えの際、Application Gateway V1・V2 がともに稼働している状態であれば、トラフィック移行中でも継続して Application Gateway からサービスが提供されますので基本的には通信影響はございません。

ただし、お客様のバックエンド アプリケーションにおいてセッション管理を行っている場合、セッション維持の実装方法によってはトラフィックの移行時に通信影響が発生することがありますので、十分な検証のうえ移行作業を進めていただくことをお勧めします。

トラフィックを移行するまでの間、Application Gateway V1 と V2 のリソースを並行稼働できるでしょうか？

A.
はい、Azure の観点では Application Gateway V1 と V2 のリソースを並行稼働することに問題はございません。トラフィックを移行するまでの間は Application Gateway V1 を経由してバックエンド サーバーに通信が行われます。

トラフィックを移行した後、通信が Application Gateway V2 を経由していることを確認できるでしょうか？

A.
はい、診断ログを有効にした上でアクセス ログをご確認いただくことで、通信が Application Gateway V2 を経由していることを確認できます。
なお、Application Gateway V1 で診断ログを有効にしていても、移行スクリプトを実行するだけでは Application Gateway V2 で診断ログは有効になりませんため、個別に設定を追加いただく必要があります。
診断ログの設定方法に関しましては、以下の公式ドキュメントを参考にしていただければ幸いです。

• 診断ログ - Azure portal を使用してログを有効にする

V1 と V2 の仕様差分に関するよくあるお問い合わせ

Application Gateway V1 と V2 の機能の差分はありますか？

A.
こちらのドキュメントに V1 と V2 で利用できる機能の差異についてまとめられておりますのでご確認ください。

Application Gateway V1 と Application Gateway V2 の通信要件(NSG/ UDR) の違いはあるでしょうか？

A.
Application Gateway V1 と Application Gateway V2 では、 Azure 基盤サービスとの通信要件や、NSG/UDR の要件が一部異なります。そのため、NSG や UDR による通信制御を行っている環境では、V2 への移行時に設定の見直しが必要となる場合があります。

NSG につきまして、 基盤サービス（GatewayManager）との通信で使用されるポート範囲が SKU ごとに異なります。詳細については、以下の公開ドキュメントをご参照ください。

• Azure Application Gateway インフラストラクチャの構成 - ネットワーク セキュリティ グループ

インフラストラクチャ ポート: GatewayManager サービス タグと “任意” の宛先として、ソースからの受信要求を許可します。 宛先ポートの範囲は、SKU によって異なります。これは、バックエンド正常性の状態を通信するために必要です。 これらのポートは、Azure 証明書によって保護 (ロックダウン) されます。 適切な証明書が設定されていない外部エンティティは、そのようなエンドポイントに対する変更を開始できません。

V2: ポート 65200 から 65535
V1: ポート 65503 から 65534

UDR につきまして、 V1 では、エンド ツー エンドの通信経路が維持されることを前提として、Application Gateway サブネットに UDR を設定する構成がサポートされています。
一方で V2 では、すべての管理/コントロール プレーン トラフィックが、仮想アプライアンス経由ではなく、インターネットに直接送信されるようにする必要があり、0.0.0.0/0 トラフィックをインターネットに向けるよう設定する必要があります。(お客様でご利用中の個別のアドレス プレフィックス宛のルートを設定いただく分には問題ございません)

• Azure Application Gateway インフラストラクチャの構成 - サポートされているユーザー定義ルート

v1: v1 SKU の場合、UDR は、エンド ツー エンドの要求/応答の通信が変更されなければ、Application Gateway サブネットでサポートされます。 たとえば、パケットの検査のためにファイアウォール アプライアンスを指すように Application Gateway サブネットの UDR を設定できます。 ただし、検査後にパケットが目的の宛先に到達できることを確認する必要があります。 これに失敗すると、不適切な正常性プローブやトラフィック ルーティング動作が発生する場合があります。 これには仮想ネットワークの Azure ExpressRoute や VPN ゲートウェイによってプロパゲートされる学習済みのルートまたは既定の 0.0.0.0/0 ルートが含まれます。

v2: v2 SKU の場合、サポートされるシナリオとサポートされないシナリオがあります。

なお、プライベート Application Gateway の場合は、NSG と UDR の通信要件が緩和されております。詳細については以下のドキュメントをご確認ください。

• プライベート アプリケーション ゲートウェイのデプロイ

Application Gateway V1の最小サブネット サイズは /26 でしたが Application Gateway V2で推奨のサブネット サイズはあるでしょうか？

A.
Application Gateway V2 は、インスタンスを最大 125 までスケール アウトすることが可能です。そのため、最大 131 個の IP アドレス (※) が必要となり、/24 のサブネット サイズを推奨しております。
※ 125 のインスタンス IP アドレス + 1 つのプライベート フロントエンド IP 構成 + 5 つの Azure 予約 IP アドレス

なお、お客様環境のご要件にてインスタンスのスケール アウトが最大 125 まで必要とされない場合、スケール アウトする最大インスタンス数の上限を決めることで、サブネット サイズを調整いただくことは可能ですが、拡張性を考慮して /24 のサブネット サイズでデプロイいただくことを強くお勧めいたします。

• Azure Application Gateway インフラストラクチャの構成 - 仮想ネットワークと専用サブネット

Application Gateway V1 と V2 を停止した際に、課金の差異はあるでしょうか？

A.
V2 につきましては、Application Gateway 自体の固定コスト/容量ユニットコスト/データ転送はすべて課金されなくなりますが、パブリック IP アドレスの課金は停止中も発生します。
V1 につきましては、関連付けているパブリック IP アドレスを含めすべての課金が停止いたします。

その他

Application Gateway V2 のフロントエンド IP として Application Gateway V1 で利用していたプライベート IP アドレスを設定することは可能でしょうか？

A.
Application Gateway V1 と Application Gateway V2 を同じサブネットに共存させることは叶いませんため、Application Gateway V1 を先に削除いただき、Application Gateway V2 を作成する際に Application Gateway V1 で使用していたプライベート IP アドレスを設定することで設定が可能です。

Application Gateway V1 から V2 への移行に向けて、料金差分を確認したいです。大まかな料金を確認したいのですが、どのように計算したらよいでしょうか？

A.
Application Gateway の V1 と V2 では料金体系が大きく異なっております。
V1 では、インスタンス数とインスタンスのサイズに基づく固定料金と、処理データ量に応じた従量課金が発生します。

一方で、V2 では、従来のインスタンス単位ではなく、利用状況に応じて課金される消費ベースのモデルへと切り替わっており、容量ユニット コスト使用状況に応じて料金が変動する仕組みとなっています。詳細については、以下の公開ドキュメントをご参照ください。

• Azure Application Gateway と Web Application Firewall の価格について

料金差分を確認される際には、以下の料金計算ツール上で V1 に相当する「Basic V1」と V2 の「Standard v2」をそれぞれ選択し、現在ご利用中のトラフィック量や接続数に合わせて試算いただくことになります。
V1 と V2 は料金構造そのものが異なるため、単純にインスタンス数を並べて比較するのではなく、利用量をもとに試算していただくことが必要となります。

• 料金計算ツール

以上、Application Gateway V1 SKU から V2 SKU への移行に関するよくあるお問い合わせについてご紹介しました。移行のご参考になれば幸いです。

※ V1 のリタイアについて詳しくはこちら

今回のブログでは Application Gateway V1 と V2 で HTTP/2 を取り扱う際の動作の違いについてご紹介します。皆様のご参考になりましたら幸いです。

HTTP/2（Hypertext Transfer Protocol version 2）は、ウェブ ページのデータをウェブ サーバーから取得するための新しい通信方法です。
HTTP/1.1 の後継として、2015 年に正式な仕様として承認されました。HTTP/2 には、「h2」と「h2c」の二つの識別子があります。HTTP/2 の接続が確立される際にトランスポート層セキュリティ（TLS) が利用されたかどうかによって、HTTP/2 通信には「h2」または「h2c」識別子が表示されます。つまり、HTTP/2 の識別子を通じて、HTTP/2 通信が暗号化されているかどうかを判断することができます。

・識別子が “h2” となっている場合、それは HTTP/2 通信が TLS を使用するプロトコルであることを示しています。

・識別子が “h2c” となっている場合、HTTP/2 通信が TLS を使用しません。この際、クライアントは HTTP/2 通信に “Upgrade” ヘッダーと “HTTP2-Settings” ヘッダーを送信します。”Upgrade” ヘッダーの値は「h2c」が設定され、”HTTP2-Settings” ヘッダーの値はトークン（例: AAMAAABkAAQCAAAAAAIAAAAA）が設定されます。

HTTP/2 の関連記事 (英語)

The “h2c” string was previously used as a token for use in the HTTP Upgrade mechanism’s Upgrade header field. This usage was never widely deployed and is deprecated by this document. The same applies to the HTTP2-Settings header field, which was used with the upgrade to “h2c”.

現在、Edge や Chrome など現在主要なブラウザーでは、HTTP/2 over TLS (h2) のみが HTTP/2 として使用できます。

例えば、www.microsoft.com のサイトは HTTP/2 に対応していますが、 www.microsoft.com に HTTPS ではなく HTTP で接続する場合、
ブラウザーが HTTP/2 over TCP (h2c) をサポートしていないため、HTTP/2 は使用されず、HTTP/1.1 で接続を確立します。
(以下のスクリーンショットの例ではその後 HTTPS の URL にリダイレクトされ、HTTP/2 over TLS (h2)で接続しています。)

なお、ブラウザからのアクセスではなく、curl コマンドなどの他の HTTP クライアントから HTTP リクエストを送信する際には、HTTP/2 over TCP (h2c) を利用して HTTP/2 通信が行われる可能性があります。この状況では、Application Gateway が接続先となる際に、v1 と v2 で動作が異なります。v1 の場合、HTTP/2 通信はダウングレードされて、v2 の場合は HTTP ステータスコード 403 が応答されます。詳細の動作つきましては、以下のセクションをご参照ください。

Application Gateway の HTTP2 サポートについて

Application Gateway はリバース プロキシとして動作するため、フロントエンド接続（クライアント - Application Gateway）とバックエンド接続（Application Gateway - バックエンド サーバー）の二つの接続が発生します。現在、バックエンド接続における HTTP/2 はサポートされておりません。

フロントエンド接続における HTTP/2 のサポート状況については、リスナーで利用しているプロトコルによって異なります。詳細は以下のテーブルをご参照いただけますと幸いです。

一般的なシナリオとして、HTTP/2 over TLS (h2) が使用されるため、Application Gateway でも HTTP/2 over TLS (h2) のみを考慮しています。そのため、Application Gateway では、HTTPS リスナーでのみ HTTP/2 をサポートしています。v1、v2 ともに HTTP リスナーでは HTTP/2 の通信をサポートしていませんが、HTTP リスナーに対して実際にクライアントから HTTP/2 通信を送信する際には、SKU によって動作が異なります。以下にそれぞれの SKU の動作について紹介します。

v1 の動作

v1 の HTTP リスナーに HTTP/2 を用いて送信すると、通信がダウングレードされ、Application Gateway は HTTP/1.1 でレスポンスを送信します。

v1 の HTTP リスナーに HTTP/2 リクエストを curl コマンドで送信した結果

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

root:/# curl -v http://<v1 Appgw の IP> --http2
*   Trying xxxxxx:80...
* Connected to xxxx port 80 (#0)
> GET / HTTP/1.1
> Host: xxxxxx
> User-Agent: curl/7.81.0
> Accept: */*
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c
> HTTP2-Settings: AAMAAABkAAQCAAAAAAIAAAAA
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Wed, 25 Dec 2024 09:09:10 GMT
< Content-Type: text/html
< Content-Length: 7
< Connection: keep-alive
< Server: Microsoft-IIS/10.0

v2 の動作

v2 の場合は、HTTP リスナーに HTTP/2 を送信すると、Application Gateway はクライアントに 403 を応答します。

v2 の HTTP リスナーに HTTP/2 リクエストを curl コマンドで送信した結果

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

root: curl --http2 -v -k http://<v2 Appgw の IP>
*   Trying xxxx:80...
* Connected to xxxx (xxxx) port 80 (#0)
> GET / HTTP/1.1
> Host: xxxx
> User-Agent: curl/7.81.0
> Accept: */*
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c
> HTTP2-Settings: AAMAAABkAAQCAAAAAAIAAAAA
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< Server: Microsoft-Azure-Application-Gateway/v2
< Date: Wed, 25 Dec 2024 08:51:52 GMT
< Content-Type: text/html
< Content-Length: 179
< Connection: keep-alive
<
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>Microsoft-Azure-Application-Gateway/v2</center>
</body>
</html>
* Connection #0 to host xxxx left intact

上記の HTTP リスナーに HTTP/2 を送信した通信結果を、Application Gateway で設定可能な診断ログの 1 つであるアクセス ログから対象の通信結果を確認すると、「httpStatus」のプロパティには 403 が記載され、「serverStatus」のプロパティには 403 以外の別のステータスコードが記載されます。こちらは想定されているログの記録結果です。

また、このブロックは Application Gateway V2 自体のコード レベルでの動作であり、WAF を利用していない場合でも同様に HTTP 403 を返す動作となります。つまり、Application Gateway v2 は WAF の利用の有無にかかわらず HTTP リスナーで受け取った HTTP/2 通信をブロックすることが想定された動作となります。

Virtual WAN の相互接続性について

Virtual WAN は仮想ハブというコンポーネントを中心としており、この仮想ハブに対して様々な環境を接続することができます。
仮想ハブに対して接続する主な環境は、仮想ネットワークと、ブランチと呼ばれるオンプレミス環境です。
この “ブランチ” については、Virtual WAN 内の仮想ハブに接続するオンプレミス環境をまとめた総称であり、具体的な接続パターンは以下の様なものがあります。

• サイト間 VPN (S2S VPN)
• ポイント対サイトユーザー VPN (P2S VPN)
• ExpressRoute

※ その他、仮想ハブと Vnet 上の仮想アプライアンス間で直接 BGP ピアを構成したり、仮想ハブ上に所定のパートナーが提供するアプライアンス製品やサービスをデプロイし SD-WAN 環境を構成するといったことも可能ですが、今回の記事ではよくご利用いただく、仮想ネットワークとブランチ (サイト間 VPN、ポイント対サイト VPN、ExpressRoute) 接続のパターンにフォーカスしたいと思います。

Virtual WAN では、仮想ネットワークやブランチを仮想ハブに接続することで、複雑な操作を伴わずにそれぞれの環境間を相互接続させるということをコンセプトにしております。
上述したような仮想ネットワーク/ブランチ (サイト間 VPN、ポイント対サイト VPN、ExpressRoute) の接続については、一部条件付きのケースもございますが、基本的に Virtual WAN によって相互接続させることが可能です。
Virtual WAN の相互接続性については、以下の公式ドキュメントにも言及がありますので、併せてご参照ください。

(参考)
グローバル トランジット ネットワーク アーキテクチャと Virtual WAN

各接続パターンについて

Virtual WAN 環境と仮想ネットワーク環境における相互接続性の差をわかりやすく示すため、まずは概要として簡単な表を以下に記載しております。

この表では、縦軸と横軸に記載された環境間での相互接続可否を示しており、記号はそれぞれ以下の意味を表します。

• 〇については相互接続が可能となるよう構成可能
• ×については相互接続が可能となる構成が非サポート
• △については相互接続可能となるよう構成可能であるが、特定のオプションや別サービスの利用が伴うため考慮が必要

※ 本記事では詳細な構成及び設定の方法については割愛いたしますが、〇と表記しているケースでも構成によっては相互接続が可能とならないケースもある点ご了承ください。

また、縦軸と横軸において省略して記載している各表記は、以下を示しております。

• VNet = 仮想ネットワーク環境
• S2S = サイト間 VPN で接続されたオンプレミス拠点
• P2S = ポイント対サイト VPN で接続されたクライアント端末
• ExpressRoute = ExpressRoute 回線で接続されたオンプレミス拠点

仮想ネットワーク環境の場合

Virtual WAN 環境の場合

以下では、各接続パターンにおいてどのような相互接続が可能となるか、通常の仮想ネットワーク環境とも比較しながらもう少し詳しく見ていこうと思います。

S2S to S2S

仮想ハブ上の VPN ゲートウェイには複数のサイト間 VPN を接続可能ですが、サイト間 VPN で接続された拠点同士で相互接続ができるように構成することが可能です。

従来の仮想ネットワーク環境でも、同様に複数のサイト間 VPN で接続された拠点間の相互接続 (トランジット接続) ができるように構成することが可能です。

(参考)
VPN Gateway に関する FAQ - Azure VPN Gateway では、BGP トランジット ルーティングをサポートしていますか。

P2S to S2S

ポイント対サイトユーザー VPN のクライアントから、サイト間 VPN の接続先拠点にアクセスすることが可能です。

従来の仮想ネットワーク環境でも、ポイント対サイト VPN のクライアントからサイト間 VPN の接続先拠点にアクセスできるよう構成することは可能です。

(ご参考)
ポイント対サイト VPN ルーティングについて
※ ポイント対サイトユーザー VPN で利用するプロトコルや、接続端末の OS 種別によっては、カスタムルートの構成やゲスト OS 内でのルート設定といった追加作業が必要になる場合もございます。

S2S to ExpressRoute

このシナリオは、通常の仮想ネットワーク環境と比較し、Virtual WAN 環境で容易に構成できることが大きな特徴です。
まず、Virtual WAN 環境では、サイト間 VPN と ExpressRoute 回線を仮想ハブに接続するのみで、相互に疎通させることが可能です。

従来の仮想ネットワーク環境でも、サイト間 VPN と ExpressRoute 用の仮想ネットワークゲートウェイを同じ仮想ネットワークに共存させて同時にオンプレミス拠点と接続することはできますが、既定の構成のままでは各拠点間の相互接続を行うことはできません。
仮想ネットワーク環境でサイト間 VPN と ExpressRoute に接続された拠点間でトランジット通信を実現したい場合、Azure Route Server という別のリソースを追加で構成し、各仮想ネットワークゲートウェイと BGP による経路交換を行う必要があります。

(参考)
ExpressRoute と Azure VPN に対する Azure Route Server のサポート

このように、通常の仮想ネットワーク環境では更に別のサービスを構成してトランジット通信を実現する必要があるほか、VPN 用仮想ネットワークゲートウェイの構成やパラメーター、ゲートウェイサブネットのサイズ等に一定の制約が生じるなど、様々な考慮事項が生じます。
Virtual WAN 環境では上記のような別リソースの構成は伴わず、仮想ハブ上のゲートウェイにサイト間 VPN と ExpressRoute 回線の接続を構成すれば、基本的には既定の構成で拠点間の相互通信を実現することができます。

P2S to ExpressRoute

OpenVPN プロトコルで接続したポイント対サイトユーザー VPN のクライアントから、ExpressRoute の接続先拠点にアクセスすることも可能です。

従来の仮想ネットワーク環境では、前述の Azure Route Server を利用したとしても、P2S VPN の接続クライアントから ExprsesRoute 接続先拠点へのトランジット接続は非サポートとなります。

(参考)Azure Route Server に関してよく寄せられる質問 (FAQ)

ExpressRoute to ExpressRoute

複数の ExpressRoute 回線で接続された拠点間のトランジット通信は、Virtual WAN 環境であっても既定の状態では不可能です。
以下のうちいずれかのオプション機能を利用することで、実現が可能となります。

• Global Reach の利用 (仮想ハブを経由することなく各 ExpressRoute 回線間で直接トラフィックが転送されます)
• プライベート ルーティング ポリシーの有効化(仮想ハブに Azure Firewall を伴う、セキュリティ保護付き仮想ハブの利用が必要となります。また、有効化の際にサポートリクエストによる依頼が必要となります。)

(参考)
ルーティング インテントを使用した ExpressRoute 回線間のトランジット接続

従来の仮想ネットワーク環境でも同様に、既定の状態では複数の ExpressRoute 回線で接続された拠点間のトランジット通信ができません。
実現する場合には、Global Reach を利用する必要がございます。

VNet to Branch (S2S, P2S, ExpressRoute)

Virtual WAN 環境では、仮想ネットワーク環境と各ブランチ (サイト間、ポイント対サイト、ExpressRoute) で接続された環境間の疎通が可能です。

同様に、従来の仮想ネットワーク環境でも、サイト間、ポイント対サイト、ExpressRoute で接続された環境との通信は可能です。
複数の仮想ネットワークを接続する場合は、ハブ用の仮想ネットワークを用意して各スポークと VNet ピアリングを構成した上で、ゲートウェイ転送オプションを有効化しておく必要がございます。
Virtual WAN 環境であれば、仮想ハブに複数の仮想ネットワークを順次接続していけば、自動的にブランチ環境との接続性を確保することができます。

VNet to VNet

Virtual WAN 環境では、仮想ハブに接続した仮想ネットワーク同士の疎通も可能です。
たくさんの仮想ネットワーク間で相互接続性を確保したい時には、それぞれの仮想ネットワークを仮想ハブに接続していくことで、自動的に相互通信ができるようになります。

従来の仮想ネットワーク環境では、複数の仮想ネットワーク間は基本的に VNet ピアリングによって接続します。
もちろん、VNet ピアリングによって仮想ネットワーク間の通信は可能となりますが、VNet ピアリングでは基本的に直接ピアリングした先の仮想ネットワークにしかアクセスすることができません。
相互接続したい仮想ネットワークの数が多くなる場合、メッシュ状に VNet ピアリングを構成するか、ハブ用の仮想ネットワークを用意してルーティング用の NVA を配置するといった対処が必要となります。

おわりに

この記事では、Virtual WAN 環境における各環境間の相互接続についてご紹介いたしました。
通常の仮想ネットワーク環境を用いるパターンと比較しますと、実現できることの違いや、同じようなトラフィックフローが実現できたとしても構成の難度や複雑性が異なってくる点がご理解いただけたのではないかと思います。
Virtual WAN 環境の利用をご検討いただく一助となれば幸いです。

目次

• はじめに - セキュリティ保護付き仮想ハブとは -
• セキュリティ保護付き仮想ハブをご利用いただくメリット
• ルーティング インテントとルーティング ポリシーの構成方法について
• ルーティング インテントとルーティング ポリシーを構成した後の通信確認例
• 最後に

はじめに - セキュリティ保護付き仮想ハブとは -

Virtual WAN においては、上述したとおり複数の接続間で通信が可能となる反面、例えば、

• ある Vnet は他の Vnet とは接続させたいがブランチとは接続させたくない
• ある Vnet は他の Vnet とは接続させたくないがブランチとは接続したい

といった、お互いに接続したい要件と接続させたくない要件が両立する場合など、仮想ハブを介した接続同士で通信制御を行いたい場合は考慮が必要となります。
また、各接続からインターネットに接続するにあたり、一度 Azure Firewall を経由させることで、通信のフィルターを行いたい、というご要件もあるかと存じます。

上述したようなご要件に対応する方法として、Virtual WAN をご利用いただき、かつ仮想ハブとしてセキュリティ保護付き仮想ハブをご利用いただけます。
セキュリティ保護付き仮想ハブとは、ハブとスポークの構成を提供する仮想ハブとしての機能に加え、Azure Firewall の機能、
および Azure Firewall や Network Virtual Appliance (NVA) を経由するためのルーティング機能がセットになっている仮想ハブとなります。

セキュリティ保護付き仮想ハブを用いた構成例

ひとつの Virtual WAN に一つのセキュリティ保護付き仮想ハブのみをご利用いただく場合、以下のような接続形態を提供します。
なお、複数の仮想ハブをまたがる構成においてご利用いただくことも可能ですが、ここでは一つのセキュリティ保護付き仮想ハブのみをご利用いただいている場合を例にご説明します。

構成例 1. プライベートな通信間を Azure Firewall にてフィルター

以下のような接続形態になります。

(各接続) - (仮想ハブ内の Azure Firewall) - (各接続)

■構成例 1 の図

具体的には、以下のような各通信が該当します。
・仮想ネットワーク間の接続 (V2V)
・ブランチ間の接続 (B2B)
・ブランチと仮想ネットワーク (B2V)

構成例 2. インターネットへの通信を Azure Firewall にてフィルター

以下のような接続形態になります。

(各接続) - (仮想ハブ内の Azure Firewall) - (インターネット)

■構成例 2 の図

具体的には、以下の通信が該当します。
・仮想ネットワークからインターネットに向けた接続 (V2I)
・ブランチからインターネットに向けた通信において Azure Firewall を通したい場合 (B2I) (*ご参考)

(*ご参考)
こちらの構成は、以下弊サポート発行 Blog の項目「1）Virtual WAN を利用する」に記載がございますのでご参考になさってください。
オンプレミスからのインターネット宛ての通信を Azure 経由にする方法

セキュリティ保護付き仮想ハブをご利用いただくメリット

上記のような接続形態は、セキュリティ保護付き仮想ハブをご利用いただかない Virtual WAN、または Virtual WAN そのものをご使用いただかなくても、ご要件次第ではありますが実現可能です。
では、セキュリティ保護付き仮想ハブをご利用いただくメリットは何か、というと、
一つ一つの接続に対してルーティングを独自に設定する必要がない、という点が挙げられます。

セキュリティ保護付き仮想ハブをご利用いただく際、ルーティング インテントとルーティング ポリシーを構成いただくことで、ルーティング制御も自動的に行われます。
この構成時にご指定いただくのは、仮想ハブがひとつの構成においては

・プライベート トラフィックを保護するか (上記 <形態 1> が該当します)
・インターネット トラフィックを保護するか (上記 <形態 2> が該当します)

のいずれかとなりますが、この際にルーティングをお客様で別途設定いただく必要はなく、ルーティングの制御も含めて自動的に行われます。
もし、ルーティング インテントとルーティング ポリシーをご利用いただかない場合、Azure Firewall で保護したい通信はすべてお客様でルーティングの設定をしていただくことになり、構成次第では複雑な制御が必要になり、また接続が増える等の要件変更のたびに設定が必要となります。

ルーティング インテントとルーティング ポリシーの構成方法について

ルーティング インテントとルーティング ポリシーの構成方法としては二通りの方法があり、Azure portal を介して、Virtual WAN ポータルまたは Azure Firewall Manager を使って構成できます。
仮想ハブ内に Azure Firewall をデプロイされている場合、どちらで実施いただいても同等となります。

Azure Firewall が仮想ハブにデプロイされている環境において、Virtual WAN ポータルからプライベート トラフィックを構成する際の図例は以下となります。
対象の仮想ハブを選択し、[ルーティング] の [ルーティング ポリシー] を選択し、[プライベート トラフィック] で [Azure Firewall]、[ネクスト ホップ リソース] で、当該の Azure Firewall のリソースを選択します。

■Virtual WAN ポータルからの構成図例

上記、Virtual WAN ポータルからの構成後に Azure Firewall Manager を確認すると、プライベート トラフィックが Azure Firewall を経由する構成となっていることがわかります。(Send via Azure Firewall)
併せて、仮想ハブ間 (Inter-hub) の通信も Azure Firewall を経由することがわかります。

■Azure Firewall Manager における表示例

ルーティング インテントとルーティング ポリシーを構成した後の通信確認例

試しに Vnet 間の通信を行ってみると、仮想ハブ内の Azure Firewall を経由していることがわかります。
仮想ハブ内の Azure Firewall を経由していることの確認方法は何点か考えられますが、Azure Firewall の診断ログを確認いただけます。
ログを確認するには、事前に診断ログを記録するように設定いただく必要はございますが、運用管理上の観点からも推奨となります。

■診断ログ確認画面例

最後に

今回は、Virtual WAN をご利用いただき Any to Any の接続を実現しつつ、かつ Azure Firewall を経由させて通信のフィルターを実現するにあたってのセキュリティ保護付き仮想ハブの概要、およびルーティング インテントとルーティング ポリシーについてご説明いたしました。
今回は概要ご説明のため、比較的簡易な仮想ハブ 1 つの構成についてご説明いたしましたが、さらに複雑な構成を含む、ルーティング インテントとルーティング ポリシーについての詳細は以下公開文書をご確認ください。

Virtual WAN ハブのルーティング インテントとルーティング ポリシーの構成方法

こんにちは、Azure テクニカル サポート チームです。
この記事では Azure VirtualWAN を効果的に利用いただくためのアイデアをご提供させていただきます。

VWAN はハブ＆スポーク VNET 構成を手軽にかつ、大規模に実現することができるサービスです。
複数の仮想ネットワークをハブ＆スポークで接続するだけでなく、 ExpressRoute や Site-to-Site 接続によるオンプレミス接続、Point-to-Site 接続によるクライアントアクセスだけでなく、Azure Firewall や NVA を配置する等の高機能を提供することもできる、 Azure Network の最終形のようなサービスです。

VWAN は高機能で様々なユースケースに対応することができる柔軟性がある反面、機能面、設定面が複雑でわかりにくいというご意見もございました。今回のドキュメントでは、シンプルな構成であっても VWAN を有効に活用できるケースをご紹介いたします。

1.1 VWAN アーキテクチャと特徴

VWAN standard は１つ以上の仮想ハブ( vHUB ) を含みます。vHUB を作成すると内部的に仮想ネットワークと vHUB ルータが配置されます。その他、必要に応じて以下のリソースを配置して機能を拡張することができ、オンプレミスサイトへの接続や、セキュリティソリューションを vHUB 内にデプロイが可能です。

1. ExpressRoute ゲートウェイ
2. Site-to-Site ゲートウェイ
3. Point-to-Site ゲートウェイ
4. Azure Firewall ( 以降 AzFW )
5. NVA ( Network Virtual Appliance )

vHUB は複数作成することができ、vHUB には VM などリソースを配置されたスポークVNET を接続します。同一 vHUB に接続する異なる VNET 上のリソースは vHUB ルータ経由で通信することができます ( VNet 間のトランジット接続 )

また、 同一 VWAN リソース内の vHUB リソース同士はデフォルト状態で接続されており、明示的な設定なしに異なる vHUB に接続するスポーク VNET 上のリソース間で通信ができます。

VWAN を活用することで簡単に実現できる構成例
１．VNET ハブ＆スポーク構成
通常、VNET でハブ＆スポーク 構成ではハブ VNET に AzFWもしくは NVA を配置し、スポーク VNET 側では UDR を設定する必要がありますが、設定・管理の手間が発生いたします。
VWAN を使用する場合には vHUB がハブ VNET + AzFW/NVA の代わりとなるため、簡単かつシンプルにハブ&スポーク構成を実現できます。

2. VWAN 活用例

2.1 大規模 VNET 構成例

一般的に複数 VNET 間で通信が必要になる環境では、 VNET 間をメッシュで VNET Peering するか、ハブ＆スポーク構成をとる必要があります。
しかしながら、どちらの方法でも設定工数が多く、また VNET 追加が発生した場合の作業が多いなど設定管理面で課題があります。

構成 1. VNET をフルメッシュで VNET Peering する

課題点 VNET ピアリング数が多く、新たに VNET を追加する場合にも設定工数がかかる

構成 2. ハブ VNET を作成して AzFW, NVA を配置し、ハブ＆スポーク構成を作る

課題点 ハブ VNET 上に AzFW, NVA が必須となり、またスポークVNET 側にはそれぞれユーザ定義ルートを設定、管理する必要がある

VirtualWAN を使用することでこれらの課題点を解決し、シンプルな運用が可能です。
VirtualWAN ( Standard SKU ) では標準で仮想ハブに仮想ハブルータが配置されるため、ユーザが AzFW, NVA を仮想ハブに配置する必要がなく、
またスポーク VNET にユーザ定義ルート設定も不要であるため、 VNET 数が多い環境への対応も容易です。

2.2. ExpressRoute, Site-to-Site, Point-to-Site 間のトランジットルーティング

非 VirtualWAN 環境でも 1 VNET に ExpressRoute GW, VPNGW を配置し、 ExpressRoute, サイト間接続, ポイント対サイト接続することができますが、
ExpressRoute, サイト間接続/ポイント対サイト接続の相互接続( トランジット接続 ) はできません。
Azure Route Server を追加することで ExpressRoute ⇔ サイト間接続の相互接続は可能になりますが、それでも ExpressRoute ⇔ ポイント対サイト間の接続はできません。

ご参考. ExpressRoute と Azure VPN のサポート - Azure Route Server

2.3. スポーク VNET 間、オンプレミスサイト間の通信を強制的に AzFW 経由させる

しばしば通信セキュリティ要件として、オンプレミスサイトと VNET 間の通信や、VNET 間の通信を AzFW を経由させたい、という要件がございます。
非 VirtualWAN 環境でもハブ＆スポーク VNET 構成を組むことで、通信をハブ VNET 上の AzFW を経由させることは可能ではありますが、
前述の通り、 スポーク VNET にユーザ定義ルート設定が必要になり煩雑な運用が発生いたします。

VirtualWAN では、セキュリティ付き仮想ハブ機能を有効にするだけで、
仮想ハブ上に AzFW や、その他認定された NVA を配置することができます

ご参考. セキュリティ保護付き仮想ハブとは

2.4 複数リージョンにまたがる大規模 VNET 構成

VirtualWAN を使用しない場合、複数ハブ VNET を接続・運用する際のルーティング設計は非常に難しくなります。
一方、VirtualWAN では複数 vHUB を配置することができ、ハブ間を簡単に自動で接続する機能が標準で準備されております。
これにより、 VirtualWAN ユーザーはスポーク VNET やハブ VNET のルーティングを意識することなく、スポークVNET間の通信が行えます。
vHUB はどのリージョンにも配置することができ、ハブごとにゲートウェイを配置することが可能です。
これにより下記２つのメリットが期待できます。

• オンプレミスサイトとの通信品質の改善
  オンプレミスサイトとの通信でも、地理的に近いリージョンの vHUB に接続ポイントを設けることで通信遅延を低減が可能です。

• リージョン障害への耐性向上
  リージョン障害が発生し　vHUB の一つが支障した場合でも別リージョン　vHUB がオンプレミスサイトへの接続を持っていれば、
  自動的に通信が迂回し、サービス継続させることができます。
  例としては vHUB A, B, C が存在し、vHUB C 配下にスポーク VNET C が接続。vHUB A, B がオンプレミスサイトへの接続を持っている構成を想定します。
  このとき vHUB A が大規模障害により停止した場合でも、スポーク VNET C は vHUB B 経由でオンプレイスサイトとの通信を継続できます。

3. まとめ

この記事では VirtualWAN を使用するだけで簡単に実現ができる構成についてご紹介をいたしました。
VirtualWAN は高機能なサービスではございますが、シンプルに使用するだけでも強力なソリューションとなります。
今後、ご活用の機会がありましたらご検討をお願いいたします。