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 への移行には、いくつかの利点があります。

• 回復力の強化: AZ 冗長性、自動スケール
• セキュリティの強化: Azure Keyvault 統合、WAF 機能の強化、Bot Protection
• 強化された監視機能: CPU 監視のみを備えた V1 とは異なり、V2 は CPU、メモリ、ディスクの使用状況を包括的に監視します。
• 検出と自動軽減の強化: V2 ゲートウェイには、高度な検出メカニズムと自動化された軽減プロセスが備わっており、手動による介入を必要とせずに問題を迅速かつ正確に特定して解決できます。
• 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 に自動的にはコピーされません。
https://shell.azure.com に移動するか、[Cloud Shell を起動する] ボタンを選択して、ブラウザーで 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 キーを選択して、コードまたはコマンドを実行します。

構成の移行

構成移行では、既存の V1 環境の設定を使用して新しい V2 ゲートウェイを設定することに重点を置いています。 V1 (Standard または WAF) から V2 (Standard_V2 または WAF_V2) ゲートウェイへの構成の移行を容易にするように設計された 2 つの Azure PowerShell スクリプトが用意されています。 これらのスクリプトは、主要なデプロイタスクと構成タスクを自動化することで、移行プロセスを効率化するのに役立ちます。

1. 拡張複製スクリプト

これは、次の方法で改善された移行エクスペリエンスを提供する新しいエクスペリエンスです。

• フロントエンド SSL 証明書とバックエンドの信頼されたルート証明書を手動で入力する必要がなくなります。
• プライベートのみの V2 ゲートウェイのデプロイをサポートします。

拡張複製スクリプトは、PowerShell ギャラリーからダウンロードできます。

スクリプトのパラメーター: このスクリプトは、次のパラメーターを受け取ります。

• AppGw V1 ResourceId -Required: このパラメーターは、既存の 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 - 必須: Application Gateway V2 をデプロイするサブネットの CIDR 表記のアドレス
• AppGwName -省略可能: v2 アプリ ゲートウェイの名前。 デフォルト値 = {AppGwV1 Name}_migrated
• AppGwResourceGroupName -省略可能: V2 Application Gateway が作成されるリソース グループの名前。 指定しない場合は、Application Gateway V1 リソース グループが使用されます。
• PrivateIPAddress -省略可能: Application Gateway V2 に割り当てられるプライベート IP アドレス。 指定しない場合は、ランダムなプライベート IP が割り当てられます。
• ValidateBackendHealth -省略可能: ApplicationGatewayBackendHealth 応答を比較して、移行後の検証を行います。 設定されていない場合、この検証はスキップされます。
• PublicIpResourceId -省略可能: パブリック IP アドレス resourceId (既に存在する場合) をアプリケーション ゲートウェイに接続できます。 指定しない場合、パブリック IP 名は {AppGwName}-IP になります。
• DisableAutoscale -Optional: Application Gateway V2 インスタンスの自動スケール構成を無効にします。既定では false
• WafPolicyName -省略可能: WAF V1 構成から作成され、WAF v2 ゲートウェイにアタッチされる WAF ポリシーの名前。

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

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

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

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

4. 手順に従ってスクリプトをインストールする - スクリプトのインストール
5. 適切なパラメーターを使用してスクリプトを実行します。 完了するまで 5 から 7 分かかることがあります。

   ./AzureAppGWClone.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>
   -privateIpAddress <private IP string>
   -publicIpResourceId <public IP name string>
   - disableAutoscale
   -wafpolicyname <wafpolicyname>
   

   例

   ./AzureAppGWClone.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" `
   -privateIpAddress "10.0.0.1" `
   -publicIpResourceId "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
   

推奨事項

• スクリプトの完了後、Azure portal で V2 ゲートウェイの構成を確認し、V2 ゲートウェイの IP にトラフィックを直接送信して接続をテストします。
• このスクリプトは、複製中に既定でバックエンド TLS 検証を緩和します (証明書チェーン、有効期限、SNI 検証なし)。 より厳密な TLS 検証または認証証明書が必要な場合、お客様は Application Gateway V2 の作成後に更新して、信頼されたルート証明書を追加し、要件に従ってこの機能を有効にすることができます。
• NTLM/Kerberos パススルーの場合は、複製後に HTTP 設定で専用バックエンド接続を "true" に設定します。

注意事項

• V1 ゲートウェイが配置されている仮想ネットワーク内の別のサブネットの IP アドレス空間を指定する必要があります。 スクリプトでは、V1 ゲートウェイが既に存在するサブネットに、V2 ゲートウェイを作成することはできません。 サブネットに V2 ゲートウェイが既にある場合、十分な IP アドレス空間を使用できれば、スクリプトは引き続き動作する可能性があります。
• V2 ゲートウェイ サブネットに関連付けられているネットワーク セキュリティ グループまたはユーザー定義ルートがある場合は、移行を成功させるために、それらが NSG 要件と UDR要件に準拠していることを確認します
• V1 ゲートウェイで FIPS モードを有効にしている場合、それは新しい V2 ゲートウェイに移行されません。
• 新しい WAFV2 は、既定で CRS 3.0 を使用するように構成されています。 ただし、CRS 3.0 は非推奨になる予定であるため、移行後に最新のルール セット DRS 2.1 にアップグレードすることをお勧めします。 詳細については、「 CRS および DRS ルール グループ」 を参照してください。ルールには、V2 ゲートウェイ サブネットに関連付けられたネットワーク セキュリティ グループまたはユーザー定義ルートがあり、移行を成功させるために NSG 要件と UDR 要件に準拠していることを確認してください。

2. 従来の複製スクリプト

これは古い複製スクリプトであり、次の方法で移行を容易にします。

• ユーザー指定の仮想ネットワーク サブネットに新しいStandard_V2または WAF_V2 Application Gateway を作成する。
• 既存の Standard または WAF V1 ゲートウェイから新しく作成された V2 ゲートウェイに構成を自動的にコピーします。
• お客様が入力として SSL 証明書と認証証明書を提供する必要があり、プライベートのみの V2 ゲートウェイをサポートしていません。PowerShell ギャラリーからこの複製スクリプトをダウンロードできます

スクリプトのパラメーター: レガシ スクリプトは、次のパラメーターを受け取ります。

• 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> です)

• 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. Connect-AzAccount を使用して Azure に接続します。
2. Import-Module Az を使用して Az モジュールをインポートします。
3. Set-AzContext コマンドレットを実行して、アクティブな Azure コンテキストを適切なサブスクリプションに設定します。 移行スクリプトは、既存のリソース グループが現在のサブスクリプション コンテキストに存在しない場合、それをクリーンアップする可能性があるので、これは重要なステップです。

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

4. 手順に従ってスクリプトをインストールする - スクリプトのインストール
5. Get-Help AzureAppGWMigration.ps1 を実行して必要なパラメーターを調べます。
6. 適切なパラメーターを使用してスクリプトを実行します。 完了するまで 5 から 7 分かかることがあります。

      ./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
   

   例

      ./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 ゲートウェイに移行されません。
• WAFv2 は古い WAF 構成モードで作成されます。WAF ポリシーへの移行が必要です。
• 新しい WAFv2 は、既定で CRS 3.0 を使用するように構成されています。 ただし、CRS 3.0 は非推奨になる予定であるため、移行後に最新のルール セット DRS 2.1 にアップグレードすることをお勧めします。 詳細については、CRS および DRS ルール グループとルールを参照してください。

スクリプトのインストール

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

• Azure Az モジュールがインストールされていない場合、または Azure Az モジュールをアンインストールしてもかまわない場合、最善の方法は Install-Script オプションを使用してスクリプトを実行することです。
• Azure Az モジュールを保持する必要がある場合は、スクリプトをダウンロードして直接実行するのが最善の方法です。 Azure Az モジュールがインストールされているかどうかを確認するには、Get-InstalledModule -Name az を実行します。 インストールされている Az モジュールが見つからなかった場合は、Install-Script メソッドを使用できます。

Install-Script メソッドを使用してインストールする (推奨)

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

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

• パブリック IP 保持スクリプトの複製を強化するには - Install-Script -Name AzureAppGWIPMigrate -Force

• 従来の複製スクリプトの場合 - Install-Script -Name AzureAppGWMigration -Force

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

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

何らかの Azure Az モジュールがインストールされていて、それらをアンインストールできない (またはアンインストールしたくない) 場合は、スクリプトのダウンロード リンクの [Manual Download] (手動ダウンロード) タブを使って、手動でスクリプトをダウンロードできます。

スクリプトは、生の nupkg ファイルとしてダウンロードされます。 この nupkg ファイルからスクリプトをインストールするには、「パッケージの手動ダウンロード」を参照してください。

従来の複製スクリプトの場合、バージョン 1.0.11 は、主要なバグ修正を含む新しいバージョンの移行スクリプトです。 PowerShell ギャラリーにある最新の安定バージョンを使用してください

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

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

1. NuGet パッケージの内容を抽出します。
2. フォルダー内の .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.

トラフィックの移行

前提条件

• まず、スクリプトによって、V1 ゲートウェイから移行された正確な構成で、V2 の新しいゲートウェイが正常に作成されたことを再確認します。 この確認は Azure portal から行うことができます。
• また、手動テストとして少量のトラフィックを V2 ゲートウェイ経由で送信します。

パブリック IP 保持スクリプト

構成を正常に移行し、新しい V2 ゲートウェイを徹底的にテストした後、この手順ではライブ トラフィックのリダイレクトに重点を置きます。 V1 のパブリック IP アドレスを保持するように設計された Azure PowerShell スクリプトを提供します。

• パブリック IP のスワップ: このスクリプトは、V1 から Basic パブリック IP を予約し、Standard に変換して、V2 ゲートウェイに接続します。 これにより、すべての受信トラフィックが V2 ゲートウェイに効果的にリダイレクトされます。
• 予期されるダウンタイム: 通常、この IP スワップ操作により、 約 1 ~ 5 分の短いダウンタイムが発生します。 それに従って計画を立てます。
• スクリプトの実行が成功すると、パブリック IP は Application Gateway V1 から Application Gateway V2 に移動され、Application Gateway V1 は新しいパブリック IP を受信します。

パブリック IP 保持スクリプトはPowerShell ギャラリーからダウンロードできます。

スクリプトのパラメーター:

このスクリプトには、次の必須パラメーターが必要です。

• V1 ResourceId – パブリック IP が予約され、V2 に関連付けられる V1 アプリケーション ゲートウェイのリソース ID。
• V2 ResourceId – V1 パブリック IP が割り当てられる V2 アプリケーション ゲートウェイのリソース ID。 V2 ゲートウェイは、手動で作成することも、複製スクリプトを使用して作成することもできます。

スクリプトをダウンロードしてインストールした後

必要なパラメーターを使用して AzureAppGWIPMigrate.ps1 を実行します。

   ./AzureAppGWIPMigrate.ps1
    -v1resourceId <V1 application gateway Resource ID>
    -v2resourceId <V2 application gateway Resource ID>

例

 ./AzureAppGWIPMigrate.ps1 `
 -v1resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
 -v2resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv2appgateway `

IP スワップが完了したら、V2 ゲートウェイでの制御とデータ プレーンの操作を確認する必要があります。 V1 ゲートウェイでは、Delete を除くすべてのコントロール プレーン アクションが無効になります。

Traffic Migrationに関する推奨事項

現在のアプリケーション ゲートウェイ (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) を使用することを検討してください。

移行後

トラフィックの移行が成功し、アプリケーションが V2 ゲートウェイ経由で正しく実行されていることを完全に確認したら、不要なコストを回避するために、古い V1 Application Gateway リソースの使用停止と削除を安全に計画できます。

価格に関する考慮事項

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 つのバリエーションを利用できます。

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

一般的な質問

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

次のステップ

Application Gateway V2 について理解する