Maintenance + freshness + Acrolinx + Documentor

Author: mbender-ms

articles/load-balancer/cross-region-overview.md

@@ -6,7 +6,7 @@ services: load-balancer
 author: mbender-ms
 ms.service: azure-load-balancer
 ms.topic: concept-article
-ms.date: 02/20/2025
+ms.date: 01/29/2026
 ms.author: mbender
 ms.custom: references_regions
 # Customer intent: "As a cloud architect, I want to implement a global load balancer, so that I can ensure high availability and geo-redundancy for applications, optimizing traffic distribution while minimizing latency."
@@ -16,17 +16,17 @@ ms.custom: references_regions
 
 Azure Standard Load Balancer supports global load balancing enabling geo-redundant high availability scenarios such as:
 
-* Incoming traffic originating from multiple regions.
-* [Instant global failover](#regional-redundancy) to the next optimal regional deployment.
-* Load distribution across regions to the closest Azure region with [ultra-low latency](#ultra-low-latency).
-* Ability to [scale up/down](#ability-to-scale-updown-behind-a-single-endpoint) behind a single endpoint.
-* Static anycast global IP address
-* [Client IP preservation](#client-ip-preservation)
-* [Build on existing load balancer](#build-cross-region-solution-on-existing-azure-load-balancer) solution with no learning curve
+- Incoming traffic originating from multiple regions.
+- [Instant global failover](#regional-redundancy) to the next optimal regional deployment.
+- Load distribution across regions to the closest Azure region with [ultra-low latency](#ultra-low-latency).
+- Ability to [scale up/down](#ability-to-scale-updown-behind-a-single-endpoint) behind a single endpoint.
+- Static anycast global IP address
+- [Client IP preservation](#client-ip-preservation)
+- [Build on existing load balancer](#build-cross-region-solution-on-existing-azure-load-balancer) solution with no learning curve
 
 The frontend IP configuration of your global load balancer is static and advertised across [most Azure regions](#participating-regions-in-azure).
 
-:::image type="content" source="./media/cross-region-overview/cross-region-load-balancer.png" alt-text="Diagram of global load balancer." border="true":::
+:::image type="content" source="./media/cross-region-overview/cross-region-load-balancer.png" alt-text="Screenshot of diagram showing global load balancer architecture." border="true":::
 
 > [!NOTE]
 > The backend port of your load balancing rule on global load balancer should match the frontend port of the load balancing rule/inbound nat rule on regional standard load balancer. 
@@ -39,7 +39,7 @@ If one region fails, the traffic is routed to the next closest healthy regional
 
 The health probe of the global load balancer gathers information about availability of each regional load balancer every 5 seconds. If one regional load balancer drops its availability to 0, global load balancer detects the failure. The regional load balancer is then taken out of rotation. 
 
-:::image type="content" source="./media/cross-region-overview/global-region-view.png" alt-text="Diagram of global region traffic view." border="true":::
+:::image type="content" source="./media/cross-region-overview/global-region-view.png" alt-text="Screenshot of diagram showing global region traffic view." border="true":::
 
 ### Ultra-low latency
 
@@ -49,8 +49,8 @@ Traffic started from a client hits the closest participating region and travel t
 
 For example, you have a global load balancer with standard load balancers in Azure regions:
 
-* West US
-* North Europe
+- West US
+- North Europe
 
 If a flow is started from Seattle, traffic enters West US. This region is the closest participating region from Seattle. The traffic is routed to the closest region load balancer, which is West US.
 
@@ -94,75 +94,75 @@ Add your existing load balancer deployments to a global load balancer for a high
 
 ### Home regions and participating regions
 
-**Home region** is where the global load balancer or Public IP Address of Global tier is deployed. 
+--Home region-- is where the global load balancer or Public IP Address of Global tier is deployed. 
 This region doesn't affect how the traffic is routed. If a home region goes down, traffic flow is unaffected.
 
 #### Home regions in Azure
-* Central US
-* East Asia
-* East US 2
-* North Europe
-* Southeast Asia
-* UK South
-* US Gov Virginia
-* West Europe
-* West US
-* China North 2
+- Central US
+- East Asia
+- East US 2
+- North Europe
+- Southeast Asia
+- UK South
+- US Gov Virginia
+- West Europe
+- West US
+- China North 2
 
 > [!NOTE]
 > You can only deploy your global load balancer or Public IP in Global tier in one of the listed Home regions.
 
-A **participating region** is where the Global public IP of the load balancer is being advertised.
+A --participating region-- is where the Global public IP of the load balancer is being advertised.
 
 Traffic started by the user travels to the closest participating region through the Microsoft core network. 
 
 Global load balancer routes the traffic to the appropriate regional load balancer.
 
-:::image type="content" source="./media/cross-region-overview/multiple-region-global-traffic.png" alt-text="Diagram of multiple region global traffic.":::
+:::image type="content" source="./media/cross-region-overview/multiple-region-global-traffic.png" alt-text="Screenshot of diagram showing multiple region global traffic flow.":::
 
 #### Participating regions in Azure
 
-* Australia East 
-* Australia Southeast 
-* Central India 
-* Central US 
-* East Asia 
-* East US 
-* East US 2 
-* Japan East 
-* North Central US 
-* North Europe 
-* South Central US 
-* Southeast Asia 
-* UK South 
-* US DoD Central
-* US DoD East
-* US Gov Arizona
-* US Gov Texas
-* US Gov Virginia
-* West Central US 
-* West Europe 
-* West US 
-* West US 2 
+- Australia East 
+- Australia Southeast 
+- Central India 
+- Central US 
+- East Asia 
+- East US 
+- East US 2 
+- Japan East 
+- North Central US 
+- North Europe 
+- South Central US 
+- Southeast Asia 
+- UK South 
+- US DoD Central
+- US DoD East
+- US Gov Arizona
+- US Gov Texas
+- US Gov Virginia
+- West Central US 
+- West Europe 
+- West US 
+- West US 2 
 
 > [!NOTE]
 > The backend regional load balancers can be deployed in any publicly available Azure Region and isn't limited to just participating regions.
 
 ## Limitations of global load balancer
 
-* Global frontend IP configurations are public only. An internal frontend is currently not supported.
+- Global frontend IP configurations are public only. An internal frontend is currently not supported.
 
-* Private or internal load balancer can't be added to the backend pool of a global load balancer 
+- Private or internal load balancer can't be added to the backend pool of a global load balancer 
 
-* NAT64 translation isn't supported at this time. The frontend and backend IPs must be of the same type (v4 or v6).
+- NAT64 translation isn't supported at this time. The frontend and backend IPs must be of the same type (v4 or v6).
 
-* UDP traffic on port 3 isn't supported on global load balancer
+- UDP traffic on port 3 isn't supported on global load balancer
 
-* Outbound rules aren't supported on global load balancer. For outbound connections, utilize [outbound rules](./outbound-rules.md) on the regional load balancer or [NAT gateway](../nat-gateway/nat-overview.md).
+- Outbound rules aren't supported on global load balancer. For outbound connections, utilize [outbound rules](./outbound-rules.md) on the regional load balancer or [NAT gateway](../nat-gateway/nat-overview.md).
 
-* Regional load balancers can't be upgraded to the global tier. Only new load balancers can be created as the global tier.
+- Regional load balancers can't be upgraded to the global tier. Only new load balancers can be created as the global tier.
 
-* When placing the same NIC(s) behind multiple regional load balancers with global load balancer, the load balancing rules on each regional load balancer with the same frontend port must also be configured to the same backend port.
+- When placing the same NIC(s) behind multiple regional load balancers with global load balancer, the load balancing rules on each regional load balancer with the same frontend port must also be configured to the same backend port.
 
 ## Pricing and SLA
 Global load balancer shares the [SLA](https://azure.microsoft.com/support/legal/sla/load-balancer/v1_0/) of standard load balancer.

articles/load-balancer/cross-subscription-overview.md

@@ -6,7 +6,7 @@ services: load-balancer
 author: mbender-ms
 ms.service: azure-load-balancer
 ms.topic: overview
-ms.date: 02/20/2025
+ms.date: 01/29/2026
 ms.author: mbender
 ms.custom:
   - sfi-image-nochange
@@ -22,7 +22,7 @@ This article provides an overview of cross-subscription load balancing with Azur
 
 Cross-subscription load balancing allows you to deploy Azure Load Balancer resources across multiple subscriptions. This feature enables you to deploy a load balancer in one subscription and have the frontend IP and backend pool instances in a different subscription. This capability is useful for organizations that have separate subscriptions for networking and application resources.
 
-:::image type="content" source="media/cross-subscription-load-balancer-overview/cross-subscription-load-balancer-concept.png" alt-text="Diagram of cross-subscription load balancer concepts with two subscriptions and resources.":::
+:::image type="content" source="media/cross-subscription-load-balancer-overview/cross-subscription-load-balancer-concept.png" alt-text="Screenshot of cross-subscription load balancer concepts with two subscriptions and resources.":::
 
 This table illustrates some of the possible scenarios cross-subscription load balancing supports. 
 
@@ -38,7 +38,7 @@ Cross-subscription frontends allow the frontend IP configuration to reside in a
 ### Public frontend IP configurations 
 Public IP addresses utilized by an Azure Load Balancer can reside in different subscription than the load balancer. If multiple public IP addresses are attached to a load balancer, each IP address can come from a different subscription. For example, if we have a Load Balancer (deployed in subscription C) with two frontend IPs, the first IP address can reside in subscription B and the second IP address can reside in subscription A.   
 
-:::image type="content" source="media/cross-subscription-load-balancer-overview/public-frontend-ip-configuration-concept.png" alt-text="Diagram of public frontend ip configuration with cross subscription load balancing.":::
+:::image type="content" source="media/cross-subscription-load-balancer-overview/public-frontend-ip-configuration-concept.png" alt-text="Screenshot of public frontend IP configuration with cross-subscription load balancing.":::
 
 An important note is that once a frontend IP configuration is set, its subscription can’t be modified. However, the frontend IP configuration can be updated with a different IP address within the same subscription. For example, if a frontend IP configuration is attached to IP address A in subscription 1, it can be updated to IP address B also in subscription 1. 
 Cross-subscription public IP addresses are only supported on the regional tier standard load balancer
@@ -66,7 +66,7 @@ With SyncMode configured as *Manual*, backend pool instances aren't synchronized
 
 In addition, cross-subscription load balancing is supported for Azure global Load Balancer. With cross-subscription global load balancer, backend regional load balancers can each be located in different subscriptions. Cross-subscription backends on a global load balancer don't need other parameters or changes to the backend pool.
 
-:::image type="content" source="media/cross-subscription-load-balancer-overview/global-load-balancer-cross-subscription-concept-thumbnail.png" alt-text="Diagram of cross subscription global load balancer concept." lightbox="media/cross-subscription-load-balancer-overview/global-load-balancer-cross-subscription-concept.png":::
+:::image type="content" source="media/cross-subscription-load-balancer-overview/global-load-balancer-cross-subscription-concept-thumbnail.png" alt-text="Screenshot of cross-subscription global load balancer concept." lightbox="media/cross-subscription-load-balancer-overview/global-load-balancer-cross-subscription-concept.png":::
 
 > [!NOTE]
 >  Cross-subscription frontends aren't supported on Azure global Load Balancer today. 

articles/load-balancer/howto-load-balancer-imds.md

@@ -6,7 +6,7 @@ services: load-balancer
 author: mbender-ms
 ms.service: azure-load-balancer
 ms.topic: how-to
-ms.date: 06/28/2024
+ms.date: 01/29/2026
 ms.author: mbender
 ms.custom: template-how-to
 # Customer intent: As a cloud operator, I want to retrieve load balancer metadata using the Instance Metadata Service, so that I can analyze network traffic and manage IP configurations for virtual machines effectively.

articles/load-balancer/index.yml

@@ -10,7 +10,7 @@ metadata:
   ms.topic: landing-page
   author: mbender-ms
   ms.author: mbender
-  ms.date: 11/11/2024
+  ms.date: 01/28/2026
   ms.custom: engagement-fy23, seo-FY24Q2
 
 # linkListType: architecture | concept | deploy | download | get-started | how-to-guide | learn | overview | quickstart | reference | tutorial | whats-new

articles/load-balancer/instance-metadata-service-load-balancer.md

@@ -6,7 +6,7 @@ services: load-balancer
 author: mbender-ms
 ms.service: azure-load-balancer
 ms.topic: concept-article
-ms.date: 06/26/2024
+ms.date: 01/29/2026
 ms.author: mbender
 # Customer intent: "As a cloud infrastructure engineer, I want to retrieve load balancer and virtual machine IP information using the Instance Metadata Service, so that I can efficiently manage and troubleshoot my virtual machine instances behind the load balancer."
 ---

articles/load-balancer/load-balancer-basic-upgrade-guidance.md

@@ -5,14 +5,14 @@ author: mbender-ms
 ms.service: azure-load-balancer
 ms.author: mbender
 ms.topic: concept-article
-ms.date: 09/30/2024
+ms.date: 01/29/2026
 # Customer intent: As an cloud engineer with Basic Load Balancer services, I need guidance and direction on migrating my workloads off Basic to Standard SKUs
 ---
 
 # Upgrading from Basic Load Balancer - Guidance
 
->[!Important]
->On September 30, 2025, Basic Load Balancer was retired. For more information, see the [official announcement](https://azure.microsoft.com/updates/azure-basic-load-balancer-will-be-retired-on-30-september-2025-upgrade-to-standard-load-balancer/). If you are currently using Basic Load Balancer, make sure to upgrade to Standard Load Balancer as soon as possible. This article will help guide you through the upgrade process. 
+> [!IMPORTANT]
+> On September 30, 2025, Basic Load Balancer was retired. For more information, see the [official announcement](https://azure.microsoft.com/updates/azure-basic-load-balancer-will-be-retired-on-30-september-2025-upgrade-to-standard-load-balancer/). If you are currently using Basic Load Balancer, make sure to upgrade to Standard Load Balancer as soon as possible. This article will help guide you through the upgrade process. 
 
 In this article, we discuss guidance for upgrading your Basic Load Balancer instances to Standard Load Balancer. Standard Load Balancer is recommended for all production instances and provides many [key differences](#basic-load-balancer-sku-vs-standard-load-balancer-sku) to your infrastructure.
 
@@ -64,7 +64,7 @@ Use these PowerShell scripts to help with upgrading from Basic to Standard SKU:
 > [!NOTE]
 > Although manually upgrading your Basic Load Balancer to a Standard Load Balancer using the Portal is an option, we recommend using the [**automated script option**](./upgrade-basic-standard-with-powershell.md) above, due to the number of steps and complexity of the migration. The automation ensures a consistent migration and minimizes downtime to load balanced applications.
 
->[!Warning]
+> [!WARNING]
 > Before manually upgrading a Basic Load Balancer, make sure that all Public IPs associated with both the Load Balancer and its backend Virtual Machines are set to 'static'. If you disassociate a Public IP or remove all backend VMs before changing the IP allocation to static, the IP address may be lost.
 
 When manually migrating from a Basic to Standard SKU Load Balancer, there are a couple key considerations to keep in mind:
@@ -79,7 +79,7 @@ Suggested order of operations for manually upgrading a Basic Load Balancer in co
 1. Change all Public IPs associated with the Basic Load Balancer and backend Virtual Machines to 'static' allocation
 1. For private Load Balancers, record the private IP addresses allocated to the frontend IP configurations
 1. Record the backend pool membership of the Basic Load Balancer
-1. Record the load balancing rules, NAT rules and health probe configuration of the Basic Load Balancer
+1. Record the load balancing rules, NAT rules, and health probe configuration of the Basic Load Balancer
 1. Create a new Standard SKU Load Balancer, matching the public or private configuration of the Basic Load Balancer. Name the frontend IP configuration something temporary. For public load balancers, use a new Public IP address for the frontend configuration. For guidance, see [Create a Public Load Balancer in the Portal](./quickstart-load-balancer-standard-public-portal.md) or [Create an Internal Load Balancer in the Portal](./quickstart-load-balancer-standard-internal-portal.md)
 1. Duplicate the Basic SKU Load Balancer configuration for the following:
     1. Backend pool names
@@ -91,7 +91,7 @@ Suggested order of operations for manually upgrading a Basic Load Balancer in co
 1. For Virtual Machine Scale Set backends, remove the Load Balancer association in the Networking settings and [update the instances](/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-perform-manual-upgrades) 
 1. Delete the Basic Load Balancer 
    > [!NOTE]
-   > For Virtual Machine Scale Set backends, you will need to remove the load balancer association in the Networking settings. Once removed, you will also need to [**update the instances**](/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-perform-manual-upgrades) 
+   > For Virtual Machine Scale Set backends, you'll need to remove the load balancer association in the Networking settings. Once removed, you'll also need to [**update the instances**](/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-perform-manual-upgrades) 
 1. [Upgrade all Public IPs](../virtual-network/ip-services/public-ip-upgrade-portal.md) previously associated with the Basic Load Balancer and backend Virtual Machines to Standard SKU. For Virtual Machine Scale Sets, remove any instance-level public IP configuration, update the instances, then add a new one with Standard SKU and update the instances again. 
 1. Recreate the frontend configurations from the Basic Load Balancer on the newly created Standard Load Balancer, using the same public or private IP addresses as on the Basic Load Balancer
 1. Update the load balancing and NAT rules to use the appropriate frontend configurations

articles/load-balancer/load-balancer-best-practices.md

@@ -6,14 +6,12 @@ services: load-balancer
 author: cozhang8
 ms.service: azure-load-balancer
 ms.topic: troubleshooting
-ms.date: 01/13/2025
+ms.date: 01/29/2026
 ms.author: mbender
 # Customer intent: As a cloud architect, I want to implement best practices for deploying and configuring a load balancer, so that I can enhance the reliability and performance of my Azure network infrastructure.
 ---
 
 # Azure Load Balancer Best Practices
-<!-- Before Publishing: -->
-<!-- Verify TOC entry is added to TOC.yml -->
 
 This article discusses a collection of Azure best practices for your load balancer deployment. These best practices are derived from our experience with Azure networking and the experiences of customers like yourself.