Merge pull request #307316 from MicrosoftDocs/main

Auto Publish – main to live - 2025-10-23 22:00 UTC

Author: learn-build-service-prod[bot]

articles/azure-vmware/native-introduction.md

@@ -62,6 +62,8 @@ Gen 2 is available in the following Azure public regions.
 
 - UK West
 
+- West US 2
+
 Beyond these regions, SLAs are region specific. Contact your Microsoft account team or Microsoft Support to confirm coverage.
 
 ## Next steps

articles/container-apps/environment.md

@@ -92,7 +92,7 @@ You can monitor the status of your environments through Azure Monitor alerts or
 
 Understanding the limits and quotas for Container Apps environments helps you plan your application architecture effectively.
 
-To see the quotas relevant to your environment, see [Quotas in Azure Container Apps](./quotas.md) for ways to return your quota limits.
+To see the quotas relevant to your environment, see [Quotas for Azure Container Apps](./quotas.md) for ways to return your quota limits.
 
 For the most up-to-date limits and quotas, refer to the [Azure Container Apps service limits](/azure/azure-resource-manager/management/azure-subscription-service-limits#container-apps-limits).
 

articles/data-factory/introduction.md

@@ -54,7 +54,8 @@ This visual guide provides a detailed overview of the complete Data Factory arch
 
 :::image type="content" source="media\introduction\data-factory-visual-guide-small.png" alt-text="A detailed visual guide to the complete system architecture for Azure Data Factory, presented in a single high resolution image." lightbox="media\introduction\data-factory-visual-guide.png":::
 
-To see more detail, select the preceding image to zoom in, or browse to the [high resolution image](/azure/data-factory/media/introduction/data-factory-visual-guide.png). 
+To see more detail, select the preceding image to zoom in, or browse to the [high resolution image](/azure/data-factory/media/introduction/data-factory-visual-guide.png).
+Learn about the [development of this visual guide and the sketch the docs project here](https://dev.to/azure/a-visual-guide-to-azure-data-factory-53ik).
 
 ### Connect and collect
 

articles/expressroute/gateway-migration.md

@@ -42,8 +42,12 @@ For enhanced reliability and high availability, we recommend migrating to an Az-
 ### Migrate to ErGwScale (Scalable Gateway)
 The ExpressRoute Scalable Gateway (ErGwScale) is a new virtual network gateway SKU that provides flexible, high-bandwidth connectivity for your Azure virtual networks.
 
-You can configure the gateway's performance by setting the minimum and maximum scale units between **1** and **40**:
-- To configure a fixed-size gateway, set both the **minimum** and **maximum** scale units to the same value (for example, set both to **1**).
+> [!IMPORTANT]
+>The minimum scale unit must be 1, when the maximum scale unit is 1.
+
+
+You can configure the gateway's scaling, as per requirements, by setting the minimum and maximum scale units:
+- To configure a fixed-size gateway, set both the **minimum** and **maximum** scale units to the same value (for example, set both to **1**, set both to **20**, set both to **40**).
 - To enable autoscaling, set the **minimum scale unit** to **2** or higher, and specify the desired **maximum scale unit** (up to 40).
 
 This allows the gateway to automatically scale based on your workload requirements.
@@ -52,7 +56,9 @@ For more information, see [About Scalable Gateway](scalable-gateway.md).
 
 | Scenario              | Minimum Scale Unit | Maximum Scale Unit | Autoscaling Enabled? |
 |-----------------------|-------------------|-------------------|---------------------|
-| Fixed size            | 1                 | 1                 | No                  |
+| Fixed scaling         | 1                 | 1                 | No                  |
+| Fixed scaling         | 20                | 20                | No                  |  
+| Fixed scaling         | 40                | 40                | No                  |  
 | Autoscaling           | 2 or higher       | Up to 40          | Yes                 |
 
 ## Steps to migrate to a new gateway

articles/expressroute/scalable-gateway.md

@@ -19,12 +19,32 @@ The ExpressRoute scalable gateway (ErGwScale) is a new virtual network gateway S
 
 The virtual network gateway infrastructure autoscales between the minimum and maximum scale unit that you configure, based on the bandwidth or flow count utilization. Scale operations might take up to 30 minutes to complete. If you want to achieve a fixed connectivity at a specific bandwidth value, you can configure a fixed scale unit by setting the minimum scale unit and the maximum scale unit to the same value.
 
+## Upgrade and migration paths
+
+You can move to the Scalable Gateway SKU using either an upgrade or migration process, depending on your current gateway SKU. The following diagram summarizes your options:
+
+```mermaid
+flowchart TD
+    A[Current Gateway SKU]
+    A -->|ErGw1, ErGw2, ErGw3| B[Direct Upgrade - Portal or PowerShell]
+    A -->|Standard, High Performance, Ultra Performance| C[ExpressRoute Gateway Migration Tool]
+    B --> D[Scalable Gateway SKU]
+    C --> D
+```
+**Upgrade options**
+- If you have an existing gateway using the ErGw1, ErGw2, or ErGw3 SKU, you can [upgrade](expressroute-howto-add-gateway-portal-resource-manager.md#upgrade-the-gateway-sku) directly to the Scalable Gateway SKU. No migration tool is required.
+- Upgrades can be performed through the Azure portal or by using PowerShell.
+
+This process may take up to 2 hours to complete. During this time, the gateway remains available and does not experience downtime.
+
+**Migration options**
+- If your gateway uses the Standard, High Performance, or Ultra Performance SKU, you must use the [migration Tool](gateway-migration.md) to move to the Scalable Gateway SKU.
+
 ## Limitations
 
+* **IPsec over ExpressRoute**: ErGwScale currently doesn't support IPsec traffic over ExpressRoute. 
 * **Basic IP**: ErGwScale doesn't support the Basic IP SKU. You need to use a Standard IP SKU to configure ErGwScale.
 * **Minimum and maximum scale units**: You can configure the scale unit for ErGwScale between 1 and 40. The *minimum scale unit* can't be lower than 1 and the *maximum scale unit* can't be higher than 40.
-* **Migration scenarios**: You can't migrate from Standard/ErGw1Az or HighPerf/ErGw2Az/UltraPerf/ErGw3Az to ErGwScale in the preview.
-* **IPsec over ExpressRoute**: ErGwScale currently doesn't support IPsec traffic over ExpressRoute. 
 
 ### Supported performance per scale unit
 

articles/firewall/tcp-session-behavior.md

@@ -61,6 +61,20 @@ Certain applications, such as traditional SAP GUI and SAP Remote Function Call (
 > [!NOTE]
 > If you're running SAP workloads through an Azure Firewall, test your configuration and review the [SAP design documentation](/azure/sap/workloads/deployment-checklist?tabs=pilot#pilot-phase-strongly-recommended) to ensure a successful Azure deployment.
 
+### TCP reset behavior during scale-in events
+
+When Azure Firewall scales in, it enters a drain mode for 90 seconds before an underlying firewall instance is recycled: 
+
+- **First 45 seconds:** The firewall stops accepting new connections but allows existing connections to continue without sending TCP reset packets.
+- **Next 45 seconds:** The firewall sends TCP RST packets to all active session flows to ensure clean termination before recycling. These resets inform both the client and the server that the connection is closing cleaning, so neither side hangs indefinitely waiting for packets that will not arrive once the underlying instance is decommissioned.
+    - To ensure that both client and server endpoints promptly detect these resets, configure a **bi-directional TCP keep-alive messages at 30-second intervals**. Keep-alive probes generate periodic traffic even when no application data is exchanged, helping both sides detect connection closure in real time and avoid half-open sessions - cases where one side believes the connection is still alive after the other side has closed it. This configuration allows applications to gracefully recover connections when a firewall instance is recycled during scale-in.
+    - If a 30-second keep-alive interval is not feasible, consider configuring [prescaling](/azure/firewall/prescaling) to maintain a higher minimum capacity, reducing the likelihood of scale-in events that could disrupt long-running connections. 
+
+This scale-in TCP reset behavior applies for both north-south and east-west traffic. It ensures clients and servers are properly notified before the firewall instance is decommissioned. The drain period and reset behavior are not configurable during scale-in events.
+
+> [!NOTE]
+> TCP reset behavior during scale-in differs from idle timeout behavior. For idle timeout, RST packets are sent only for north-south traffic, while during scale-in, RST packets are sent for both north-south and east-west traffic.
+
 ## Next steps
 
 To learn more about Azure Firewall performance, see [Azure Firewall performance](firewall-performance.md).