Merge pull request #305050 from MicrosoftDocs/main

Auto Publish – main to live - 2025-09-04 11:00 UTC

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

articles/application-gateway/application-gateway-tls-version-retirement.md

@@ -5,7 +5,7 @@ services: application gateway
 author: jaesoni
 ms.service: azure-application-gateway
 ms.topic: concept-article
-ms.date: 07/31/2025
+ms.date: 09/04/2025
 ms.author: mbender
 ms.custom:
   - build-2025
@@ -113,14 +113,16 @@ Once support for TLS versions 1.0 and 1.1 is discontinued, clients may encounter
 A default TLS policy for Application Gateway is a packaged set of supported TLS versions and cipher suites. This allows customers to begin using secured traffic by only configuring HTTPS or TLS listeners and backend settings, without any extra configuration for TLS version or ciphers. Application Gateway uses one of its predefined policies as the default.
 
 ### How will the default TLS policies be impacted after legacy TLS versions 1.0 and 1.1 retirement?
-Until September 2025, V2 SKUs utilize two [default TLS policies](application-gateway-ssl-policy-overview.md#default-tls-policy) based on the API version specified during resource deployment. Deployments using API version **2023-02-01 or later** apply `AppGwSslPolicy20220101` by default, while earlier API versions use `AppGwSslPolicy20150501`. With the deprecation of TLS 1.0 and 1.1, the older `AppGwSslPolicy20150501` policy, will be discontinued. So, `AppGwSslPolicy20220101` will become the default policy for all V2 gateways.
+Until September 2025, V2 SKUs utilize two [default TLS policies](application-gateway-ssl-policy-overview.md#default-tls-policy) based on the API version specified during resource deployment. Deployments using API version **2023-02-01 or later** apply `AppGwSslPolicy20220101` by default, while earlier API versions use `AppGwSslPolicy20150501`. 
+
+With the deprecation of TLS 1.0 and 1.1, the older `AppGwSslPolicy20150501` policy, will be discontinued. So, `AppGwSslPolicy20220101` will become the default policy for all V2 gateways. Once this change in default policy is implemented, a subsequent PUT operation will complete the configuration update. 
 
 The default policy for the V1 SKU will remain unchanged since `AppGwSslPolicy20220101` won't be introduced for this retiring SKU.
 
 > [!NOTE]
-> A default TLS policy is applied only when the "Default" option is selected in the Portal or when no TLS policy is specified within the resource configuration by means such as REST, PowerShell, or AzCLI.
+> * A default TLS policy is applied only when the "Default" option is selected in the Portal or when no TLS policy is specified within the resource configuration by means such as REST, PowerShell, or AzCLI. Accordingly, using a default policy in configuration isn't same as explicitly selecting `AppGwSslPolicy20150501` policy, even if `AppGwSslPolicy20150501` is the default policy for your API version.
 > 
-> Accordingly, using a default policy in configuration isn't same as explicitly selecting `AppGwSslPolicy20150501` policy, even if `AppGwSslPolicy20150501` is the default policy for your API version.
+> * The changes will be applied gradually across all Azure regions.
 
 ### Which TLS policies in Application Gateway are getting deprecated?
 The predefined policies `AppGwSslPolicy20150501` and `AppGwSslPolicy20170401` that support TLS versions 1.0 and 1.1 will be removed from the Azure Resource Manager configuration. Similarly, the Custom policy will stop supporting TLS versions 1.0 and 1.1 along with their associated cipher suites. This applies to both V1 and V2 SKUs.
@@ -134,7 +136,7 @@ If you have chosen any deprecating TLS policy in the configuration of your gatew
 A nonfunctional TLS configuration, such a SSLProfile not linked to any listener, won't have any impact on the control plane of the gateway.
 
 ### How is the release for this change planned?
-Given the scale of our fleet, after 30 August 2025, the deprecation of TLS versions will be implemented separately for the Data and Control Planes (in that order). Any region-specific details won't be available; therefore, we strongly advise you to take all necessary actions before this retirement date.
+Given the scale of our fleet, after 30 August 2025, the deprecation of TLS versions will be implemented separately for the Control and Data planes. Any region-specific details won't be available; therefore, we strongly advise you to take all necessary actions at the earliest.
 
 ### Is there any potential impact if I haven’t selected any TLS policy and my gateway uses only HTTP/TCP configurations?
 If your gateway doesn't use any TLS configuration—either through SSLPolicy, SSLProfile, HTTPS, or TLS Listeners—there will be no impact after August 2025.

articles/backup/restore-all-files-volume-mars.md

@@ -2,7 +2,7 @@
 title: Restore all files in a volume with MARS
 description: Learn how to restore all the files in a volume using the MARS Agent.
 ms.topic: how-to
-ms.date: 06/20/2025
+ms.date: 09/04/2025
 author: AbhishekMallick-MS
 ms.author: v-mallicka
 # Customer intent: As an IT admin responsible for data recovery, I want to restore all backed-up files in a volume using the Recovery Services agent, so that I can quickly recover critical data to either the original machine or an alternate machine.
@@ -21,7 +21,7 @@ The MARS Agent enables seamless restoration of all files within a volume. By usi
 - Restore the backup data from the secondary region, if you have Cross Region Restore enabled in your vault. Also, you need to download the Secondary Region vault credential file from the Azure portal and pass it into the MARS agent.
 
 >[!TIP]
->The **Volume** option recovers all backed up data in a specified volume. This option provides faster transfer speeds (up to 40 Mbps), and is recommended for recovering large-sized data or entire volumes.
+>The **Volume** option recovers all backed up data in a specified volume. This option provides faster transfer speeds (up to 40 MBps), and is recommended for recovering large-sized data or entire volumes.
 >
 >The **Individual files and folders option** allows for quick access to the recovery point data. It's suitable for recovering individual files, and is recommended for a total size of less than 80 GB. It offers transfer or copy speeds of up to 6 MBps during recovery.
 

articles/frontdoor/origin-security.md

@@ -14,6 +14,13 @@ zone_pivot_groups: front-door-tiers
 
 Front Door's features work best when traffic only flows through Front Door. You should configure your origin to block traffic that hasn't been sent through Front Door. Otherwise, traffic might bypass Front Door's web application firewall, DDoS protection, and other security features.
 
+| Approach | Supported tiers | 
+|--|--|
+| Private Link | Premium |
+| Managed Identities | Standard, Premium |
+| IP address filtering | Classic, Standard, Premium |
+| Front Door identifier | Classic, Standard, Premium |
+
 ::: zone pivot="front-door-classic"
 
 > [!NOTE]
@@ -25,7 +32,7 @@ Front Door's features work best when traffic only flows through Front Door. You
 
 Front Door provides several approaches that you can use to restrict your origin traffic.
 
-## Private Link origins
+## Private Link enabled origins
 
 When you use the premium SKU of Front Door, you can use Private Link to send traffic to your origin. [Learn more about Private Link origins.](private-link.md)
 

articles/frontdoor/private-link.md

@@ -32,9 +32,6 @@ After you enable an origin for Private Link and approve the private endpoint con
 
 Once your request is approved, a dedicated private endpoint gets assigned for routing your traffic from the Azure Front Door managed virtual network. Traffic from your clients will reach Azure Front Door Global POPs and is then routed over the Microsoft backbone network to the AFD regional cluster which hosts the managed virtual network containing the dedicated private endpoint. The traffic is then routed to your origin via the private link platform over Microsoft backbone network. Hence the incoming traffic to your origin secured upon the moment it arrives to Azure Front Door. 
 
-> [!NOTE]
-> * This feature only supports private link connectivity from your AFD to your origin. Client to AFD private connectivity is not supported.
-
 ## Supported origins
 
 Origin support for direct private endpoint connectivity is currently limited to the below origin types.
@@ -70,16 +67,7 @@ Azure Front Door private link is available in the following regions:
 | US Gov Texas | | | |
 | US Gov Virginia | | | |
 
-The Azure Front Door Private Link feature is region agnostic but for the best latency, you should always pick an Azure region closest to your origin when choosing to enable Azure Front Door Private Link endpoint. If your origin's region is not supported in the list of regions AFD Private Link supports, pick the next nearest region. You can use [Azure network round-trip latency statistics](../networking/azure-network-latency.md) to determine the next nearest region in terms of latency.
-
-## Tips while using AFD Private Link integration
-* Azure Front Door doesn't allow mixing public and private origins in the same origin group. Doing so can cause errors during configuration or while AFD tries to send traffic to the public/private origins. Keep all your public origins in a single origin group and keep all your private origins in a different origin group.
-* Improving redundancy:
-    * To improve redundancy at origin level, make sure you have multiple private link enabled origins within the same origin group so that AFD can distribute traffic across multiple instances of the application. If one instance is unavailable, then other origins can still receive traffic.
-    * To route Private Link traffic, requests are routed from AFD POPs to the AFD managed virtual network hosted in AFD regional clusters. To have redundancy in case the regional cluster is not reachable, it is recommended to configure multiple origins (each with a different Private Link region) under the same AFD origin group. This way even if one regional cluster is unavailable, then other origins can still receive traffic via a different regional cluster. Below is how an origin group with both origin level and region level redundancy would look like.
-        :::image type="content" source="./media/private-link/redundant-origin-group.png" alt-text="Diagram showing an origin group with both origin level and region level redundancy.":::
-* While approving the private endpoint connection or after approving the private endpoint connection, if you double click on the private endpoint, you will see an error message saying "You don't have access. Copy the error details and send them to your administrator(s) to get access to this page." This is expected as the private endpoint is hosted within a subscription managed by Azure Front Door.
-* For platform protection, each AFD regional cluster has a limit of 7200 RPS (requests per second) per AFD profile. Requests beyond 7200 RPS will be rate limited with "429 Too Many Requests". If you are onboarding or expecting traffic more than 7200 RPS, we recommend deploying multiple origins (each with a different Private Link region) so that traffic is spread across multiple AFD regional clusters. It is recommended that each origin is a separate instance of your application to improve origin level redundancy. But if you can not maintain separate instances, you can still configure multiple origins at AFD level with each origin pointing to the same hostname but the regions are kept different. This way AFD will route the traffic to the same instance but via different regional clusters.
+The Azure Front Door Private Link feature is region agnostic but for the best latency, you should always pick an Azure region closest to your origin when choosing to enable Azure Front Door Private Link endpoint. If your origin's region is not supported in the list of regions AFD Private Link supports, pick the next nearest region. You can use [Azure network round-trip latency statistics](../networking/azure-network-latency.md) to determine the next nearest region in terms of latency. We are in the process of enabling support for more regions. Once a new region is supported, you can follow these [instructions](blue-green-deployment.md) to gradually shift traffic to the new region.
 
 ## Association of a private endpoint with an Azure Front Door profile
 
@@ -135,6 +123,29 @@ If AFD-Profile-1 gets deleted, then the PE1 private endpoint across all the orig
     * If AFD-Profile-4 gets deleted, only PE7 is removed.
     * If AFD-Profile-5 gets deleted, only PE8 is removed.
 
+## Frequently asked questions
+
+1. Does this feature support private link connectivity from client to Front Door?
+* No. This feature only supports private link connectivity from your AFD to your origin.
+
+2. How to improve redundancy while using Private Link with AFD?
+* To improve redundancy at origin level, make sure you have multiple private link enabled origins within the same origin group so that AFD can distribute traffic across multiple instances of the application. If one instance is unavailable, then other origins can still receive traffic.
+* To route Private Link traffic, requests are routed from AFD POPs to the AFD managed virtual network hosted in AFD regional clusters. To have redundancy in case the regional cluster is not reachable, it is recommended to configure multiple origins (each with a different Private Link region) under the same AFD origin group. This way even if one regional cluster is unavailable, then other origins can still receive traffic via a different regional cluster. Below is how an origin group with both origin level and region level redundancy would look like.
+        :::image type="content" source="./media/private-link/redundant-origin-group.png" alt-text="Diagram showing an origin group with both origin level and region level redundancy.":::
+
+3. Can I mix public and private origins in the same origin group?
+* No. Azure Front Door doesn't allow mixing public and private origins in the same origin group. This can cause configuration errors or traffic routing issues. Keep all public origins in one origin group and all private origins in a separate origin group.
+
+4. Why do I see an error when trying to access the private endpoint details by double clicking on the private endpoint in Azure portal?
+* While approving the private endpoint connection or after approving the private endpoint connection, if you double click on the private endpoint, you will see an error message saying "You don't have access. Copy the error details and send them to your administrator(s) to get access to this page." This is expected as the private endpoint is hosted within a subscription managed by Azure Front Door.
+
+5. What are the rate limits for Private Link traffic and how can I handle high traffic scenarios?
+* For platform protection, each AFD regional cluster has a limit of 7200 RPS (requests per second) per AFD profile. Requests beyond 7200 RPS at a region will be rate limited with "429 Too Many Requests". 
+* If you are onboarding or expecting traffic more than 7200 RPS, we recommend deploying multiple origins (each with a different Private Link region) so that traffic is spread across multiple AFD regional clusters. It is recommended that each origin is a separate instance of your application to improve origin level redundancy. But if you can not maintain separate instances, you can still configure multiple origins at AFD level with each origin pointing to the same hostname but the regions are kept different. This way AFD will route the traffic to the same instance but via different regional clusters.
+
+6. For private link enabled origins, will health probes also follow the same network path as actual traffic?
+* Yes.
+
 ## Next steps
 
 * Learn how to [connect Azure Front Door Premium to a Web App origin with Private Link](standard-premium/how-to-enable-private-link-web-app.md).

articles/frontdoor/secure-front-door.md

@@ -26,7 +26,7 @@ Network security for Azure Front Door focuses on establishing secure connections
 
 * **Configure Web Application Firewall for application-layer protection**: Deploy Azure Web Application Firewall (WAF) to protect your applications from common web vulnerabilities and exploits. WAF provides managed rule sets for OWASP Top 10 protection, bot management, and custom rules for specific threat patterns. For more information, see [Web Application Firewall (WAF) on Azure Front Door](./web-application-firewall.md).
 
-* **Implement origin security controls**: Configure your origins to accept traffic only from Azure Front Door by using IP filtering with the `AzureFrontDoor.Backend` service tag and validating the X-Azure-FDID header value. This prevents attackers from bypassing Front Door's security features. For more information, see [Secure traffic to Azure Front Door origins](./origin-security.md).
+* **Implement origin security controls**: Configure your origins to accept traffic only from Azure Front Door by using managed identities or IP filtering with the `AzureFrontDoor.Backend` service tag and validating the X-Azure-FDID header value. This prevents attackers from bypassing Front Door's security features. For more information, see [Secure traffic to Azure Front Door origins](./origin-security.md).
 
 * **Use rate limiting to prevent abuse**: Configure WAF rate limiting rules to protect against high-volume attacks and prevent individual IP addresses from overwhelming your service. Rate limiting helps mitigate application-layer DDoS attacks and abusive traffic patterns. For more information, see [Rate limiting](/azure/web-application-firewall/afds/waf-front-door-rate-limit).