edits

Author: tfitzmac

articles/azure-resource-manager/management/request-limits-and-throttling.md

@@ -5,7 +5,8 @@ ms.topic: conceptual
 ms.date: 03/01/2024
 ms.custom: devx-track-arm-template
 ---
-# Throttling Resource Manager requests
+
+# Understand how Azure Resource Manager throttles requests
 
 This article describes how Azure Resource Manager throttles requests. It shows you how to track the number of requests that remain before reaching the limit, and how to respond when you reach the limit.
 
@@ -35,6 +36,8 @@ These limits apply to each Azure Resource Manager instance. There are multiple i
 
 The remaining requests are returned in the [response header values](#remaining-requests).
 
+## Migrating to regional throttling and token bucket algorithm
+
 Starting in 2024, Microsoft is migrating Azure subscriptions to a new throttling architecture. With this change, you'll experience new throttling limits. The new throttling limits are applied per region rather than per instance of Azure Resource Manager. The new architecture uses a [token bucket algorithm](https://en.wikipedia.org/wiki/Token_bucket) to manage API throttling.
 
 The token bucket represents the maximum number of requests that you can send for each second. When you reach the maximum number of requests, the refill rate determines how quickly tokens become available in the bucket.
@@ -131,8 +134,6 @@ For information about throttling in other resource providers, see:
 
 When you reach the limit, you receive the HTTP status code **429 Too many requests**. The response includes a **Retry-After** value, which specifies the number of seconds your application should wait (or sleep) before sending the next request. If you send a request before the retry value elapses, your request isn't processed and a new retry value is returned.
 
-After waiting for specified time, you can also close and reopen your connection to Azure. By resetting the connection, you may connect to a different instance of Azure Resource Manager.
-
 If you're using an Azure SDK, the SDK may have an auto retry configuration. For more information, see [Retry guidance for Azure services](/azure/architecture/best-practices/retry-service-specific).
 
 Some resource providers return 429 to report a temporary problem. The problem could be an overload condition that isn't directly caused by your request. Or, it could represent a temporary error about the state of the target resource or dependent resource. For example, the network resource provider returns 429 with the **RetryableErrorDueToAnotherOperation** error code when the target resource is locked by another operation. To determine if the error comes from throttling or a temporary condition, view the error details in the response.