Memigrasikan Azure Application Gateway dan Web Application Firewall dari V1 ke V2

Kami mengumumkan penghentian SKU Application Gateway V1 (Standar dan WAF) pada 28 April 2023. V1 SKU berhenti pada 28 April 2026. Untuk informasi selengkapnya, lihat Memigrasikan Application Gateway Anda dari V1 SKU ke V2 SKU pada 28 April 2026.

Azure Application Gateway dan Web Application Firewall (WAF) V2 sekarang menawarkan fitur tambahan seperti penskalaan otomatis, ketersediaan, redundansi zona, performa yang lebih tinggi, operasi yang lebih cepat, dan throughput yang ditingkatkan dibandingkan dengan V1. Selain itu, semua fitur baru dirilis untuk V2 SKU. Sangat disarankan bagi Anda untuk membuat rencana migrasi sekarang.

Gateway V1 tidak dimutakhirkan secara otomatis ke V2. Gunakan panduan migrasi ini untuk membantu Anda merencanakan dan melakukan migrasi.

Ada dua tahap dalam migrasi:

1. Memigrasikan konfigurasi
2. Memigrasikan lalu lintas klien

Artikel ini terutama membantu migrasi konfigurasi. Migrasi lalu lintas klien bervariasi tergantung pada lingkungan. Beberapa rekomendasi umum disediakan dalam artikel ini.

Prasyarat

• Akun Azure dengan langganan aktif. Buat akun secara gratis.
• Application Gateway V1 Standard yang sudah ada.
• Pastikan Anda memiliki modul PowerShell terbaru, atau Anda dapat menggunakan Azure Cloud Shell di portal.
• Jika Anda menjalankan PowerShell secara lokal, Anda juga harus menjalankan Connect-AzAccount untuk membuat koneksi dengan Azure.
• Pastikan bahwa tidak ada gateway Aplikasi dengan Nama AppGW V2 dan nama grup Sumber Daya yang disediakan dalam langganan V1. Ini menulis ulang sumber daya yang ada.
• Jika alamat IP publik disediakan, pastikan alamat IP tersebut dalam keadaan berhasil. Jika tidak disediakan dan AppGWResourceGroupName disediakan, pastikan bahwa sumber daya IP publik dengan nama AppGWV2Name-IP tidak ada di grup sumber daya dengan nama AppGWResourceGroupName dalam langganan V1.
• Pastikan bahwa tidak ada operasi lain yang direncanakan pada gateway V1 atau sumber daya terkait selama migrasi.

Azure Cloud Shell

Azure meng-hosting Azure Cloud Shell, lingkungan shell interaktif yang dapat Anda gunakan melalui browser. Anda dapat menggunakan Bash atau PowerShell dengan Cloud Shell untuk bekerja dengan layanan Azure. Anda dapat menggunakan perintah Cloud Shell yang telah diinstal sebelumnya untuk menjalankan kode dalam artikel ini tanpa harus menginstal apa-apa di lingkungan lokal Anda.

Untuk memulai Azure Cloud Shell:

Opsi	Contoh/Tautan
Pilih Coba di pojok kanan atas blok kode atau perintah. Memilih Coba tidak otomatis menyalin kode atau perintah ke Cloud Shell.
Buka https://shell.azure.com, atau pilih tombol Luncurkan Cloud Shell untuk membuka Cloud Shell di browser Anda.
Pilih tombol Cloud Shell pada bilah menu di kanan atas di portal Microsoft Azure.

Untuk menggunakan Azure Cloud Shell:

1. Mulai Cloud Shell.

2. Pilih tombol Salin pada blok kode (atau blok perintah) untuk menyalin kode atau perintah.

3. Tempel kode atau perintah ke dalam sesi Cloud Shell dengan memilih Ctrl+Shift+V di Windows dan Linux, atau dengan memilih Cmd+Shift+V di macOS.

4. Pilih Masukkan untuk menjalankan kode atau perintah.

Catatan

Sebaiknya Anda menggunakan modul Azure Az PowerShell untuk berinteraksi dengan Azure. Lihat Menginstal Azure PowerShell untuk memulai. Untuk mempelajari cara bermigrasi ke modul Az PowerShell, lihat Memigrasikan Azure PowerShell dari AzureRM ke Az.

Penting

Jalankan Set-AzContext -Subscription <V1 application gateway SubscriptionId> cmdlet setiap kali sebelum menjalankan skrip migrasi. Ini diperlukan untuk mengatur konteks Azure aktif ke langganan yang benar, karena skrip migrasi mungkin membersihkan grup sumber daya yang ada jika tidak ada dalam konteks langganan saat ini. Ini bukan langkah wajib untuk versi 1.0.11 & di atas skrip migrasi.

Penting

Versi stabil baru dari skrip migrasi, versi 1.0.11 tersedia sekarang, yang berisi perbaikan bug dan pembaruan penting. Gunakan versi ini untuk menghindari potensi masalah.

Migrasi konfigurasi

Skrip Azure PowerShell disediakan dalam dokumen ini. Ini melakukan operasi berikut untuk membantu Anda dengan konfigurasi:

• Membuat gateway Standard_V2 atau WAF_V2 baru di subnet jaringan virtual yang Anda tentukan.
• Menyalin konfigurasi yang terkait dengan gateway Standar atau WAF V1 dengan lancar ke gateway Standard_V2 atau WAF_V2 yang baru dibuat.

Mengunduh skrip

Anda dapat mengunduh skrip migrasi dari Galeri PowerShell. Rilis stabil baru (Versi 1.0.11) dari skrip migrasi tersedia, yang mencakup pembaruan utama dan perbaikan bug. Disarankan untuk menggunakan versi stabil ini.

Menggunakan skrip

Catatan

Jalankan Set-AzContext -Subscription <V1 application gateway SubscriptionId> cmdlet setiap kali sebelum menjalankan skrip migrasi. Ini diperlukan untuk mengatur konteks Azure aktif ke langganan yang benar, karena skrip migrasi mungkin membersihkan grup sumber daya yang ada jika tidak ada dalam konteks langganan saat ini. Ini bukan langkah wajib untuk versi 1.0.11 & di atas skrip migrasi.

Terdapat dua pilihan untuk Anda, bergantung pada pengaturan dan preferensi lingkungan PowerShell lokal Anda:

• Jika Anda tidak memiliki modul Azure Az yang terpasang, atau tidak keberatan mencopot pemasangan modul Azure Az, maka opsi terbaik adalah menggunakan opsi Install-Script untuk menjalankan skrip.
• Jika Anda harus menyimpan modul Azure Az, maka opsi terbaiknya adalah mengunduh skrip dan menjalankannya secara langsung.

Untuk melihat apakah Anda memiliki modul Azure Az yang terpasang, jalankan Get-InstalledModule -Name az. Jika tidak ada modul Az yang terpasang, Anda dapat menggunakan metode Install-Script.

Instal menggunakan metode Install-Script (disarankan)

Untuk menggunakan opsi ini, modul Azure Az tidak boleh terpasang di komputer Anda. Jika terpasang, perintah berikut akan menampilkan kesalahan. Anda dapat mencopot pemasangan modul Azure Az, atau menggunakan opsi lain untuk mengunduh skrip secara manual dan menjalankannya.

Jalankan skrip dengan perintah berikut untuk mendapatkan versi terbaru:

Install-Script -Name AzureAppGWMigration -Force

Perintah ini juga memasang modul Az yang diperlukan.

Memasang menggunakan skrip langsung

Jika Anda memiliki beberapa modul Azure Az yang terinstal dan tidak dapat menghapus instalannya (atau tidak ingin menghapus instalasinya), Anda dapat mengunduh skrip secara manual menggunakan tab Unduh Manual di tautan unduhan skrip. Skrip akan diunduh sebagai file nupkg mentah. Untuk memasang skrip dari file nupkg ini, lihat Pengunduhan Paket Manual.

Versi 1.0.11 adalah versi baru dari skrip migrasi yang mencakup perbaikan bug utama. Disarankan untuk menggunakan versi stabil ini.

Cara memeriksa versi skrip yang diunduh

Untuk memeriksa versi skrip yang diunduh, langkah-langkahnya adalah sebagai berikut:

• Ekstrak konten paket NuGet.
• .PS1 Buka file di folder dan periksa di .VERSION bagian atas untuk mengonfirmasi versi skrip yang diunduh

<#PSScriptInfo
.VERSION 1.0.10
.GUID be3b84b4-e9c5-46fb-a050-699c68e16119
.AUTHOR Microsoft Corporation
.COMPANYNAME Microsoft Corporation
.COPYRIGHT Microsoft Corporation. All rights reserved.

• Pastikan untuk menggunakan versi stabil terbaru dari Galeri PowerShell

Cara menjalankan skrip

Untuk menjalankan skrip:

1. Gunakan Connect-AzAccount untuk tersambung ke Azure.

2. Gunakan Import-Module Az untuk mengimpor modul Az.

3. Jalankan Set-AzContext cmdlet, untuk mengatur konteks Azure aktif ke langganan yang benar. Ini adalah langkah penting karena skrip migrasi mungkin membersihkan grup sumber daya yang ada jika tidak ada dalam konteks langganan saat ini.

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

4. Jalankan Get-Help AzureAppGWMigration.ps1 untuk memeriksa parameter yang diperlukan:

   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
   

Catatan

Selama migrasi, jangan mencoba operasi lain di gateway V1 atau sumber daya terkait.

Parameter untuk skrip:

• resourceId: [String]: Diperlukan: Parameter ini adalah ID Sumber Daya Azure untuk gateway V1 atau WAF V1 Standar yang ada. Untuk menemukan nilai untai ini, pergilah ke portal Microsoft Azure, pilih sumber daya Application Gateway atau WAF Anda, dan klik link Properties untuk gateway. ID Sumber daya terletak di halaman tersebut.

  Anda juga bisa menjalankan perintah Azure PowerShell berikut ini untuk mendapatkan ID Sumber daya:

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

• subnetAddressRange: [String]: Diperlukan: Parameter ini adalah ruang alamat IP yang telah Anda alokasikan (atau ingin mengalokasikan) untuk subnet baru yang berisi gateway V2 baru Anda. Ruang alamat harus ditentukan dalam notasi CIDR. Misalnya: 10.0.0.0/24. Anda tidak perlu membuat subnet ini terlebih dahulu tetapi CIDR harus menjadi bagian dari ruang alamat VNET. Skrip membuatnya untuk Anda jika tidak ada dan jika ada, skrip menggunakan yang sudah ada (pastikan subnet kosong, hanya berisi Gateway V2 jika ada, dan memiliki IP yang tersedia yang cukup).

• appgwName: [String]: Opsional. Ini adalah string yang Anda tentukan untuk digunakan sebagai nama untuk gateway Standard_V2 atau WAF_V2 baru. Jika parameter ini tidak disediakan, nama gateway V1 Anda yang ada digunakan dengan akhiran _V2 ditambahkan.

• AppGWResourceGroupName: [String]: Opsional. Nama grup sumber daya tempat Anda ingin sumber daya Application Gateway V2 dibuat (nilai defaultnya adalah <V1-app-gw-rgname>)

Catatan

Pastikan bahwa tidak ada gateway Aplikasi dengan Nama AppGW V2 dan nama grup Sumber Daya yang disediakan dalam langganan V1. Ini menulis ulang sumber daya yang ada.

• sslCertificates: [PSApplicationGatewaySslCertificate]: Opsional. Daftar objek PSApplicationGatewaySslCertificate yang dipisahkan koma yang Anda buat untuk mewakili sertifikasi TLS/SSL dari gateway V1 Anda harus diunggah ke gateway V2 baru. Untuk setiap sertifikasi TLS/SSL yang dikonfigurasi untuk gateway V1 atau WAF V1 Standar, Anda dapat membuat objek PSApplicationGatewaySslCertificate baru melalui perintah yang New-AzApplicationGatewaySslCertificate ditunjukkan di sini. Anda memerlukan jalur ke file sertifikat TLS / SSL Anda dan kata sandinya.

  Parameter ini hanya bersifat opsional jika Anda tidak memiliki pendengar HTTPS yang dikonfigurasi untuk gateway V1 atau WAF Anda. Jika Anda memiliki setidaknya satu pengaturan perespons HTTPS, Anda harus menentukan parameter ini.

  $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
  

  Anda dapat meneruskan $mySslCert1, $mySslCert2 (berbatas koma) dalam contoh sebelumnya sebagai nilai untuk parameter ini dalam skrip.

• sslCertificates dari Keyvault: Opsional. Anda dapat mengunduh sertifikat yang disimpan di Azure Key Vault dan meneruskannya ke skrip migrasi. Untuk mengunduh sertifikat sebagai file PFX, jalankan perintah berikut. Perintah ini mengakses SecretId, lalu menyimpan konten sebagai file 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)
  

  Untuk setiap sertifikasi yang diunduh dari Keyvault, Anda dapat membuat objek PSApplicationGatewaySslCertificate baru melalui perintah New-AzApplicationGatewaySslCertificate yang ditampilkan di sini. Anda memerlukan jalur ke file sertifikat TLS / SSL Anda dan kata sandinya.

  //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]: Opsional. Daftar objek PSApplicationGatewayTrustedRootCertificate berbatas koma yang Anda buat untuk mewakili sertifikat akar tepercaya untuk autentikasi instans backend dari gateway v2 Anda.

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

  Untuk membuat daftar objek PSApplicationGatewayTrustedRootCertificate, lihat New-AzApplicationGatewayTrustedRootCertificate.

• privateIpAddress: [String]: Opsional. Alamat IP privat tertentu yang ingin Anda kaitkan ke gateway V2 baru Anda. Ini harus dari VNet yang sama dengan yang Anda alokasikan untuk gateway V2 baru Anda. Jika ini tidak ditentukan, skrip mengalokasikan alamat IP privat untuk gateway V2 Anda.

• publicIpResourceId: [String]: Opsional. ResourceId dari sumber daya alamat IP publik (SKU standar) yang ada dalam langganan Yang ingin Anda alokasikan ke gateway V2 baru. Jika nama sumber daya Ip publik disediakan, pastikan bahwa nama tersebut ada dalam status berhasil. Jika ini tidak ditentukan, skrip mengalokasikan alamat IP publik baru dalam grup sumber daya yang sama. Namanya adalah nama gateway V2 dengan -IP ditambahkan. Jika AppGWResourceGroupName disediakan dan alamat IP publik tidak disediakan, pastikan bahwa sumber daya IP publik dengan nama AppGWV2Name-IP tidak ada di grup sumber daya dengan nama AppGWResourceGroupName di langganan V1.

• validateMigration: [switch]: Opsional. Gunakan parameter ini untuk mengaktifkan skrip untuk melakukan beberapa validasi perbandingan konfigurasi dasar setelah pembuatan gateway V2 dan salinan konfigurasi. Secara default, tidak ada validasi yang dilakukan.

• enableAutoScale: [switch]: Opsional. Gunakan parameter ini untuk mengaktifkan skrip untuk mengaktifkan autoscaling pada gateway V2 baru setelah dibuat. Secara default, autoscaling dinonaktifkan. Anda selalu dapat mengaktifkannya secara manual nanti di gateway V2 yang baru dibuat.

5. Jalankan skrip menggunakan parameter yang sesuai. Butuh sekitar lima sampai tujuh menit untuk menyelesaikannya.

   Contoh

   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
   

Peringatan\Batasan

• Gateway V2 baru memiliki alamat IP publik dan privat baru. Tidak dimungkinkan untuk memindahkan alamat IP yang terkait dengan gateway V1 yang ada dengan mulus ke V2. Namun, Anda dapat mengalokasikan alamat IP publik atau privat yang sudah ada (tidak dialokasikan) ke gateway V2 baru.
• Anda harus menyediakan ruang alamat IP untuk subnet lain dalam jaringan virtual Tempat gateway V1 Anda berada. Skrip tidak dapat membuat gateway V2 di subnet yang sudah memiliki gateway V1. Jika subnet sudah memiliki gateway V2, skrip mungkin masih berfungsi, asalkan ruang alamat IP yang cukup tersedia.
• Jika Anda memiliki grup keamanan jaringan atau rute yang ditentukan pengguna yang terkait dengan subnet gateway V2, pastikan mereka mematuhi persyaratan NSG dan persyaratan UDR untuk migrasi yang berhasil
• Kebijakan titik akhir layanan jaringan virtual saat ini tidak didukung dalam subnet Application Gateway.
• Untuk memigrasikan konfigurasi TLS/SSL, Anda harus menentukan semua sertifikasi TLS/SSL yang digunakan di gateway V1 Anda.
• Jika Anda mengaktifkan mode FIPS untuk gateway V1, mode tersebut tidak dimigrasikan ke gateway V2 baru Anda. Mode FIPS tidak didukung di V2.
• Jika Anda memiliki gateway V1 ip privat saja, skrip akan menghasilkan alamat IP privat dan publik untuk gateway V2 baru. Gateway V2 khusus IP Privat saat ini dalam pratinjau publik. Setelah tersedia secara umum, pelanggan dapat menggunakan skrip untuk mentransfer ip privat mereka hanya gateway V1 ke gateway V2 ip privat saja.
• Autentikasi NTLM dan Kerberos tidak didukung oleh Application Gateway V2. Skrip tidak dapat mendeteksi apakah gateway melayani jenis lalu lintas ini dan dapat berpose sebagai perubahan yang melanggar dari gateway V1 ke V2 jika dijalankan.
• WAFv2 dibuat dalam mode konfigurasi WAF lama; diperlukan migrasi ke kebijakan WAF.

Migrasi lalu lintas

Pertama, periksa kembali apakah skrip berhasil membuat gateway V2 baru dengan konfigurasi yang tepat yang dimigrasikan dari gateway V1 Anda. Anda dapat memverifikasi hal ini dari portal Microsoft Azure.

Kirim juga sejumlah kecil lalu lintas melalui gateway V2 sebagai pengujian manual.

Berikut ini adalah beberapa skenario di mana gateway aplikasi Anda saat ini (Standar) dapat menerima lalu lintas klien, dan rekomendasi kami untuk masing-masing:

• Zona DNS kustom (misalnya, contoso.com) yang menunjuk ke alamat IP frontend (menggunakan catatan A) yang terkait dengan gateway V1 atau WAF V1 Standar Anda.

  Anda bisa memperbarui catatan DNS Anda untuk menunjuk ke IP frontend atau label DNS yang terkait dengan gateway aplikasi Standard_V2 Anda. Bergantung pada TTL yang dikonfigurasi pada catatan DNS Anda, mungkin perlu beberapa saat agar semua lalu lintas klien Anda bermigrasi ke gateway V2 baru Anda.

• Zona DNS kustom (misalnya, contoso.com) yang menunjuk ke label DNS (misalnya: myappgw.eastus.cloudapp.azure.com menggunakan data CNAME) yang terkait dengan gateway V1 Anda.

  Anda memiliki dua pilihan:

  • Jika Anda menggunakan alamat IP publik di gateway aplikasi, Anda dapat melakukan migrasi terperinci yang terkontrol menggunakan profil Traffic Manager untuk merutekan lalu lintas secara bertahap (metode perutean lalu lintas tertimbang) ke gateway V2 baru.

    Anda dapat melakukan ini dengan menambahkan label DNS gateway aplikasi V1 dan V2 ke profil Traffic Manager, dan CNAMEing catatan DNS kustom Anda (misalnya, www.contoso.com) ke domain Traffic Manager (misalnya, contoso.trafficmanager.net).

  • Atau, Anda bisa memperbarui catatan DNS domain kustom Anda untuk mengarahkan ke label DNS gateway aplikasi V2 baru. Bergantung pada TTL yang dikonfigurasi pada catatan DNS Anda, mungkin perlu beberapa saat agar semua lalu lintas klien Anda bermigrasi ke gateway V2 baru Anda.

• Klien Anda tersambung ke alamat IP frontend Application Gateway Anda.

  Perbarui klien Anda untuk menggunakan alamat IP yang terkait dengan gateway aplikasi V2 yang baru dibuat. Kami menyarankan agar Anda tidak menggunakan alamat IP secara langsung. Pertimbangkan untuk menggunakan label nama DNS (misalnya, yourgateway.eastus.cloudapp.azure.com) yang terhubung dengan application gateway Anda yang dapat Anda CNAME ke zona DNS kustom Anda sendiri (misalnya, contoso.com).

Pertimbangan harga

Model harga berbeda untuk SKU Application Gateway V1 dan V2. V2 dikenakan biaya berdasarkan konsumsi. Lihat Harga Application Gateway sebelum bermigrasi untuk informasi harga.

Panduan efisiensi biaya

SKU V2 hadir dengan berbagai keunggulan seperti peningkatan performa 5x, peningkatan keamanan dengan integrasi Key Vault, pembaruan aturan keamanan yang lebih cepat di WAF_V2, aturan Kustom WAF, Asosiasi kebijakan, dan perlindungan Bot. Ini juga menawarkan skalabilitas tinggi, perutean lalu lintas yang dioptimalkan, dan integrasi yang mulus dengan layanan Azure. Fitur-fitur ini dapat meningkatkan pengalaman pengguna secara keseluruhan, mencegah perlambatan selama waktu lalu lintas yang padat, dan menghindari pelanggaran data yang mahal.

Ada lima varian yang tersedia di V1 SKU berdasarkan Tingkat dan Ukuran - Standard_Small, Standard_Medium, Standard_Large, WAF_Medium, dan WAF_Large.

SKU	Harga Tetap V1/mo	Harga Tetap V2/mo	Rekomendasi
Sedang Standar	102.2	179.8	V2 SKU dapat menangani sejumlah besar permintaan daripada gateway V1, jadi sebaiknya konsolidasikan beberapa gateway V1 ke dalam satu gateway V2, untuk mengoptimalkan biaya. Pastikan bahwa konsolidasi tidak melebihi batas Application Gateway. Kami merekomendasikan konsolidasi 3:1.
WAF Sedang	183.96	262.8	Sama seperti untuk Media Standar
Standar Besar	467.2	179.58	Untuk varian ini, dalam kebanyakan kasus, pindah ke gateway V2 dapat memberi Anda manfaat harga yang lebih baik dibandingkan dengan V1.
WAF Besar	654.08	262.8	Sama seperti untuk Standar Besar

Catatan

Perhitungan yang ditampilkan di sini didasarkan pada US Timur dan untuk gateway dengan 2 instans di V1. Biaya variabel di V2 didasarkan pada salah satu dari 3 dimensi dengan penggunaan tertinggi: Koneksi baru (50/detik), Koneksi persisten (2500 koneksi persisten/menit), Throughput (1 CU dapat menangani 2,22 Mbps).

Skenario yang dijelaskan di sini adalah contoh dan hanya untuk tujuan ilustrasi. Untuk informasi harga sesuai wilayah Anda, lihat halaman Harga.

Untuk masalah lebih lanjut mengenai harga, bekerja dengan CSAM Anda atau hubungi tim dukungan kami untuk mendapatkan bantuan.

Pertanyaan umum

Pertanyaan umum tentang migrasi dapat ditemukan di sini

Langkah berikutnya

Pelajari tentang Application Gateway V2