resize gateway

Author: cherylmc

articles/vpn-gateway/tutorial-create-gateway-portal.md

@@ -6,7 +6,7 @@ author: cherylmc
 ms.author: cherylmc
 ms.service: azure-vpn-gateway
 ms.topic: tutorial
-ms.date: 03/10/2025
+ms.date: 06/24/2025
 
 ---
 
@@ -26,7 +26,7 @@ In this tutorial, you learn how to:
 > * Create a virtual network.
 > * Create an active-active mode zone-redundant VPN gateway.
 > * View the gateway public IP address.
-> * Resize a VPN gateway (resize SKU).
+> * Upgrade a VPN gateway SKU.
 > * Reset a VPN gateway.
 
 > [!NOTE]
@@ -68,12 +68,12 @@ To view public IP addresses associated to your virtual network gateway, navigate
 1. On the **Virtual network gateway** portal page, under **Settings**, open the **Properties** page.
 1. To view more information about the IP address object, click the associated IP address link.
 
-## <a name="resize"></a>Resize a gateway SKU
+## <a name="resize"></a>Upgrade a gateway SKU
 
-There are specific rules for resizing versus changing a gateway SKU. In this section, you resize the SKU. For more information, see [Resize or change gateway SKUs](about-gateway-skus.md#resizechange).
+There are specific rules for upgrading a gateway SKU. Not all SKUs can be upgraded. For more information, see [Upgrade a gateway SKU](gateway-sku-upgrade.md).
 
 1. Go to the **Configuration** page for your virtual network gateway.
-1. On the right side of the page, select the dropdown arrow to show a list of available SKUs. Notice that the list only populates SKUs that you're able to use to resize your current SKU. If you don't see the SKU you want to use, instead of resizing, you have to change to a new SKU.
+1. On the right side of the page, select the dropdown arrow to show a list of available SKUs. Notice that the list only populates SKUs that you're able to select.
 1. Select the SKU from the dropdown list and save your changes.
 
 ## <a name="reset"></a>Reset a gateway

articles/vpn-gateway/tutorial-site-to-site-portal.md

@@ -6,7 +6,7 @@ author: cherylmc
 ms.author: cherylmc
 ms.service: azure-vpn-gateway
 ms.topic: tutorial
-ms.date: 01/15/2025
+ms.date: 06/24/2025
 
 #customer intent: As a network engineer, I want to create a site-to-site VPN connection between my on-premises location and my Azure virtual network.
 ---
@@ -171,9 +171,9 @@ You can specify a different shared key for your connection.
 1. Save your changes.
 1. Update your VPN device with the new shared key as necessary.
 
-### <a name="resize"></a>Resize or change a gateway SKU
+### <a name="resize"></a>Upgrade a gateway SKU
 
-You can resize a gateway SKU, or you can change the gateway SKU. There are specific rules regarding which option is available, depending on the SKU your gateway is currently using. For more information, see [Resize or change gateway SKUs](about-gateway-skus.md#resizechange).
+You can upgrade the SKU of your VPN gateway to a different SKU. There are rules regarding which SKUs are available for upgrade. For more information, see [Upgrade a gatewway SKU](gateway-sku-upgrade.md).
 
 ### <a name="additional"></a>More configuration considerations
 

articles/vpn-gateway/vpn-gateway-about-skus-legacy.md

@@ -4,7 +4,7 @@ description: How to work with the old virtual network gateway SKUs; Standard, an
 author: cherylmc
 ms.service: azure-vpn-gateway
 ms.topic: how-to
-ms.date: 06/23/2025
+ms.date: 06/24/2025
 ms.author: cherylmc
 
 #customer intent: As an Azure administrator, I want to understand the legacy SKU deprecation timeline so that I can plan for the automatic migration.
@@ -59,17 +59,17 @@ The UltraPerformance gateway SKU isn't represented in this table. For informatio
 
 ### <a name="migrate"></a>Migrate a gateway SKU
 
-A gateway SKU migration process is similar to a resize. It requires fewer steps and configuration changes than changing to a new gateway SKU. Your gateway will be migrated seamlessly from backend without any connectivity impact before September 30, 2025. This is different from the initial approach of providing a migration path.
+Your legacy gateway will be migrated seamlessly from backend without any connectivity impact before September 30, 2025. This is different from the initial approach of providing a migration path.
 
-### <a name="resize"></a>Resize to a gateway SKU in the same SKU family
+### <a name="resize"></a>Upgrade to a gateway SKU in the same SKU family
 
-Resizing a gateway SKU incurs less downtime and fewer configuration changes than the process to change to a new SKU. However, there are limitations. You can only resize your gateway to a gateway SKU within the same SKU family (except for the Basic SKU).
+Upgrading a legacy SKU has limitations. You can only upgrade your gateway to a gateway SKU within the same SKU family (except for the Basic SKU).
 
-For example, if you have a Standard SKU, you can resize to a High Performance SKU. However, you can't resize your VPN gateway between the old SKUs and the new SKU families. You can't go from a Standard SKU to a VpnGw2 SKU, or from a Basic SKU to VpnGw1 by resizing.
+For example, if you have a Standard SKU, you can upgrade to a High Performance SKU. However, you can't upgrade your VPN gateway between the old SKUs and the new SKU families. You can't go from a Standard SKU to a VpnGw2 SKU, or from a Basic SKU to VpnGw1 by resizing.
 
 **Resource Manager**
 
-You can resize a gateway for the [Resource Manager deployment model](../azure-resource-manager/management/deployment-models.md) using the Azure portal or PowerShell. For PowerShell, use the following command:
+You can upgrade a gateway for the [Resource Manager deployment model](../azure-resource-manager/management/deployment-models.md) using the Azure portal or PowerShell. For PowerShell, use the following command:
 
 ```powershell
 $gw = Get-AzVirtualNetworkGateway -Name vnetgw1 -ResourceGroupName testrg
@@ -78,7 +78,7 @@ Resize-AzVirtualNetworkGateway -VirtualNetworkGateway $gw -GatewaySku HighPerfor
 
 **Classic**
 
-To resize a gateway for the [classic deployment model](../azure-resource-manager/management/deployment-models.md), you must use the Service Management PowerShell cmdlets. Use the following command:
+To upgrade a gateway for the [classic deployment model](../azure-resource-manager/management/deployment-models.md), you must use the Service Management PowerShell cmdlets. Use the following command:
 
 ```powershell
 Resize-AzureVirtualNetworkGateway -GatewayId <Gateway ID> -GatewaySKU HighPerformance
@@ -92,7 +92,7 @@ Standard and High Performance SKUs will be deprecated September 30, 2025. The pr
 
 ## SKU deprecation
 
-The Standard and High Performance SKUs will be deprecated on September 30, 2025. The product team will do backend seamless migration for these SKUs starting June 2025. This is a change from originally announced November 2024 date **At this time, there's no action that you need to take**.
+The Standard and High Performance SKUs will be deprecated on September 30, 2025. The product team will initiate backend seamless migration for these SKUs starting June 2025. This is a change from originally announced November 2024 date **At this time, there's no action that you need to take**.
 
 * View the [Announcement](https://go.microsoft.com/fwlink/?linkid=2255127)
 * See the SKU deprecation [FAQs](#sku-deprecation-faqs)

articles/vpn-gateway/vpn-gateway-validate-throughput-to-vnet.md

@@ -7,7 +7,7 @@ manager: dcscontentpm
 ms.service: azure-vpn-gateway
 ms.custom: linux-related-content
 ms.topic: troubleshooting
-ms.date: 03/31/2025
+ms.date: 06/24/2025
 ms.author: radwiv
 ms.reviewer: chadmat;genli
 ---
@@ -42,7 +42,7 @@ The following diagram shows the logical connectivity of an on-premises network t
 1. Determine your Internet Service Provider (ISP) bandwidth.
 1. Calculate your expected throughput by taking the least bandwidth of either the VM, VPN Gateway, or ISP; which is measured in Megabits-per-second (/) divided by eight (8). This calculation gives you Megabytes-per-second.
 
-If your calculated throughput doesn't meet your application's baseline throughput requirements, you must increase the bandwidth of the resource that you identified as the bottleneck. To resize an Azure VPN Gateway, see [Changing a gateway SKU](vpn-gateway-about-vpn-gateway-settings.md#gwsku). To resize a virtual machine, see [Resize a VM](/azure/virtual-machines/resize-vm). If you aren't experiencing the expected Internet bandwidth, you may also contact your ISP.
+If your calculated throughput doesn't meet your application's baseline throughput requirements, you must increase the bandwidth of the resource that you identified as the bottleneck. To upgrade an Azure VPN Gateway, see [Upgrade a gateway SKU](gateway-sku-upgrade.md). To resize a virtual machine, see [Resize a VM](/azure/virtual-machines/resize-vm). If you aren't experiencing the expected Internet bandwidth, you can also contact your ISP.
 
 > [!NOTE]
 > VPN Gateway throughput is an aggregate of all Site-to-Site\VNET-to-VNET, or Point-to-Site connections.
@@ -51,7 +51,7 @@ If your calculated throughput doesn't meet your application's baseline throughpu
 
 This validation should be performed during nonpeak hours, as VPN tunnel throughput saturation during testing doesn't give accurate results.
 
-The tool we use for this test is iPerf, which works on both Windows and Linux and has both client and server modes. It is limited to 3 Gbps for Windows VMs.
+The tool we use for this test is iPerf, which works on both Windows and Linux and has both client and server modes. It's limited to 3 Gbps for Windows VMs.
 
 This tool doesn't perform any read/write operations to disk. It solely produces self-generated TCP traffic from one end to the other. It generates statistics based on experimentation that measures the bandwidth available between client and server nodes. When testing between two nodes, one node acts as the server, and the other node acts as a client. Once this test is completed, we recommend that you reverse the roles of the nodes to test both upload and download throughput on both nodes.
 
@@ -80,7 +80,7 @@ Download [iPerf](https://iperf.fr/download/iperf_3.1/iperf-3.1.2-win64.zip). For
    netsh advfirewall firewall delete rule name="Open Port 5001" protocol=TCP localport=5001
    ```
 
-   **Azure Linux:** Azure Linux images have permissive firewalls. If there's an application listening on a port, the traffic is allowed through. Custom images that are secured may need ports opened explicitly. Common Linux OS-layer firewalls include `iptables`, `ufw`, or `firewalld`.
+   **Azure Linux:** Azure Linux images have permissive firewalls. If there's an application listening on a port, the traffic is allowed through. Custom images that are secured might need ports opened explicitly. Common Linux OS-layer firewalls include `iptables`, `ufw`, or `firewalld`.
 
 1. On the server node, change to the directory where iperf3.exe is extracted. Then run iPerf in server mode, and set it to listen on port 5001 as the following commands:
 
@@ -124,7 +124,7 @@ Download the latest version of [Latte.exe](https://github.com/microsoft/latte/re
 
 Consider putting Latte.exe in separate folder, such as `c:\tools`
 
-### Allow Latte.exe through the Windows firewall
+### Allow Latte.exe through the Windows Firewall
 
 On the receiver, create an Allow rule on the Windows Firewall to allow the Latte.exe traffic to arrive. It's easiest to allow the entire Latte.exe program by name rather than to allow specific TCP ports inbound.
 
@@ -192,7 +192,7 @@ From bash command line (assumes git is installed)
 `./autogen.sh`
 `./configure --prefix=`
 
-Make is slower, may take several minutes
+Make is slower, and might take several minutes
 
 `make`
 
@@ -214,11 +214,11 @@ Make install is fast
 > Make sure there are no intermediate hops (e.g. Virtual Appliance) during the throughput testing in between the VM and Gateway.
 > If there are poor results (in terms of overall throughput) coming from the iPERF/NTTTCP tests above, please refer to [this article](../virtual-network/virtual-network-tcpip-performance-tuning.md) to understand the key factors behind the possible root causes of the problem:
 
-In particular, analysis of packet capture traces (Wireshark/Network Monitor) collected in parallel from client and server during those tests help in the assessments of bad performance. These traces can include packet loss, high latency, MTU size. fragmentation, TCP 0 Window, Out of Order fragments, and so on.
+In particular, analysis of packet capture traces (Wireshark/Network Monitor) collected in parallel from client and server during those tests help in the assessments of bad performance. These traces can include packet loss, high latency, MTU size. Fragmentation, TCP 0 Window, Out of Order fragments, and so on.
 
 ## Address slow file copy issues
 
-Even if the overall throughput assessed with the previous steps (iPERF/NTTTCP/etc.) was good, you may experience slow file coping when either using Windows Explorer, or dragging and dropping through an RDP session. This problem is normally due to one or both of the following factors:
+Even if the overall throughput assessed with the previous steps (iPERF/NTTTCP/etc.) was good, you might experience slow file coping when either using Windows Explorer, or dragging and dropping through an RDP session. This problem is normally due to one or both of the following factors:
 
 * File copy applications, such as Windows Explorer and RDP, don't use multiple threads when copying files. For better performance, use a multi-threaded file copy application such as [Richcopy](/previous-versions/technet-magazine/dd547088(v=msdn.10)) to copy files by using 16 or 32 threads. To change the thread number for file copy in Richcopy, click **Action** > **Copy options** > **File copy**.
 
@@ -232,15 +232,15 @@ Even if the overall throughput assessed with the previous steps (iPERF/NTTTCP/et
 
 ## On-premises device external facing interface
 
-Mentioned the subnets of on-premises ranges that you would like Azure to reach via VPN on Local Network Gateway. Simultaneously, define the VNET address space in Azure to the on-premises device.
+Mentioned the subnets of on-premises ranges that you would like Azure to reach via VPN on Local Network Gateway. Simultaneously, define the virtual network address space in Azure to the on-premises device.
 
 * **Route Based Gateway**: The policy or traffic selector for route-based VPNs are configured as any-to-any (or wild cards).
 
 * **Policy Based Gateway**: Policy-based VPNs encrypt and direct packets through IPsec tunnels based on the combinations of address prefixes between your on-premises network and the Azure VNet. The policy (or Traffic Selector) is usually defined as an access list in the VPN configuration.
 
 * **UsePolicyBasedTrafficSelector** connections: ("UsePolicyBasedTrafficSelectors" to $True on a connection configures the Azure VPN gateway to connect to policy-based VPN firewall on premises. If you enable PolicyBasedTrafficSelectors, you need to ensure your VPN device has the matching traffic selectors defined with all combinations of your on-premises network (local network gateway) prefixes to and from the Azure virtual network prefixes, instead of any-to-any.
 
-Inappropriate configuration may lead to frequent disconnects within the tunnel, packet drops, bad throughput, and latency.
+Inappropriate configuration might lead to frequent disconnects within the tunnel, packet drops, bad throughput, and latency.
 
 ## Check latency
 
@@ -252,7 +252,7 @@ You can check latency by using the following tools:
 
 ![Check Latency](./media/vpn-gateway-validate-throughput-to-vnet/08checkinglatency.png)
 
-If you notice a high latency spike at any of the hops before entering MS Network backbone, you may want to proceed with further investigations with your Internet Service Provider.
+If you notice a high latency spike at any of the hops before entering MS Network backbone, you might want to proceed with further investigations with your Internet Service Provider.
 
 If a large, unusual latency spike is noticed from hops within "msn.net", contact MS support for further investigations.
 

articles/vpn-gateway/vpn-gateway-vpn-faq.md

@@ -146,7 +146,7 @@ Azure Standard SKU public IP resources must use a static allocation method. You
 
 Standard SKU public IP address resources use a static allocation method. Going forward, you must use a Standard SKU public IP address when you create a new VPN gateway. This requirement applies to all gateway SKUs except the Basic SKU. The Basic SKU currently supports only Basic SKU public IP addresses. We're working on adding support for Standard SKU public IP addresses for the Basic SKU.
 
-For non-zone-redundant and non-zonal gateways that were previously created (gateway SKUs that don't have *AZ* in the name), dynamic IP address assignment is supported but is being phased out. When you use a dynamic IP address, the IP address doesn't change after it's assigned to your VPN gateway. The only time that the VPN gateway IP address changes is when the gateway is deleted and then re-created. The public IP address doesn't change when you resize, reset, or complete other internal maintenance and upgrades of your VPN gateway.
+For non-zone-redundant and non-zonal gateways that were previously created (gateway SKUs that don't have *AZ* in the name), dynamic IP address assignment is supported but is being phased out. When you use a dynamic IP address, the IP address doesn't change after it's assigned to your VPN gateway. The only time that the VPN gateway IP address changes is when the gateway is deleted and then re-created. The public IP address doesn't change when you upgrade (resize), reset, or complete other internal maintenance and upgrades of your VPN gateway.
 
 ### How does the retirement of Basic SKU public IP addresses affect my VPN gateways?