次の方法で共有

Azure Application Gateway と Web Application Firewall を V1 から V2 に移行する

  • [アーティクル]

Application Gateway V1 SKU (Standard と WAF) は 2023 年 4 月 28 日に非推奨になったことが発表されました。 V1 SKU は、2026 年 4 月 28 日に廃止されます。 詳細については、「2026 年 4 月 28 日までに Application Gateway を V1 SKU から V2 SKU に移行する」を参照してください。

Azure Application Gateway と Web Application Firewall (WAF) V2 では、V1 と比較して、自動スケーリング、可用性、ゾーン冗長、パフォーマンスの向上、操作の高速化、スループットの向上などの追加機能が提供されるようになりました。 また、すべての新機能は V2 SKU 用にリリースされます。 今すぐ移行計画を作成することを強くお勧めします。

V1 ゲートウェイは、V2 に自動的にアップグレードされません。 この移行ガイドは、移行の計画と実行に役立ちます。

移行には、次の 2 つの段階があります。

  1. 構成の移行
  2. クライアント トラフィックの移行

この記事は、主に構成の移行に役立ちます。 クライアント トラフィックの移行は、環境によって異なります。 この記事では、いくつかの一般的な推奨事項について説明します。

前提条件

  • アクティブなサブスクリプションが含まれる Azure アカウント。 無料でアカウントを作成できます。
  • 既存の Application Gateway V1 Standard。
  • 最新の Azure PowerShell モジュールがあることを確認してください。ポータルで Azure Cloud Shell を使用することもできます。
  • PowerShell をローカルで実行している場合、Connect-AzAccount を実行して Azure との接続を作成することも必要です。
  • V1 サブスクリプションに、AppGW V2 名とリソース グループ名が指定された既存の Application Gateway がないことを確認します。 これにより、既存のリソースが書き換えられます。
  • パブリック IP を指定する場合は、それが正常な状態であることを確認します。 それを指定せず、AppGWResourceGroupName を指定する場合は、AppGWV2Name-IP という名前のパブリック IP リソースが、V1 サブスクリプションの AppGWResourceGroupName という名前のリソース グループに存在しないことを確認します。
  • V1 SKU の場合、バックエンド サーバーとの TLS 接続を設定するには認証証明書が必要です。 V2 SKU では、同じ目的に対し信頼されたルート証明書をアップロードする必要があります。 V1 では認証証明書として自己署名証明書を使用できます。V2 では、自己署名証明書がバックエンドで使用されている場合には、自己署名ルート証明書の作成とアップロードが義務付けられています。
  • 移行中に、V1 ゲートウェイまたは関連リソースで他の操作が計画されていないことを確認します。

Azure Cloud Shell

Azure では、ブラウザーを介して使用できる対話型のシェル環境、Azure Cloud Shell がホストされています。 Cloud Shell で Bash または PowerShell を使用して、Azure サービスを操作できます。 ローカル環境に何もインストールしなくても、Cloud Shell にプレインストールされているコマンドを使用して、この記事のコードを実行できます。

Azure Cloud Shell を開始するには、以下のようにします。

オプション 例とリンク
コードまたはコマンド ブロックの右上隅にある [使ってみる] を選択します。 [使ってみる] を選択しても、コードまたはコマンドは Cloud Shell に自動的にはコピーされません。 Azure Cloud Shell の [使ってみる] の例を示すスクリーンショット。
https://shell.azure.com に移動するか、[Cloud Shell を起動する] ボタンを選択して、ブラウザーで Cloud Shell を開きます。 Azure Cloud Shell を起動するボタン。
Azure portal の右上にあるメニュー バーの [Cloud Shell] ボタンを選択します。 Azure portal の [Cloud Shell] ボタンを示すスクリーンショット

Azure Cloud Shell を使用するには、以下のようにします。

  1. Cloud Shell を開始します。

  2. コード ブロック (またはコマンド ブロック) の [コピー] ボタンを選択し、コードまたはコマンドをコピーします。

  3. Windows と Linux では Ctrl+Shift+V キーを選択し、macOS では Cmd+Shift+V キーを選択して、コードまたはコマンドを Cloud Shell セッションに貼り付けます。

  4. Enter キーを選択して、コードまたはコマンドを実行します。

注意

Azure を操作するには、Azure Az PowerShell モジュールを使用することをお勧めします。 作業を始めるには、「Azure PowerShell をインストールする」を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

重要

移行スクリプトを実行する前に、毎回 Set-AzContext -Subscription <V1 application gateway SubscriptionId> コマンドレットを実行します。 移行スクリプトは既存のリソース グループが現在のサブスクリプション コンテキストに存在しない場合はそれをクリーンアップする可能性があるので、アクティブな Azure コンテキストを適切なサブスクリプションに設定するために、これを行う必要があります。 バージョン 1.0.11 以降の移行スクリプトでは、このステップは必須ではありません。

重要

利用可能になった移行スクリプトの新しい安定バージョン 1.0.11 には、重要なバグ修正と更新プログラムが含まれています。潜在的な問題を回避するため、このバージョンを使ってください。

構成の移行

このドキュメントでは、Azure PowerShell スクリプトを提供します。 構成に役立つ次の操作が、それによって実行されます。

  • 指定した仮想ネットワーク サブネットに、新しい Standard_V2 または WAF_V2 ゲートウェイを作成します。
  • V1 Standard または WAF ゲートウェイに関連付けられている構成を、新しく作成した Standard_V2 または WAF_V2 ゲートウェイにシームレスにコピーします。

スクリプトのダウンロード

移行スクリプトは、PowerShell ギャラリーからダウンロードできます。移行スクリプトの新しい安定版リリース (バージョン 1.0.11) を利用でき、これには主要な更新プログラムとバグ修正が含まれています。 この安定バージョンを使用することをお勧めします。

スクリプトの使用

Note

移行スクリプトを実行する前に、毎回 Set-AzContext -Subscription <V1 application gateway SubscriptionId> コマンドレットを実行します。 移行スクリプトは既存のリソース グループが現在のサブスクリプション コンテキストに存在しない場合はそれをクリーンアップする可能性があるので、アクティブな Azure コンテキストを適切なサブスクリプションに設定するために、これを行う必要があります。 バージョン 1.0.11 以降の移行スクリプトでは、このステップは必須ではありません。

ローカルの PowerShell 環境のセットアップと設定に応じて、次の 2 つのオプションがあります。

  • Azure Az モジュールがインストールされていない場合、または Azure Az モジュールをアンインストールしてもかまわない場合、最善の方法は Install-Script オプションを使用してスクリプトを実行することです。
  • Azure Az モジュールを保持する必要がある場合は、スクリプトをダウンロードして直接実行するのが最善の方法です。

Azure Az モジュールがインストールされているかどうかを確認するには、Get-InstalledModule -Name az を実行します。 インストールされている Az モジュールが見つからなかった場合は、Install-Script メソッドを使用できます。

このオプションを使用するには、コンピューターに Azure Az モジュールがインストールされていないことが必要です。 インストールされている場合、次のコマンドにはエラーが表示されます。 Azure Az モジュールをアンインストールするか、もう 1 つのオプションであるスクリプトを手動でダウンロードして実行する方法を使用します。

次のコマンドを使用してスクリプトを実行し、最新バージョンを取得します。

Install-Script -Name AzureAppGWMigration -Force

このコマンドでは、必要な Az モジュールもインストールされます。

スクリプトを使用して直接インストールする

何らかの Azure Az モジュールがインストールされていて、それらをアンインストールできない (またはアンインストールしたくない) 場合は、スクリプトのダウンロード リンクの [Manual Download] (手動ダウンロード) タブを使って、手動でスクリプトをダウンロードできます。 スクリプトは、生の nupkg ファイルとしてダウンロードされます。 この nupkg ファイルからスクリプトをインストールするには、「パッケージの手動ダウンロード」を参照してください。

バージョン 1.0.11 は移行スクリプトの新しいバージョンであり、主要なバグ修正が含まれています。 この安定バージョンを使用することをお勧めします。

ダウンロードしたスクリプトのバージョンを調べる方法

ダウンロードしたスクリプトのバージョンを調べる手順は次のとおりです。

  • NuGet パッケージの内容を抽出します。
  • フォルダー内の .PS1 ファイルを開き、先頭にある .VERSION を調べて、ダウンロードしたスクリプトのバージョンを確認します
<#PSScriptInfo
.VERSION 1.0.10
.GUID be3b84b4-e9c5-46fb-a050-699c68e16119
.AUTHOR Microsoft Corporation
.COMPANYNAME Microsoft Corporation
.COPYRIGHT Microsoft Corporation. All rights reserved.

スクリプトを実行する方法

スクリプトを実行するには、次の手順を実行します。

  1. Connect-AzAccount を使用して Azure に接続します。

  2. Import-Module Az を使用して Az モジュールをインポートします。

  3. Set-AzContext コマンドレットを実行して、アクティブな Azure コンテキストを適切なサブスクリプションに設定します。 移行スクリプトは、既存のリソース グループが現在のサブスクリプション コンテキストに存在しない場合、それをクリーンアップする可能性があるので、これは重要なステップです。

    Set-AzContext -Subscription '<V1 application gateway SubscriptionId>'

  4. Get-Help AzureAppGWMigration.ps1 を実行して必要なパラメーターを調べます。

    AzureAppGWMigration.ps1
 -resourceId <V1 application gateway Resource ID>
 -subnetAddressRange <subnet space you want to use>
 -appgwName <string to use to append>
 -AppGWResourceGroupName <resource group name you want to use>
 -sslCertificates <comma-separated SSLCert objects as above>
 -trustedRootCertificates <comma-separated Trusted Root Cert objects as above>
 -privateIpAddress <private IP string>
 -publicIpResourceId <public IP name string>
 -validateMigration -enableAutoScale

Note

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

スクリプトのパラメーターは次のとおりです。

  • resourceId: [String]: 必須: このパラメーターは、既存の Standard V1 または WAF V1 ゲートウェイの Azure リソース ID です。 この文字列の値を調べるには、Azure portal に移動し、アプリケーション ゲートウェイまたは WAF リソース選択して、ゲートウェイの [プロパティ] リンクをクリックします。 そのページにリソース ID があります。

    次の Azure PowerShell コマンドを実行してリソース ID を取得することもできます。

    $appgw = Get-AzApplicationGateway -Name <V1 gateway name> -ResourceGroupName <resource group Name>
$appgw.Id

  • subnetAddressRange: [String]: 必須: このパラメーターは、新しい V2 ゲートウェイを含む新しいサブネットに割り当てた (または割り当てる) IP アドレス空間です。 アドレス空間は、CIDR 表記で指定する必要があります。 例: 10.0.0.0/24。 このサブネットを事前に作成する必要はありませんが、CIDR は VNET のアドレス空間の一部である必要があります。 存在しない場合は、スクリプトによって作成されます。存在する場合は、既存のものが使われます (サブネットが空であるか、V2 ゲートウェイだけが含まれ、使用可能な IP が十分にあることを確認してください)。

  • appgwName: [String]: 省略可能. これは、新しい Standard_V2 または WAF_V2 ゲートウェイの名前として使うように指定する文字列です。 このパラメーターが指定されていない場合、既存の V1 ゲートウェイの名前にサフィックス _V2 を付加したものが使われます。

  • AppGWResourceGroupName: [String]: 省略可能。 V2 Application Gateway リソースを作成するリソースグループの名前 (既定値は <V1-app-gw-rgname> です)

Note

V1 サブスクリプションに、AppGW V2 名とリソース グループ名が指定された既存の Application Gateway がないことを確認します。 これにより、既存のリソースが書き換えられます。

  • sslCertificates: [PSApplicationGatewaySslCertificate]: 省略可能. V1 ゲートウェイの TLS/SSL 証明書を表すために作成する PSApplicationGatewaySslCertificate オブジェクトのコンマ区切りの一覧を、新しい V2 ゲートウェイにアップロードする必要があります。 Standard V1 または WAF V1 ゲートウェイ用に構成された TLS/SSL 証明書ごとに、次に示す New-AzApplicationGatewaySslCertificate コマンドを使って、新しい PSApplicationGatewaySslCertificate オブジェクトを作成できます。 TLS または SSL 証明書ファイルへのパスとパスワードが必要です。

    このパラメーターは、V1 ゲートウェイまたは WAF 用に構成された HTTPS リスナーがない場合にのみ省略できます。 HTTPS リスナーのセットアップが少なくとも 1 つある場合、このパラメーターを指定する必要があります。

    $password = ConvertTo-SecureString <cert-password> -AsPlainText -Force
$mySslCert1 = New-AzApplicationGatewaySslCertificate -Name "Cert01" `
  -CertificateFile <Cert-File-Path-1> `
  -Password $password
$mySslCert2 = New-AzApplicationGatewaySslCertificate -Name "Cert02" `
  -CertificateFile <Cert-File-Path-2> `
  -Password $password

    スクリプトでは前の例の $mySslCert1, $mySslCert2 (コンマ区切り) をこのパラメーターの値として渡すことができます。

  • Key Vault からの sslCertificates: 省略可能。 Azure Key Vault に格納されている証明書をダウンロードして、移行スクリプトに渡すことができます。 証明書を PFX ファイルとしてダウンロードするには、次のコマンドを実行します。 これらのコマンドは、SecretId にアクセスし、内容を PFX ファイルとして保存します。

     $vaultName = ConvertTo-SecureString <kv-name> -AsPlainText -Force
 $certificateName = ConvertTo-SecureString <cert-name> -AsPlainText -Force
 $password = ConvertTo-SecureString <password> -AsPlainText -Force

 $pfxSecret = Get-AzKeyVaultSecret -VaultName $vaultName -Name $certificateName -AsPlainText
 $secretByte = [Convert]::FromBase64String($pfxSecret)
 $x509Cert = New-Object Security.Cryptography.X509Certificates.X509Certificate2
 $x509Cert.Import($secretByte, $null, [Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable)
 $pfxFileByte = $x509Cert.Export([Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12, $password)

 # Write to a file
 [IO.File]::WriteAllBytes("KeyVaultcertificate.pfx", $pfxFileByte)

    Key Vault からダウンロードした証明書ごとに、次に示す New-AzApplicationGatewaySslCertificate コマンドを使って、新しい PSApplicationGatewaySslCertificate オブジェクトを作成できます。 TLS または SSL 証明書ファイルへのパスとパスワードが必要です。

    //Convert the downloaded certificate to SSL object
$password = ConvertTo-SecureString  <password> -AsPlainText -Force 
$cert = New-AzApplicationGatewaySSLCertificate -Name <certname> -CertificateFile <Cert-File-Path-1> -Password $password

  • trustedRootCertificates: [PSApplicationGatewayTrustedRootCertificate]: 省略可能. v2 ゲートウェイのバックエンド インスタンスの認証用の信頼されたルート証明書を表すために作成する、PSApplicationGatewayTrustedRootCertificate オブジェクトのコンマ区切りの一覧です。

    $certFilePath = ".\rootCA.cer"
$trustedCert = New-AzApplicationGatewayTrustedRootCertificate -Name "trustedCert1" -CertificateFile $certFilePath

    PSApplicationGatewayTrustedRootCertificate オブジェクトの一覧を作成するには、「New-AzApplicationGatewayTrustedRootCertificate」を参照してください。

  • privateIpAddress: [String]: 省略可能. 新しい V2 ゲートウェイに関連付ける特定のプライベート IP アドレス。 これは、新しい V2 ゲートウェイに割り当てるのと同じ VNet のものである必要があります。 これが指定されていない場合は、スクリプトによって V2 ゲートウェイにプライベート IP アドレスが割り当てられます。

  • publicIpResourceId: [String]: 省略可能. 新しい V2 ゲートウェイに割り当てる、ご自分のサブスクリプション内の既存のパブリック IP アドレス (Standard SKU) リソースのリソース ID です。 パブリック IP リソース名が指定されている場合、それが正常な状態であることを確認します。 これが指定されていない場合、スクリプトによって同じリソース グループ内の新しいパブリック IP アドレスが割り当てられます。 名前は、V2 ゲートウェイの名前に -IP が付加されたものになります。 AppGWResourceGroupName を指定し、パブリック IP アドレスを指定しない場合、AppGWV2Name-IP という名前のパブリック IP リソースが、V1 サブスクリプションの AppGWResourceGroupName という名前のリソース グループに存在しないことを確認します。

  • validateMigration: [switch]: 省略可能. V2 ゲートウェイの作成と構成のコピーが完了した後に、スクリプトで基本的な構成比較検証を実行するには、このパラメーターを使用します。 既定では、検証は行われません。

  • enableAutoScale: [switch]: 省略可能. スクリプトで新しい V2 ゲートウェイを作成した後に自動スケールを有効にするには、このパラメーターを使用します。 既定では、自動スケーリングは無効です。 新しい V2 ゲートウェイを作成した後でいつでも、手動でこれを有効にできます。

  1. 適切なパラメーターを使用してスクリプトを実行します。 完了するまで 5 から 7 分かかることがあります。

    例

    AzureAppGWMigration.ps1 `
   -resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
   -subnetAddressRange 10.0.0.0/24 `
   -appgwname "MynewV2gw" `
   -AppGWResourceGroupName "MyResourceGroup" `
   -sslCertificates $mySslCert1,$mySslCert2 `
   -trustedRootCertificates $trustedCert `
   -privateIpAddress "10.0.0.1" `
   -publicIpResourceId "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
   -validateMigration -enableAutoScale

注意事項と制限事項

  • 新しい V2 ゲートウェイには、新しいパブリック IP アドレスとプライベート IP アドレスがあります。 既存の V1 ゲートウェイに関連付けられている IP アドレスを、V2 にシームレスに移動することはできません。 ただし、既存の (未割り当ての) パブリックまたはプライベート IP アドレスを、新しい V2 ゲートウェイに割り当てることはできます。
  • V1 ゲートウェイが配置されている仮想ネットワーク内の別のサブネットの IP アドレス空間を指定する必要があります。 スクリプトでは、V1 ゲートウェイが既に存在するサブネットに、V2 ゲートウェイを作成することはできません。 サブネットに V2 ゲートウェイが既にある場合、十分な IP アドレス空間を使用できれば、スクリプトは引き続き動作する可能性があります。
  • V2 ゲートウェイ サブネットに関連付けられているネットワーク セキュリティ グループまたはユーザー定義ルートがある場合は、移行を成功させるために、それらが NSG 要件と UDR要件に準拠していることを確認します
  • 仮想ネットワーク サービス エンドポイント ポリシーは現在、Application Gateway のサブネットではサポートされません。
  • TLS/SSL の構成を移行するには、V1 ゲートウェイで使われているすべての TLS/SSL 証明書を指定する必要があります。
  • V1 ゲートウェイで FIPS モードを有効にしている場合、それは新しい V2 ゲートウェイに移行されません。 FIPS モードは V2 ではサポートされません。
  • プライベート IP のみの V1 ゲートウェイがある場合は、スクリプトによって、新しい V2 ゲートウェイのプライベートおよびパブリック IP アドレスが生成されます。 プライベート IP のみの V2 ゲートウェイは、現在パブリック プレビュー段階です。 一般提供されるようになると、お客様はスクリプトを使って、そのプライベート IP のみの V1 ゲートウェイを、プライベート IP のみの V2 ゲートウェイに転送できます。
  • NTLM と Kerberos 認証は、Application Gateway V2 ではサポートされていません。 このスクリプトは、ゲートウェイがこの種類のトラフィックを処理しているかどうかを検出できず、実行されていると、V1 から V2 ゲートウェイへの破壊的変更のように処理する可能性があります。
  • WAFv2 は古い WAF 構成モードで作成されます。WAF ポリシーへの移行が必要です。

トラフィックの移行

まず、スクリプトによって、V1 ゲートウェイから移行された正確な構成で、V2 の新しいゲートウェイが正常に作成されたことを再確認します。 この確認は Azure portal から行うことができます。

また、手動テストとして少量のトラフィックを V2 ゲートウェイ経由で送信します。

次に示すのは、現在のアプリケーション ゲートウェイ (Standard) がクライアントのトラフィックを受信できるいくつかのシナリオと、それぞれに対する推奨事項です。

  • Standard V1 または WAF V1 ゲートウェイに (A レコードを使って) 関連付けられているフロントエンド IP アドレスを指すカスタム DNS ゾーン (例: contoso.com)。

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

  • (CNAME レコードを使用して) V1 ゲートウェイに関連付けられた DNS ラベル (例: myappgw.eastus.cloudapp.azure.com) を指すカスタム DNS ゾーン (例: contoso.com)。

    次の 2 つの選択肢があります。

    • アプリケーション ゲートウェイでパブリック IP アドレスを使っている場合は、Traffic Manager プロファイルを使って制御されたきめ細かい移行を行い、トラフィックを新しい V2 ゲートウェイに段階的にルーティングできます (重み付けによるトラフィック ルーティング方法)。

      これを行うには、V1 と V2 両方のアプリケーション ゲートウェイの DNS ラベルを Traffic Manager プロファイルに追加し、カスタム DNS レコード (例: www.contoso.com) を Traffic Manager ドメイン (例: contoso.trafficmanager.net) への CNAME します。

    • または、新しい V2 アプリケーション ゲートウェイの DNS ラベルを指すように、カスタム ドメインの DNS レコードを更新できます。 DNS レコードに構成されている TTL によっては、すべてのクライアント トラフィックが新しい V2 ゲートウェイに移行するまでに、時間がかかる場合があります。

  • クライアントがアプリケーション ゲートウェイのフロントエンド IP アドレスに接続する。

    新しく作成した V2 アプリケーション ゲートウェイに関連付けられている IP アドレスを使うように、クライアントを更新します。 IP アドレスを直接使用しないことをお勧めします。 独自のカスタム DNS ゾーン (例: contoso.com) に CNAME できる、アプリケーション ゲートウェイに関連付けられた DNS 名ラベル (例: yourgateway.eastus.cloudapp.azure.com) を使用することを検討してください。

価格に関する考慮事項

Application Gateway V1 SKU と V2 SKU では、価格モデルが異なります。 V2 は使用量に基づいて課金されます。 価格情報については、移行の前に「Application Gateway の価格」をご覧ください。

コスト効率のガイダンス

V2 SKU には、5 倍のパフォーマンス向上、Key Vault の統合によるセキュリティの強化、WAF_V2 でのセキュリティ規則の迅速な更新、WAF カスタム ルール、ポリシーの関連付け、ボット保護など、さまざまな利点があります。 また、高いスケーラビリティ、最適化されたトラフィック ルーティング、Azure サービスとのシームレスな統合も提供されます。 これらの機能により、全体的なユーザー エクスペリエンスを向上させ、トラフィックが多い時間帯の速度低下を防ぎ、高くつくデータ侵害を回避できます。

V1 SKU では、レベルとサイズに基づいて、Standard_Small、Standard_Medium、Standard_Large、WAF_Medium、WAF_Large の 5 つのバリエーションを利用できます。

SKU V1 固定月額 V2 固定月額 レコメンデーション
Standard Medium 102.2 179.8 V2 SKU は V1 ゲートウェイより多くの要求を処理できるため、複数の V1 ゲートウェイを 1 つの V2 ゲートウェイに統合して、コストを最適化することをお勧めします。 統合によって、Application Gateway の制限を超えないようにしてください。 3:1 の統合をお勧めします。
WAF Medium 183.96 262.8 Standard Medium の場合と同じ
Standard Large 467.2 179.58 これらのバリエーションでは、ほとんどの場合、V2 ゲートウェイに移行すると、V1 より優れた価格ベネフィットが得られます。
WAF Large 654.08 262.8 Standard Large の場合と同じ

Note

ここで示す計算は、米国東部での、V1 で 2 インスタンスのゲートウェイに関するものです。 V2 の変動コストは、次の 3 つのディメンションのうち使用量が最も高いものに基づいています: 新しい接続 (50/秒)、永続的な接続 (2500 永続接続/分)、スループット (1 CU は 2.22 Mbps を処理できます)。

ここで説明するシナリオは例であり、説明のみを目的としています。 ご自身のリージョンに応じた価格の情報については、価格のページをご覧ください。

価格に関してさらに心配がある場合は、CSAM と協力するか、サポート チームにお問い合わせください。

一般的な質問

移行に関する一般的な質問については、こちらをご覧ください

次のステップ

Application Gateway V2 について理解する