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

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(웹 애플리케이션 방화벽) V2로 마이그레이션하면 다음과 같은 몇 가지 이점이 있습니다.

향상된 복원력: AZ 중복도, 자동 크기 조정
향상된 보안: Azure Keyvault 통합, 향상된 WAF 기능, Bot Protection
향상된 모니터링 기능: CPU 모니터링만 있는 V1과 달리 V2는 CPU, 메모리 및 디스크 사용에 대한 포괄적인 모니터링을 제공합니다.
향상된 검색 및 자동 완화: V2 게이트웨이는 수동 개입 없이도 문제를 신속하고 정확하게 식별하고 해결할 수 있는 고급 검색 메커니즘 및 자동화된 완화 프로세스를 제공합니다.
V2 SKU에 대한 모든 새로운 기능이 릴리스되었습니다.

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

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

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

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

필수 구성 요소

활성 구독이 있는 Azure 계정. 체험 계정을 만듭니다.
기존 Application Gateway V1 Standard
최신 PowerShell 모듈이 있는지 확인하거나 포털에서 Azure Cloud Shell을 사용할 수 있습니다.
또한 PowerShell을 로컬로 실행하는 경우 Connect-AzAccount를 실행하여 Azure와 연결해야 합니다.
V1 구독의 AppGW V2 이름 및 리소스 그룹 이름을 사용하는 기존 Application Gateway가 없어야 합니다. 그러면 기존 리소스가 다시 작성됩니다.
공용 IP 주소를 사용하는 경우 상태가 성공이어야 합니다. 공용 IP를 사용하지 않고 AppGWResourceGroupName을 사용하는 경우에는 V1 구독의 리소스 그룹 AppGWResourceGroupName에 AppGWV2Name-IP라는 공용 IP 리소스가 없어야 합니다.
V1 SKU의 경우 백 엔드 서버와의 TLS 연결을 설정하려면 인증 인증서가 필요합니다. V2 SKU에서는 동일한 목적으로 신뢰할 수 있는 루트 인증서를 업로드해야 합니다. V1에서는 자체 서명된 인증서를 인증 인증서로 사용할 수 있지만 V2에서는 자체 서명된 인증서가 백 엔드에서 사용되는 경우 자체 서명 루트 인증서 생성 및 업로드를 요구합니다.
마이그레이션 중에 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에서 Az로 마이그레이션을 참조하세요.

구성 마이그레이션

구성 마이그레이션은 기존 V1 환경의 설정을 사용하여 새 V2 게이트웨이를 설정하는 데 중점을 둡니다. V1(표준 또는 WAF)에서 V2(Standard_V2 또는 WAF_V2) 게이트웨이로 구성을 쉽게 마이그레이션할 수 있도록 설계된 두 개의 Azure PowerShell 스크립트를 제공합니다. 이러한 스크립트는 키 배포 및 구성 작업을 자동화하여 전환 프로세스를 간소화하는 데 도움이 됩니다.

1. 향상된 복제 스크립트

다음과 같이 향상된 마이그레이션 환경을 제공하는 새로운 환경입니다.

프런트 엔드 SSL 인증서 및 백 엔드 신뢰할 수 있는 루트 인증서의 수동 입력이 필요하지 않습니다.
프라이빗 전용 V2 게이트웨이 배포 지원

참고

기존 V1 Application Gateway가 프라이빗 전용 프런트 엔드로 구성된 경우 마이그레이션 스크립트를 실행하기 전에 프라이빗 배포에 대한 구독에 EnableApplicationGatewayNetworkIsolation 기능을 등록 해야 합니다. 배포 오류를 방지하려면 이 단계가 필요합니다.

참고

프라이빗 Application Gateway 배포에는 Microsoft.Network/applicationGateways에 구성된 서브넷 위임이 있어야 합니다. 다음 단계를 사용하여 서브넷 위임을 설정합니다.

PowerShell 갤러리에서 고급 복제 스크립트를 다운로드할 수 있습니다.

스크립트에 대한 매개 변수: 이 스크립트는 아래 매개 변수를 사용합니다.

AppGw V1 ResourceId -Required: 이 매개 변수는 기존 표준 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 -Required: 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 -선택 사항: Application Gateway V2 인스턴스에 대해 자동 크기 조정 구성 사용 안 함, 기본적으로 false
WafPolicyName -선택 사항: WAF V1 구성에서 만들어지고 WAF v2 게이트웨이에 연결될 WAF 정책의 이름입니다.

스크립트를 실행하는 방법

스크립트를 실행하려면

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

적절한 매개 변수를 사용하여 스크립트를 실행합니다. 완료하는 데 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" `

Recommendations

스크립트가 완료된 후 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 요구 사항을 준수하는지 확인해야 합니다.

참고

마이그레이션하는 동안 V1 게이트웨이 또는 연결된 리소스에서 다른 작업을 시도하지 마세요.

2. 레거시 복제 스크립트

이 스크립트는 이전 복제 스크립트로, 다음을 통해 쉽게 전환할 수 있습니다.

사용자가 지정한 가상 네트워크 서브넷에 새 Standard_V2 또는 WAF_V2 Application Gateway를 생성합니다.
기존 표준 또는 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>).

참고

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 주소가 제공되지 않는 경우, V1 구독에서 AppGWResourceGroupName이라는 이름의 리소스 그룹에 AppGWV2Name-IP라는 이름의 공용 IP 리소스가 존재하지 않는지 확인해야 합니다."
validateMigration: [switch]: 선택 사항. V2 게이트웨이 만들기 및 구성 복사 후에 스크립트가 몇 가지 기본 구성 비교 유효성 검사를 수행하려면 이 매개 변수를 사용합니다. 기본적으로 유효성 검사는 수행되지 않습니다.
enableAutoScale: [switch]: 선택 사항. 새 V2 게이트웨이가 만들어진 후 자동 크기 조정을 사용하도록 스크립트를 사용하도록 설정하려면 이 매개 변수를 사용합니다. 기본적으로 자동 크기 조정이 사용되지 않습니다. 나중에 새로 만든 V2 게이트웨이에서 언제든지 자동 크기 조정을 사용하도록 수동으로 설정할 수 있습니다.

스크립트를 실행하는 방법

스크립트를 실행하려면

Connect-AzAccount를 사용하여 Azure에 연결합니다.
Import-Module Az를 사용하여 Az 모듈을 가져옵니다.
Set-AzContext cmdlet을 실행하여 활성 Azure 컨텍스트를 올바른 구독으로 설정합니다. 현재 구독 컨텍스트에 존재하지 않는 경우 마이그레이션 스크립트가 기존 리소스 그룹을 정리할 수 있으므로 이는 중요한 단계입니다.
```
Set-AzContext -Subscription '<V1 application gateway SubscriptionId>'
```
단계에 따라 스크립트를 설치하십시오-스크립트 설치
Get-Help AzureAppGWMigration.ps1을 실행하여 필요한 매개 변수를 검사합니다.

적절한 매개 변수를 사용하여 스크립트를 실행합니다. 완료하는 데 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 또는 개인 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 규칙 그룹 및 규칙을 참조하세요.

참고

NTLM 및 Kerberos 통과 인증은 Application Gateway V2에서 지원됩니다. 자세한 내용은 전용 백 엔드 연결을 참조하세요.

스크립트 설치

참고

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

로컬 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 모듈을 제거하거나 다른 옵션을 사용하여 스크립트를 수동으로 다운로드하여 실행할 수 있습니다.

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

향상된 복제를 위한 공용 IP 보존 스크립트 - Install-Script -Name AzureAppGWIPMigrate -Force
향상된 복제 스크립트의 경우 - Install-Script -Name AzureAppGWClone -Force
레거시 복제 스크립트의 경우 - Install-Script -Name AzureAppGWMigration -Force

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

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

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

이 스크립트는 원시 nupkg 파일로 다운로드됩니다. 이 nupkg 파일에서 스크립트를 설치하려면 수동 패키지 다운로드를 참조하세요.

레거시 복제 스크립트의 경우 버전 1.0.11은 주요 버그 수정을 포함하는 마이그레이션 스크립트의 새 버전입니다. PowerShell 갤러리에서 안정적인 최신 버전을 사용해야 합니다.

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

다운로드한 스크립트의 버전을 확인하려면 다음 단계를 수행합니다.

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.

트래픽 마이그레이션

필수 구성 요소

먼저 이 스크립트가 V1 게이트웨이에서 마이그레이션된 정확한 구성을 사용하여 성공적으로 새 V2 게이트웨이를 만들었는지 다시 한번 확인합니다. Azure Portal에서 이를 확인할 수 있습니다.
또한 V2 게이트웨이를 통해 적은 양의 트래픽을 수동 테스트로 보냅니다.

공용 IP 보존 스크립트

구성을 성공적으로 마이그레이션하고 새 V2 게이트웨이를 철저히 테스트한 후 이 단계에서는 라이브 트래픽을 리디렉션하는 데 중점을 둡니다. V1에서 공용 IP 주소를 유지하도록 설계된 Azure PowerShell 스크립트를 제공합니다.

공용 IP 교환: 이 스크립트는 V1에서 기본 공용 IP를 예약하고, 표준으로 변환하고, V2 게이트웨이에 연결합니다. 그러면 들어오는 모든 트래픽이 V2 게이트웨이로 효과적으로 리디렉션됩니다.
예상 가동 중지 시간: 이 IP 교환 작업으로 인해 일반적으로 약 1~5분의 짧은 가동 중지 시간이 발생합니다. 이에 따라 계획합니다.
스크립트가 성공적으로 실행되면 공용 IP가 Application Gateway V1에서 Application Gateway V2로 이동되고 Application Gateway V1은 새 공용 IP를 받습니다.

참고

IP 마이그레이션 스크립트는 DNS 이름이 숫자 문자로 시작하는 공용 IP 주소 리소스를 지원하지 않습니다. 공용 IP 주소 리소스는 숫자로 시작하는 DNS 이름 레이블을 허용하지 않기 때문에 이 제한 사항이 있습니다. 이 문제는 공용 IP 주소에 {GUID}.cloudapp.net 양식의 기본 DNS 이름이 자동으로 할당된 2023년 5월 이전에 만든 V1 게이트웨이에 대해 발생할 가능성이 높습니다. 마이그레이션을 계속하려면 스크립트를 실행하기 전에 문자로 시작하는 DNS 이름 레이블을 사용하도록 공용 IP 주소 리소스를 업데이트합니다. 공용 IP DNS 구성에 대해 알아보기

PowerShell 갤러리에서 이 공용 IP 보존 스크립트를 다운로드할 수 있습니다.

스크립트에 대한 매개 변수:

이 스크립트에는 다음과 같은 필수 매개 변수가 필요합니다.

V1 ResourceId – 공용 IP를 예약하고 V2와 연결할 V1 Application Gateway의 리소스 ID입니다.
V2 ResourceId – V1 공용 IP가 할당될 V2 Application Gateway의 리소스 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 게이트웨이에서 사용하지 않도록 설정됩니다.

참고

IP 마이그레이션 중에는 V1 및 V2 게이트웨이 또는 연결된 리소스에서 다른 작업을 시도하지 마세요.

참고

이 스크립트에서 수행하는 공용 IP 교환은 되돌릴 수 없습니다. 일단 시작되면 스크립트를 사용하여 IP를 V1 게이트웨이로 되돌릴 수 없습니다.

트래픽 마이그레이션 권장 사항

다음은 현재 애플리케이션 게이트웨이(표준)가 클라이언트 트래픽을 수신할 수 있는 몇 가지 시나리오와 각각에 대한 권장 사항입니다.

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 애플리케이션 게이트웨이와 연결된 IP 주소를 사용하도록 클라이언트를 업데이트합니다. IP 주소를 직접 사용하지 않는 것이 좋습니다. 사용자 지정 DNS 영역(예: contoso.com)에 CNAME 할 수 있는 Application Gateway와 연결된 DNS 이름 레이블(예: yourgateway.eastus.cloudapp.azure.com)을 사용하는 것이 좋습니다.

마이그레이션 후 상태

트래픽 마이그레이션이 성공하고 애플리케이션이 V2 게이트웨이를 통해 올바르게 실행되고 있는지 완전히 확인한 후에는 불필요한 비용을 방지하기 위해 이전 V1 Application Gateway 리소스의 서비스 해제 및 삭제를 안전하게 계획할 수 있습니다.

가격 책정 고려 사항

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 고정 가격/월	권장
표준 미디엄	102.2	179.8	V2 SKU는 V1 게이트웨이보다 많은 요청을 처리할 수 있으므로, 여러 V1 게이트웨이를 단일 V2 게이트웨이로 통합하여 비용을 최적화하는 것이 좋습니다. 통합 시 Application Gateway 제한을 초과하면 안됩니다. 3:1 통합을 권장합니다.
WAF 중간 수준	183.96	262.8	Standard Medium과 동일
스탠다드 라지	467.2	179.58	이러한 요금제의 경우 대부분은 V2 게이트웨이로 이동하면 V1보다 나은 가격적 이점을 얻을 수 있습니다.
WAF Large	654.08	262.8	Standard Large와 동일

참고

여기에 표시된 계산은 미국 동부 및 V1에 두 개의 인스턴스가 있는 게이트웨이를 기반으로 합니다. V2의 가변 비용은 새 연결(50/초), 영구 연결(2500개 영구 연결/분), 처리량(하나의 CU는 2.22Mbps를 처리할 수 있음)의 사용량이 가장 높은 세 가지 차원 중 하나를 기반으로 합니다.

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

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

일반적인 질문

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

다음 단계

Application Gateway V2에 대해 알아보기

피드백

이 페이지가 도움이 되었나요?

Last updated on 2025-11-04

다음을 통해 공유

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

필수 구성 요소

Azure Cloud Shell

구성 마이그레이션

1. 향상된 복제 스크립트

스크립트를 실행하는 방법

Recommendations

제한 사항

2. 레거시 복제 스크립트

스크립트를 실행하는 방법

주의 사항/제한 사항

스크립트 설치

Install-Script 방법을 사용하여 설치(권장)

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

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

트래픽 마이그레이션

필수 구성 요소

공용 IP 보존 스크립트

트래픽 마이그레이션 권장 사항

마이그레이션 후 상태

가격 책정 고려 사항

비용 효율성 지침

일반적인 질문

다음 단계

피드백

추가 리소스