Azure Application Gateway와 Web Application Firewall을 V1에서 V2로 마이그레이션

아티클
03/08/2024

2023년 4월 28일에 Application Gateway V1 SKU(Standard 및 WAF)의 사용 중단을 발표했습니다. V1 SKU는 2026년 4월 28일에 사용 중지됩니다. 자세한 내용은 2026년 4월 28일까지 V1 SKU에서 V2 SKU로 Application Gateway 마이그레이션을 참조하세요.

Azure Application Gateway 및 WAF(Web Application Firewall) V2는 이제 자동 크기 조정, 가용성, 영역 중복, 더 높은 성능, 더 빠른 작업 속도, 향상된 처리량 등 V1보다 더 많은 기능을 제공합니다. 또한 새 기능은 V2 SKU용으로 릴리스되었습니다. 지금 마이그레이션 계획을 수립하는 것이 좋습니다.

V1 게이트웨이는 V2로 자동 업그레이드되지 않습니다. 마이그레이션 계획을 수립하고 실행하는 데 도움이 되는 이 마이그레이션 가이드를 참조하세요.

마이그레이션에는 두 단계가 있습니다.

구성 마이그레이션
클라이언트 트래픽 마이그레이션

이 문서는 주로 구성 마이그레이션에 도움이 됩니다. 클라이언트 트래픽 마이그레이션은 환경에 따라 달라집니다. 이 문서에서는 일반적인 권장 사항을 제공합니다.

필수 조건

활성 구독이 있는 Azure 계정. 체험 계정을 만듭니다.
기존 Application Gateway V1 Standard
최신 PowerShell 모듈이 있는지 확인하거나 포털에서 Azure Cloud Shell을 사용할 수 있습니다.
또한 PowerShell을 로컬로 실행하는 경우 Connect-AzAccount를 실행하여 Azure와 연결해야 합니다.
V1 구독에 제공된 AppGW V2 이름 및 리소스 그룹 이름을 가진 기존 Application Gateway가 없는지 확인합니다. 그러면 기존 리소스가 다시 작성됩니다.
공용 IP 주소가 제공된 경우 성공한 상태인지 확인합니다. 제공되지 않은 경우 AppGWResourceGroupName이 제공되면 AppGWV2Name-IP라는 이름의 공용 IP 리소스가 V1 구독에서 AppGWResourceGroupName이라는 이름의 리소스 그룹에 존재하지 않도록 합니다.
마이그레이션 중에 V1 게이트웨이 또는 연결된 리소스에서 다른 작업이 계획되지 않았는지 확인합니다.

Azure Cloud Shell

Azure는 브라우저를 통해 사용할 수 있는 대화형 셸 환경인 Azure Cloud Shell을 호스트합니다. Cloud Shell에서 Bash 또는 PowerShell을 사용하여 Azure 서비스 작업을 수행할 수 있습니다. 로컬 환경에 아무 것도 설치할 필요 없이 Azure Cloud Shell의 미리 설치된 명령을 사용하여 이 문서의 코드를 실행할 수 있습니다.

Azure Cloud Shell을 시작하려면 다음을 수행합니다.

옵션	예제/링크
코드 또는 명령 블록의 오른쪽 상단에서 시도를 선택합니다. 시도를 선택해도 코드 또는 명령이 Cloud Shell에 자동으로 복사되지 않습니다.
https://shell.azure.com으로 이동하거나 Cloud Shell 시작 단추를 선택하여 브라우저에서 Cloud Shell을 엽니다.
Azure Portal의 오른쪽 위에 있는 메뉴 모음에서 Cloud Shell 단추를 선택합니다.

Azure Cloud Shell을 사용하려면:

Cloud Shell을 시작합니다.
코드 블록(또는 명령 블록)에서 복사 단추를 선택하여 코드 또는 명령을 복사합니다.
Windows 및 Linux에서 Ctrl+Shift+V를 선택하거나 macOS에서 Cmd+Shift+V를 선택하여 코드 또는 명령을 Cloud Shell 세션에 붙여넣습니다.
Enter를 선택하여 코드 또는 명령을 실행합니다.

참고 항목

Azure Az PowerShell 모듈을 사용하여 Azure와 상호 작용하는 것이 좋습니다. 시작하려면 Azure PowerShell 설치를 참조하세요. Az PowerShell 모듈로 마이그레이션하는 방법에 대한 자세한 내용은 Azure PowerShell을 AzureRM에서 Azure로 마이그레이션을 참조하세요.

Important

마이그레이션 스크립트를 실행하기 전에 항상 Set-AzContext -Subscription <V1 application gateway SubscriptionId> cmdlet을 실행합니다. 이는 활성 Azure 컨텍스트를 올바른 구독으로 설정하는 데 필요합니다. 마이그레이션 스크립트가 기존 리소스 그룹을 정리하여 현재 구독 컨텍스트에 기존 리소스 그룹이 없을 수 있기 때문입니다. 마이그레이션 스크립트 버전 1.0.11 이상에서는 필수 단계가 아닙니다.

Important

이제 마이그레이션 스크립트의 안정적인 새 버전인 버전 1.0.11을 사용할 수 있습니다. 여기에는 중요한 버그 수정 및 업데이트가 포함되어 있습니다. 이 버전을 사용하여 잠재적인 문제를 방지합니다.

구성 마이그레이션

이 문서에서는 Azure PowerShell 스크립트를 제공합니다. 이 스크립트는 구성에 도움이 되도록 다음 작업을 수행합니다.

사용자가 지정하는 가상 네트워크 서브넷에 새 Standard_V2 또는 WAF_V2 게이트웨이를 만듭니다.
V1 Standard 또는 WAF 게이트웨이와 연결된 구성을 새로 만든 Standard_V2 또는 WAF_V2 게이트웨이에 원활하게 복사합니다.

스크립트 다운로드

PowerShell 갤러리 마이그레이션 스크립트를 다운로드할 수 있습니다. 마이그레이션 스크립트의 안정적인 새 릴리스(버전 1.0.11)를 사용할 수 있으며 여기에는 주요 업데이트 및 버그 수정이 포함됩니다. 이 안정적인 버전을 사용하는 것이 좋습니다.

스크립트 사용

참고 항목

로컬 PowerShell 환경 설정 및 기본 설정에 따라 다음과 같은 두 가지 옵션을 사용할 수 있습니다.

Azure Az 모듈이 설치되어 있지 않거나 Azure Az 모듈을 제거해도 상관없는 경우 Install-Script 옵션을 사용하여 스크립트를 실행하는 것이 가장 좋습니다.
Azure Az 모듈을 유지해야 하는 경우에는 스크립트를 다운로드하여 직접 실행하는 것이 가장 좋습니다.

Azure Az 모듈이 설치되어 있는지 확인하려면 Get-InstalledModule -Name az를 실행합니다. 설치된 Az modules가 표시되지 않으면 Install-Script 메서드를 사용할 수 있습니다.

Install-Script 메서드를 사용하여 설치(권장)

이 옵션을 사용하려면 컴퓨터에 Azure Az 모듈이 설치되어 있지 않아야 합니다. 설치되어 있는 경우 다음 명령이 오류를 표시합니다. Azure Az 모듈을 제거하거나 다른 옵션을 사용하여 스크립트를 수동으로 다운로드하여 실행할 수 있습니다.

다음 명령을 실행하여 스크립트를 실행하고 최신 버전을 다운로드합니다.

Install-Script -Name AzureAppGWMigration -Force

또한 이 명령은 필요한 Az 모듈을 설치합니다.

스크립트를 직접 사용한 설치

일부 Azure Az 모듈이 설치되어 있고 제거할 수 없는 경우(또는 제거하지 않으려는 경우) 스크립트 다운로드 링크의 수동 다운로드 탭을 사용하여 스크립트를 수동으로 다운로드할 수 있습니다. 스크립트는 원시 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.

PowerShell 갤러리에서 안정적인 최신 버전을 사용해야 합니다.

스크립트를 실행하는 방법

스크립트를 실행하려면

Connect-AzAccount를 사용하여 Azure에 연결합니다.
Import-Module Az를 사용하여 Az 모듈을 가져옵니다.
cmdlet을 Set-AzContext 실행하여 활성 Azure 컨텍스트를 올바른 구독으로 설정합니다. 마이그레이션 스크립트가 현재 구독 컨텍스트에 없는 경우 기존 리소스 그룹을 클린 수 있으므로 이 단계는 중요한 단계입니다.
```
Set-AzContext -Subscription '<V1 application gateway SubscriptionId>'
```

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

참고 항목

마이그레이션 중에는 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>).

참고 항목

V1 구독에 제공된 AppGW V2 이름 및 리소스 그룹 이름을 가진 기존 Application Gateway가 없는지 확인합니다. 그러면 기존 리소스가 다시 작성됩니다.

sslCertificates: [PSApplicationGatewaySslCertificate]: 선택 사항. V1 게이트웨이에서 TLS/SSL 인증서를 나타내기 위해 만드는 PSApplicationGatewaySslCertificate 개체의 쉼표로 구분된 목록은 새 V2 게이트웨이에 업로드해야 합니다. 여기에 표시된 New-AzApplicationGatewaySslCertificate 명령을 통해 Standard V1 또는 WAF V1 게이트웨이에 대해 구성된 각 TLS/SSL 인증서에 새 PSApplicationGatewaySslCertificate 개체를 만들 수 있습니다. TLS/SSL 인증서 파일의 경로와 암호를 입력해야 합니다.

이 매개 변수는 V1 게이트웨이 또는 WAF에 대해 구성된 HTTPS 수신기가 없는 경우에만 선택 사항입니다. 하나 이상의 HTTPS 수신기가 설정된 이 매개 변수를 지정해야 합니다.
```
$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을 스크립트의 매개 변수에 대한 값으로 전달할 수 있습니다.

Keyvault의 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)

Keyvault에서 다운로드한 인증서마다 여기에 표시된 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 주소(표준 SKU) 리소스의 resourceId입니다. 공용 IP 리소스 이름이 제공된 경우 성공 상태에 있는지 확인합니다. 이 주소를 지정하지 않으면 스크립트는 동일한 리소스 그룹에 새 공용 IP 주소를 할당합니다. 이름은 -IP가 추가된 V2 게이트웨이의 이름입니다. AppGWResourceGroupName이 제공되고 공용 IP 주소가 제공되지 않는 경우 AppGWV2Name-IP라는 이름의 공용 IP 리소스가 V1 구독의 AppGWResourceGroupName이라는 이름의 리소스 그룹에 없는지 확인합니다.
validateMigration: [switch]: 선택 사항. 이 매개 변수를 사용하여 V2 게이트웨이를 만들고 구성 복사본을 만든 후 스크립트에서 몇 가지 기본 구성 비교 유효성 검사를 수행할 수 있도록 합니다. 기본적으로 유효성 검사는 수행되지 않습니다.
enableAutoScale: [switch]: 선택 사항. 이 매개 변수를 사용하여 스크립트를 만든 후 새 V2 게이트웨이에서 자동 크기 조정을 사용하도록 설정합니다. 기본적으로 자동 크기 조정이 사용되지 않습니다. 나중에 새로 만든 V2 게이트웨이에서 언제든지 자동 크기 조정을 사용하도록 수동으로 설정할 수 있습니다.

적절한 매개 변수를 사용하여 스크립트를 실행합니다. 완료하는 데 5~7분 정도 걸릴 수 있습니다.

예제

AzureAppGWMigration.ps1 `
   -resourceId /subscriptions/8b1d0fea-8d57-4975-adfb-308f1f4d12aa/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/8b1d0fea-8d57-4975-adfb-308f1f4d12aa/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
   -validateMigration -enableAutoScale

주의 사항/제한 사항

새 V2 게이트웨이는 새 공용 IP와 개인 IP 주소를 갖고 있습니다. 기존 V1 게이트웨이와 연결된 IP 주소를 V2로 원활하게 이동할 수 없습니다. 그러나 (할당되지 않은) 기존 공용 IP 또는 개인 IP 주소를 새 V2 게이트웨이에 할당할 수 있습니다.
가상 네트워크 내에서 V1 게이트웨이가 있는 다른 서브넷에 IP 주소 공간을 제공해야 합니다. 이 스크립트는 이미 V1 게이트웨이가 있는 서브넷에 V2 게이트웨이를 만들 수 없습니다. 서브넷에 이미 V2 게이트웨이가 있는 경우에는 IP 주소 공간만 충분하다면 이 스크립트가 계속 작동할 수 있습니다.
V2 게이트웨이 서브넷에 연결된 네트워크 보안 그룹 또는 사용자 정의 경로가 있는 경우 성공적인 마이그레이션을 위해 NSG 요구 사항과 UDR 요구 사항을 준수하는지 확인합니다.
가상 네트워크 서비스 엔드포인트 정책은 현재 Application Gateway 서브넷에서 지원되지 않습니다.
TLS/SSL 구성을 마이그레이션하려면 V1 게이트웨이에서 사용되는 모든 TLS/SSL 인증서를 지정해야 합니다.
V1 게이트웨이에 FIPS 모드를 사용하도록 설정한 경우 새 V2 게이트웨이로 마이그레이션되지 않습니다. V2에서는 FIPS 모드가 지원되지 않습니다.
개인 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 게이트웨이를 통해 적은 양의 트래픽을 수동 테스트로 보냅니다.

현재 Application Gateway(Standard)가 클라이언트 트래픽을 수신할 수 있는 시나리오와 각 시나리오에 대한 권장 사항은 다음과 같습니다.

Standard V1 또는 WAF V1 게이트웨이와 연결된 (A 레코드를 사용하는) 프런트 엔드 IP 주소를 가리키는 사용자 지정 DNS 영역(예: contoso.com)입니다.

Standard_V2 Application Gateway와 연결된 프런트 엔드 IP 또는 DNS 레이블을 가리키도록 DNS 레코드를 업데이트할 수 있습니다. DNS 레코드에 구성된 TTL에 따라 모든 클라이언트 트래픽이 새 V2 게이트웨이로 마이그레이션하는 데 시간이 걸릴 수 있습니다.
V1 게이트웨이와 연결된 DNS 레이블(예: CNAME 레코드를 사용하는 myappgw.eastus.cloudapp.azure.com)을 가리키는 사용자 지정 DNS 영역(예: contoso.com)입니다.

다음과 같은 두 가지 선택 옵션이 있습니다.
- Application Gateway에서 공용 IP 주소를 사용하는 경우 Traffic Manager 프로필을 사용하여 제어된 세분화된 마이그레이션을 수행하여 트래픽(가중 트래픽 라우팅 방법)을 새 V2 게이트웨이로 증분 라우팅할 수 있습니다.
  
  V1 및 V2 Application Gateway의 DNS 레이블을 Traffic Manager 프로필에 추가하고 사용자 지정 DNS 레코드(예: www.contoso.com)를 Traffic Manager 도메인(예: contoso.trafficmanager.net)에 CNAME을 지정하여 이 작업을 수행할 수 있습니다.
- 또는 새 V2 Application Gateway의 DNS 레이블을 가리키도록 사용자 지정 도메인 DNS 레코드를 업데이트할 수 있습니다. DNS 레코드에 구성된 TTL에 따라 모든 클라이언트 트래픽이 새 V2 게이트웨이로 마이그레이션하는 데 시간이 걸릴 수 있습니다.
클라이언트는 Application Gateway의 프런트 엔드 IP 주소에 연결합니다.

새로 만든 V2 Application Gateway와 연결된 IP 주소를 사용하도록 클라이언트를 업데이트합니다. IP 주소를 직접 사용하지 않는 것이 좋습니다. 사용자 지정 DNS 영역(예: contoso.com)에 CNAME 할 수 있는 Application Gateway와 연결된 DNS 이름 레이블(예: yourgateway.eastus.cloudapp.azure.com)을 사용하는 것이 좋습니다.

가격 책정 고려 사항

Application Gateway V1 및 V2 SKU의 가격 책정 모델이 서로 다릅니다. V2는 사용량에 따라 요금이 청구됩니다. 마이그레이션하기 전에 Application Gateway 가격 책정에서 가격 책정 정보를 확인하세요.

비용 효율성 지침

V2 SKU는 5배 성능 향상, Key Vault 통합을 통한 보안 향상, WAF_V2 보안 규칙의 빠른 업데이트, WAF 사용자 지정 규칙, 정책 연결, 봇 보호 등의 다양한 이점을 제공합니다. 또한 높은 확장성, 최적화된 트래픽 라우팅, Azure 서비스와의 원활한 통합을 제공합니다. 이러한 기능은 전반적인 사용자 경험을 개선하고, 트래픽이 많은 시간에 속도가 느려지는 것을 방지하며, 비싼 대가를 치르게 되는 데이터 위반을 방지할 수 있습니다.

V1 SKU는 계층과 크기가 다른 5가지 옵션 Standard_Small, Standard_Medium, Standard_Large, WAF_Medium 및 WAF_Large를 제공합니다.

SKU	V1 고정 가격/월	V2 고정 가격/월	권장
Standard Medium	102.2	179.8	V2 SKU는 V1 게이트웨이보다 많은 요청을 처리할 수 있으므로, 여러 V1 게이트웨이를 단일 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와 동일

참고 항목

미국 동부 및 V1에 인스턴스가 2개 있는 게이트웨이를 가정한 계산입니다. V2의 가변 비용은 새 연결 수(50/초), 영구 연결 수(2500개 영구 연결/분), 처리량(1CU가 2.22Mbps 처리 가능)의 3개 차원 중에서 사용량이 가장 높은 차원을 기반으로 계산됩니다.

이 문서의 시나리오는 설명을 위해 가정한 예시일 뿐입니다. 해당 지역에 따른 가격 책정 정보는 가격 책정 페이지를 참조하세요.

가격 책정에 대한 추가 문의 사항은 CSAM에 문의하거나 지원 팀에 문의하여 도움을 받으세요.

일반적인 질문

마이그레이션에 대한 일반적인 질문은 여기에서 찾을 수 있습니다.

다음 단계

Application Gateway V2에 대해 알아보기

Azure Application Gateway와 Web Application Firewall을 V1에서 V2로 마이그레이션

필수 조건

Azure Cloud Shell

구성 마이그레이션

스크립트 다운로드

스크립트 사용

Install-Script 메서드를 사용하여 설치(권장)

스크립트를 직접 사용한 설치

다운로드한 스크립트의 버전을 확인하는 방법

스크립트를 실행하는 방법

주의 사항/제한 사항

트래픽 마이그레이션

가격 책정 고려 사항

비용 효율성 지침

일반적인 질문

다음 단계

추가 리소스