Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into us543898-nat-ip-v2-preview-remove

# Conflicts:
#	articles/nat-gateway/nat-availability-zones.md

Author: asudbring

.openpublishing.redirection.json

@@ -6659,6 +6659,11 @@
       "source_path": "articles/reliability/migrate-load-balancer.md",
       "redirect_url": "/azure/reliability/reliability-load-balancer",
       "redirect_document_id": false
+    },
+    {
+      "source_path": "articles/nat-gateway/nat-availability-zones.md",
+      "redirect_url": "/azure/reliability/reliability-nat-gateway",
+      "redirect_document_id": false
     }
   ]
 }

articles/api-management/api-management-gateways-overview.md

@@ -16,7 +16,7 @@ ms.author: danlep
 
 [!INCLUDE [api-management-availability-all-tiers](../../includes/api-management-availability-all-tiers.md)]
 
-This article provides information about the roles and features of the API Management *gateway* component and compares the gateways you can deploy.
+This article describes the roles and features of the API Management *gateway* component. It also compares the gateways you can deploy.
 
 Related information:
 
@@ -34,21 +34,21 @@ The API Management *gateway* (also called *data plane* or *runtime*) is the serv
 
 
 > [!NOTE]
-> All requests to the API Management gateway, including those rejected by policy configurations, count toward configured rate limits, quotas, and billing limits if applied in the service tier. 
+> All requests to the API Management gateway, including those rejected by policy configurations, count toward configured rate limits, quotas, and billing limits if the service tier applies them. 
 
 
-## Managed and self-hosted
+## Managed and self-hosted gateways
 
 API Management offers both managed and self-hosted gateways:
 
-* **Managed** - The managed gateway is the default gateway component that is deployed in Azure for every API Management instance in every service tier. A standalone managed gateway can also be associated with a [workspace](workspaces-overview.md) in an API Management instance. With the managed gateway, all API traffic flows through Azure regardless of where backends implementing the APIs are hosted. 
+* **Managed** - The managed gateway is the default gateway component that Azure deploys for every API Management instance in every service tier. You can also associate a standalone managed gateway with a [workspace](workspaces-overview.md) in an API Management instance in select service tiers. By using the managed gateway, all API traffic flows through Azure regardless of where backends implementing the APIs are hosted.  
 
     > [!NOTE]
     > Because of differences in the underlying service architecture, the gateways provided in the different API Management service tiers have some differences in capabilities. For details, see the section [Feature comparison: Managed versus self-hosted gateways](#feature-comparison-managed-versus-self-hosted-gateways).
     >    
  
 
-* **Self-hosted** - The [self-hosted gateway](self-hosted-gateway-overview.md) is an optional, containerized version of the default managed gateway that is available in select service tiers. It's useful for hybrid and multicloud scenarios where there's a requirement to run the gateways off of Azure in the same environments where API backends are hosted. The self-hosted gateway enables customers with hybrid IT infrastructure to manage APIs hosted on-premises and across clouds from a single API Management service in Azure. 
+* **Self-hosted** - The [self-hosted gateway](self-hosted-gateway-overview.md) is an optional, containerized version of the default managed gateway that's available in select service tiers. It's useful for hybrid and multicloud scenarios where there's a requirement to run the gateways off of Azure in the same environments where API backends are hosted. The self-hosted gateway enables customers with hybrid IT infrastructure to manage APIs hosted on-premises and across clouds from a single API Management service in Azure. 
 
     * The self-hosted gateway is [packaged](self-hosted-gateway-overview.md#packaging) as a Linux-based Docker container and is commonly deployed to Kubernetes, including to [Azure Kubernetes Service](how-to-deploy-self-hosted-gateway-azure-kubernetes-service.md) and [Azure Arc-enabled Kubernetes](how-to-deploy-self-hosted-gateway-azure-arc.md).
 
@@ -66,7 +66,7 @@ The following tables compare features available in the following API Management
 
 > [!NOTE]
 > * Some features of managed and self-hosted gateways are supported only in certain [service tiers](api-management-features.md) or with certain [deployment environments](self-hosted-gateway-overview.md#packaging) for self-hosted gateways.
-> * For the current supported features of the self-hosted gateway, ensure that you have upgraded to the latest major version of the self-hosted gateway [container image](self-hosted-gateway-overview.md#container-images).
+> * To see the current supported features of the self-hosted gateway, make sure you upgraded to the latest major version of the self-hosted gateway [container image](self-hosted-gateway-overview.md#container-images).
 > * See also self-hosted gateway [limitations](self-hosted-gateway-overview.md#limitations).
 
 ### Infrastructure
@@ -90,7 +90,7 @@ The following tables compare features available in the following API Management
 
 <sup>1</sup> Depends on how the gateway is deployed, but is the responsibility of the customer.<br/>
 <sup>2</sup> Connectivity to the self-hosted gateway v2 [configuration endpoint](self-hosted-gateway-overview.md#fqdn-dependencies) requires DNS resolution of the endpoint hostname.<br/>
-<sup>3</sup> CA root certificates for self-hosted gateway are managed separately per gateway<br/>
+<sup>3</sup> CA root certificates for self-hosted gateway are managed separately per gateway.<br/>
 <sup>4</sup> Client protocol needs to be enabled.<br/>
 <sup>5</sup> Configure using the [forward-request](forward-request-policy.md) policy.<br/>
 <sup>6</sup> Configure CA certificate details for backend certificate authentication in [backend](backends.md) settings.
@@ -154,7 +154,7 @@ For details about monitoring options, see [Observability in Azure API Management
 | [Request tracing](api-management-howto-api-inspector.md) | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
 
 <sup>1</sup> The v2 tiers support Azure Monitor-based analytics.<br/>
-<sup>2</sup> Gateway uses [Azure Application Insight's built-in memory buffer](/azure/azure-monitor/app/telemetry-channels#built-in-telemetry-channels) and does not provide delivery guarantees.<br/>
+<sup>2</sup> Gateway uses [Azure Application Insight's built-in memory buffer](/azure/azure-monitor/app/telemetry-channels#built-in-telemetry-channels) and doesn't provide delivery guarantees.<br/>
 <sup>3</sup> The self-hosted gateway currently doesn't send resource logs (diagnostic logs) to Azure Monitor. Optionally [send metrics](how-to-configure-cloud-metrics-logs.md) to Azure Monitor, or [configure and persist logs locally](how-to-configure-local-metrics-logs.md) where the self-hosted gateway is deployed.<br/>
 
 ### Authentication and authorization
@@ -169,17 +169,17 @@ Managed and self-hosted gateways support all available [API authentication and a
 ## Gateway throughput and scaling
 
 > [!IMPORTANT]
-> Throughput is affected by the number and rate of concurrent client connections, the kind and number of configured policies, payload sizes, backend API performance, and other factors. Self-hosted gateway throughput is also dependent on the compute capacity (CPU and memory) of the host where it runs. Perform gateway load testing using anticipated production conditions to determine expected throughput accurately.
+> Throughput depends on many factors, including the number and rate of concurrent client connections, the kind and number of configured policies, payload sizes, backend API performance, and other factors. Self-hosted gateway throughput also depends on the compute capacity (CPU and memory) of the host where it runs. To accurately determine expected throughput, perform gateway load testing by using anticipated production conditions.
 
 ### Managed gateway
 
 For estimated maximum gateway throughput in the API Management service tiers, see [API Management pricing](https://azure.microsoft.com/pricing/details/api-management/).
 
 > [!IMPORTANT]
-> Throughput figures are presented for information only and must not be relied upon for capacity and budget planning. See [API Management pricing](https://azure.microsoft.com/pricing/details/api-management/) for details.
+> Use the throughput figures for information only. Don't rely on them for capacity and budget planning. See [API Management pricing](https://azure.microsoft.com/pricing/details/api-management/) for details.
 
 * **Classic tiers**
-    * Scale gateway capacity by adding and removing scale [units](upgrade-and-scale.md), or upgrade the service tier. (Scaling not available in the Developer tier.)
+    * Scale gateway capacity by adding and removing scale [units](upgrade-and-scale.md), or upgrade the service tier. (Scaling isn't available in the Developer tier.)
     * In the Basic, Standard, and Premium tiers, optionally configure [Azure Monitor autoscale](api-management-howto-autoscale.md).
     * In the Premium tier, optionally add and distribute gateway capacity across multiple [regions](api-management-howto-deploy-multi-region.md).
 
@@ -198,6 +198,19 @@ For estimated maximum gateway throughput in the API Management service tiers, se
 
 Scale capacity by adding and removing scale [units](upgrade-and-scale.md) in the workspace gateway.
 
+## Gateway health check endpoint
+
+In all tiers except the Consumption tier, Azure API Management provides a built-in gateway health check endpoint at path `/status-0123456789abcdef`. Reach this endpoint to help confirm that the API gateway is available and functioning correctly. It doesn't test backend APIs, only the gateway itself.
+
+A request to the endpoint returns a `200 OK` HTTP response when the gateway is healthy; failures indicate networking or gateway issues.  
+
+* Azure uses this endpoint internally for continuous SLA monitoring and gateway health validation.
+* Customers can integrate requests to this endpoint into their own monitoring tools and probes.
+* The endpoint is available for managed gateways (including regional gateways in multi-region deployments), self-hosted gateways, and workspace gateways. 
+
+> [!TIP]
+> When you [integrate Azure Application Insights](api-management-howto-app-insights.md) with API Management, you can optionally enable availability monitoring of the gateway. This setting regularly polls the gateway health check endpoint and reports results on the **Availability** tab in Application Insights.
+
 ## Related content
 
 Learn more about:

articles/app-service/includes/configure-azure-storage/azure-storage-linux-container-pivot.md

@@ -203,6 +203,46 @@ To validate that the Azure Storage is mounted successfully for the app:
    tcpping Storageaccount.file.core.windows.net 
    ```
 
+### Storage mount health checks and auto‑recovery
+
+Azure App Service includes a built‑in health‑check mechanism to ensure that mounted Azure Storage volumes (Azure Files or Azure Blob) remain accessible and responsive. This system helps prevent application hangs caused by stale or disconnected storage mounts.
+
+#### How the health check works
+
+1. **Periodic I/O test**  
+   App Service periodically performs file I/O on a marker file named `__lastCheckTime.txt`.  
+   - **Location:** A `LogFiles` subdirectory under the mounted path (for example, `/mount/path/LogFiles/__lastCheckTime.txt`).  
+   - **Behavior:**  
+     - A read operation is attempted on this file.  
+     - The file does *not* need to exist—“file not found” is treated as a successful check.
+
+2. **Frequency**  
+   The check runs every **5 seconds** by default.
+
+3. **Failure handling**  
+   - Each failed or timed‑out check increments a *failed ping counter*.  
+   - When failures exceed the configured threshold:  
+     - **Azure Files:** 18 failed pings  
+     - **Azure Blob:** 15 failed pings  
+   - The mount is marked **Faulted**, and **App Service automatically restarts the app** to restore connectivity to the share.
+
+#### Configuration via App Settings
+
+You can customize health‑check behavior using the following app settings.
+
+| Storage type | Setting name | Default value | Description |
+|--------------|--------------|---------------|-------------|
+| Azure Files | `WEBSITE_BYOS_FILES_HEALTH_CHECK_FREQUENCY` | `5` | Interval in seconds between health checks. |
+| Azure Files | `WEBSITE_BYOS_FILES_MAX_FAILED_PINGS` | `18` | Number of consecutive failures before marking the volume as faulted. |
+| Azure Files | `WEBSITE_BYOS_FILES_AUTO_RECOVERY_ENABLED` | `true` | Set to `false` to disable auto‑recovery logic. |
+| Azure Blob | `WEBSITE_BYOS_BLOB_HEALTH_CHECK_FREQUENCY` | `5` | Interval in seconds between health checks. |
+| Azure Blob | `WEBSITE_BYOS_BLOB_MAX_FAILED_PINGS` | `15` | Number of consecutive failures before marking the volume as faulted. |
+| Azure Blob | `WEBSITE_BYOS_BLOB_AUTO_RECOVERY_ENABLED` | `true` | Set to `false` to disable auto‑recovery logic. |
+
+#### Notes
+- Auto‑recovery helps prevent long‑running application hangs caused by unresponsive storage paths.  
+- Disabling auto‑recovery is not recommended unless troubleshooting specific mount behavior.
+
 ## Best practices
 
 ### Performance

articles/app-service/manage-automatic-scaling.md

@@ -4,32 +4,50 @@ description: Learn how to scale automatically in Azure App Service with no confi
 author: msangapu-msft
 ms.author: msangapu
 ms.topic: how-to
-ms.date: 04/18/2025
+ms.date: 01/09/2026
 ms.custom: devx-track-azurecli
-
 ms.service: azure-app-service
 ---
 
 # Automatic scaling in Azure App Service
 
-> [!NOTE]
-> Automatic scaling is available for all app types: Windows and Linux (deploy as code and container). Automatic scaling isn't supported for deployment slot traffic.
->
+> [!NOTE]  
+> Automatic scaling is available for all app types: Windows and Linux (deploy as code or container).  
+> Automatic scaling isn't supported for deployment slot traffic.
+
+Automatic scaling is a scale-out option that automatically handles scaling decisions for your web apps and App Service plans. It's different from [Azure autoscale](/azure/azure-monitor/autoscale/autoscale-overview), which lets you define scaling rules based on metrics and schedules.
+
+With automatic scaling, you can adjust scaling settings to improve performance and reduce cold-start delays. The platform prewarms instances to act as a buffer, ensuring smooth scaling transitions. You're billed per second for every instance, including prewarmed instances.
 
-Automatic scaling is a scale-out option that automatically handles scaling decisions for your web apps and App Service plans. It's different from **[Azure autoscale](/azure/azure-monitor/autoscale/autoscale-overview)**, which lets you define scaling rules based on schedules and resources.
+## Before you begin
 
-With automatic scaling, you can adjust scaling settings to improve your app's performance and avoid cold start issues. The platform prewarms instances to act as a buffer when scaling out, ensuring smooth performance transitions. You're charged per second for every instance, including prewarmed instances.
+Automatic scaling in App Service is different from autoscale.  
+Use automatic scaling when you want App Service to handle scaling automatically based on HTTP traffic, without creating rules or schedules.
 
-The following table compares scale-out and scale-in options available on App Service:
+**Automatic scaling (this article):**
+- Scales automatically based on incoming HTTP traffic  
+- Configured per app  
+- Supports Always ready, per-app limits, Maximum burst, and prewarmed instances  
 
-| | **Manual** | **Autoscale** | **Automatic scaling** |
-| --- | --- | --- | --- |
-| Available pricing tiers | Basic and up | Standard and up | Premium V2 (P1V2, P2V2, and P3V2) pricing tiers. Premium V3 (P0V3, P1V3, P2V3, P3V3, P1MV3, P2MV3, P3MV3, P4MV3, and P5MV3) pricing tiers.|
-|Rule-based scaling |No |Yes   |No, the platform manages the scale-out and scale-in based on HTTP traffic. |
-|Schedule-based scaling |No |Yes |No |
-|Always-ready instances | No, your web app runs on the number of manually scaled instances. | No, your web app runs on other instances available during the scale-out operation, based on the threshold defined for autoscale rules. | Yes (minimum 1) |
-|Prewarmed instances |No |No |Yes (default 1) |
-|Per-app maximum |No |No |Yes |
+**Autoscale:**
+- Uses metrics (CPU, memory, queue length, custom metrics)  
+- Supports schedule-based scaling  
+- Applies to the entire App Service plan  
+
+If you need CPU-, memory-, or time-based scaling, use autoscale instead.  
+Only one scaling method should be active for an App Service plan.
+
+## Scale-out options available in App Service
+
+|   | **Manual** | **Autoscale** | **Automatic scaling** |
+|--------|------------|---------------|------------------------|
+| Available tiers | Basic and up | Standard and up | Premium v2 and Premium v3 |
+| Rule-based scaling | No | Yes | No (traffic-based) |
+| Schedule-based scaling | No | Yes | No |
+| Always-ready instances | No | No | Yes (minimum 1) |
+| Prewarmed instances | No | No | Yes (default 1) |
+| Per-app maximum | No | No | Yes |
+| ARR affinity behavior | On by default | On unless manually disabled | [Should be disabled manually](#arr-affinity) |
 
 ## How automatic scaling works
 
@@ -175,7 +193,7 @@ If your web app returns a 5xx status, these endpoint pings might result in inter
 ### How do I track the number of scaled-out instances during the automatic scaling event?
 
 The `AutomaticScalingInstanceCount` metric reports the number of virtual machines on which the app is running, including the prewarmed instance if it's deployed. This metric can also be used to track the maximum number of instances your web app scaled out during an automatic scaling event. This metric is available only for the apps that have **Automatic Scaling** enabled.
-
+<a name='arr-affinity'></a>
 ### How does ARR Affinity affect automatic scaling?
 
 > [!NOTE]

articles/app-service/overview-managed-instance.md

@@ -3,7 +3,7 @@ title: Managed Instance on App Service overview (preview)
 description: Managed Instance on Azure App Service is a specialized hosting option that provides isolation, customization, and secure integration with Azure resources, ideal for legacy, and infrastructure-dependent web apps.
 keywords: app service, azure app service, managed instance, isolation, vnet integration, registry, COM, RDP, installation scripts, key vault, pv4, pmv4, windows services, GAC, third-party dependencies
 ms.topic: overview
-ms.date: 11/08/2025
+ms.date: 01/09/2026
 ms.author: msangapu
 author: msangapu-msft
 ms.service: azure-app-service
@@ -95,7 +95,7 @@ Managed Instance provides plan-level configuration through:
 |-----------|---------|
 | **Platform** | • Windows only (no Linux/containers)<br>• Not available in ASE |
 | **SKUs** | Pv4 and Pmv4 only |
-| **Regions** | East Asia, West Central US, North Europe, East US |
+| **Regions** | East Asia, West Central US, North Europe, East US, Australia East |
 | **Authentication** | Entra ID and Managed Identity only (no domain join/NTLM/Kerberos) |
 | **Workloads** | Web apps only (no WebJobs, TCP/NetPipes) |
 | **Configuration** | Persistent changes require scripts (RDP is diagnostics-only) |
@@ -114,4 +114,4 @@ Managed Instance provides plan-level configuration through:
 - [Managed Instance Quickstart](quickstart-managed-instance.md)
 - [App Service overview](overview.md)
 - [Configure Managed Instance](configure-managed-instance.md)
-- [App Service Environment comparison](./environment/overview.md)
+- [App Service Environment comparison](./environment/overview.md)