Merge pull request #309001 from MicrosoftDocs/main

Auto Publish – main to live - 2025-12-03 18:00 UTC

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

articles/backup/quick-secondary-region-restore-postgresql-powershell.md

@@ -3,7 +3,7 @@ title: Quickstart - Cross region restore for PostgreSQL database with PowerShell
 description: In this Quickstart, learn how to restore PostgreSQL database across region with the Azure PowerShell module.
 ms.devlang: azurecli
 ms.topic: quickstart
-ms.date: 12/03/2024
+ms.date: 12/03/2025
 ms.custom: mvc, devx-track-azurepowershell, mode-api
 author: AbhishekMallick-MS
 ms.author: v-mallicka
@@ -91,15 +91,15 @@ To validate the probabilities of success for the restore operation, run the foll
 $validate = Test-AzDataProtectionBackupInstanceRestore -ResourceGroupName $ResourceGroupName -Name $instance[0].Name -VaultName $VaultName -RestoreRequest $OssRestoreReq -SubscriptionId $SubscriptionId -RestoreToSecondaryRegion #-Debug
 ```
 
-## Trigger the restore operation
+## Trigger the restore operation for PostgreSQL database
 
 To trigger the restore operation, run the following cmdlet:
 
 ```azurepowershell
 $restoreJob = Start-AzDataProtectionBackupInstanceRestore -BackupInstanceName $instance.Name -ResourceGroupName $ResourceGroupName -VaultName $vaultName -SubscriptionId $SubscriptionId -Parameter $OssRestoreReq -RestoreToSecondaryRegion  # -Debug
 ```
 
-## Track the restore job
+## Track the restore job for PostgreSQL database
 
 To monitor the restore job progress, choose one of the methods:
 

articles/cost-management-billing/manage/manage-azure-credits.md

@@ -18,7 +18,7 @@ ms.custom:
 When you accept Microsoft Azure credit under a Customer Agreement, the credit is assigned to a [subscription](../../cost-management-billing/manage/cloud-subscription.md) and resource group. The associated resource holds metadata such as status, credit amount, currency, start date, and end date. This information is accessible in the Azure portal.
 
 >[!NOTE] 
->This article applies to Azure Credit Offer, Azure Prepayment, Support credits accepted after ***August 2025***, credits accepted earlier are not listed as resources under a subscription.
+>This article applies to Azure Credit Offer, Azure Prepayment, End Customer Investment Funds (ECIF), and Support credits accepted after ***August 2025***, credits accepted earlier are not listed as resources under a subscription.
 
 
 

articles/digital-twins/resources-migrate-from-preview-apis.md

@@ -36,7 +36,7 @@ The changes from the 2020-03-01-preview API version to the 2023-01-31 (GA) API v
 If you're using an associated SDK of the 2020-03-01-preview API, we recommend that you update to the latest version of the management SDK. Use the following links to know what other changes are required to migrate to the new management SDK.
 * .NET: Migrate from the [Microsoft.Azure.Management.DigitalTwins 1.0.0-preview.1](https://www.nuget.org/packages/Microsoft.Azure.Management.DigitalTwins/1.0.0-preview.1) package to the [Azure.ResourceManager.DigitalTwins 1.1.0](https://www.nuget.org/packages/Azure.ResourceManager.DigitalTwins/1.1.0) package, by following the [.NET SDK migration guidance](https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/resourcemanager/Azure.ResourceManager/docs/MigrationGuide.md).
 * Java: Migrate from the [azure-mgmt-digitaltwins:1.0.0-beta](https://search.maven.org/artifact/com.microsoft.azure.digitaltwins.v2020_03_01_preview/azure-mgmt-digitaltwins/1.0.0-beta/jar) package to the [azure-resourcemanager-digitaltwins:1.1.0](https://search.maven.org/artifact/com.azure.resourcemanager/azure-resourcemanager-digitaltwins/1.1.0/jar) package, by following the [Java SDK migration guidance](https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/eventhubs/azure-messaging-eventhubs/migration-guide.md).
-* Go: Migrate from the [digitaltwins 2020-03-01-preview](https://pkg.go.dev/github.com/Azure/[email protected]+incompatible/services/preview/digitaltwins/mgmt/2020-03-01-preview/digitaltwins) package to the [armsdigitaltwins v1.0.0](https://pkg.go.dev/github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/digitaltwins/armdigitaltwins) package, by following the [Go SDK migration guidance](https://github.com/Azure/azure-sdk-for-go/blob/main/documentation/MIGRATION_GUIDE.md).
+* Go: Migrate from the [digitaltwins 2020-03-01-preview](https://pkg.go.dev/github.com/Azure/[email protected]+incompatible/services/preview/digitaltwins/mgmt/2020-03-01-preview/digitaltwins) package to the [armsdigitaltwins v1.0.0](https://pkg.go.dev/github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/digitaltwins/armdigitaltwins) package, by following the [Go SDK migration guidance](https://github.com/Azure/azure-sdk-for-go/blob/main/documentation/development/ARM/MIGRATION_GUIDE.md).
 
 
 ## Migrate from 2021-06-30-preview control plane API 

articles/event-hubs/apache-kafka-configurations.md

@@ -26,7 +26,7 @@ Producer configs can be found [here](https://kafka.apache.org/documentation/#pro
 |---|---:|---:|---|
 |`max.request.size` | 1000000 | < 1046528 | The service closes connections if requests larger than 1,046,528 bytes are sent. *This value **must** be changed and causes issues in high-throughput produce scenarios.*|
 |`retries` | > 0 | | Might require increasing `delivery.timeout.ms` value, see documentation.|
-|`request.timeout.ms` | 30000 .. 60000 | > 20000| Event Hubs internally defaults to a minimum of 20,000 ms. *While requests with lower time out values are accepted, client behavior isn't guaranteed.* <p>Make sure that your **request.timeout.ms** is at least the recommended value of 60000 and your **session.timeout.ms** is at least the recommended value of 30000. Having these settings too low could cause consumer time-outs, which then cause rebalances (which then cause more time-outs, which cause more rebalancing, and so on).</p>|
+|`request.timeout.ms` | 30000 .. 60000 | > 20000| Event Hubs internally defaults to a minimum of 20,000 ms. Producer timeouts are safe with values as low as 10,000 ms and won't be a problem for producers. <p>Make sure that your **request.timeout.ms** is at least the recommended value of 60000 and your **session.timeout.ms** is at least the recommended value of 30000. Having these settings too low could cause consumer time-outs, which then cause rebalances (which then cause more time-outs, which cause more rebalancing, and so on).</p>|
 |`metadata.max.idle.ms` | 180000 | > 5000 | Controls how long the producer caches metadata for a topic that's idle. If the elapsed time since a topic was last produced exceeds the metadata idle duration, then the topic's metadata is forgotten and the next access to it will force a metadata fetch request.|
 |`linger.ms` | > 0 | | For high throughput scenarios, linger value should be equal to the highest tolerable value to take advantage of batching.|
 |`delivery.timeout.ms` | | | Set according to the formula (`request.timeout.ms` + `linger.ms`) * `retries`.|

articles/governance/resource-graph/concepts/azure-resource-graph-get-list-api.md

@@ -133,6 +133,22 @@ For this specific example, use the following requests to retrieve the list of st
 HTTP GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/microsoft.storage/storageAccounts?api-version=2024-01-01&useResourceGraph=true 
 ```
 
+## Building Resilient Resource Queries with ARG and  Resource Provider Approach 
+
+In scenarios where data quality and reliability are critical, a hybrid querying strategy is highly recommended. This approach combines Azure Resource Graph (ARG) calls with a fallback to the Resource Provider (RP) API, which serves as the source of truth for each resource. By introducing intelligent logic that automatically triggers a fallback when data freshness issues, indexing delays, or latency problems arise, you can significantly improve the resilience of your solution. This ensures that users experience minimal disruption and continue to receive accurate, up-to-date resource information. 
+
+### A common scenario: polling immediately after resource creation 
+
+Many users poll resources immediately after creation—sometimes within 1–2 seconds—as part of a write workflow, as an example - until resource provisioningState reaches a final state, or until certain properties appear in the response. Since ARG indexing may not have completed yet, callers may receive 404 Not Found even though the resource exists. In these cases, a hybrid strategy helps avoid false negatives. 
+
+Two Workarounds to handle the brief window before ARG indexing completes, you can: 
+
+1. Retry using the useResourceGraph=true flag a few times until the call returns 200 OK. 
+
+2. Retry without the useResourceGraph=true flag to fall back directly to the Resource Provider API. 
+
+Both strategies help ensure that users always retrieve the most accurate state of the resource—without being impacted by short-lived data freshness gaps. 
+
 ## Known Limitations  
 
 - **VMSS VM health status** isn't currently supported. If you require this data, you can share your scenario and propose the feature addition on our [feedback forums](https://feedback.azure.com/d365community/forum/675ae472-f324-ec11-b6e6-000d3a4f0da0).
@@ -253,4 +269,12 @@ internal class ArgGetListHttpPipelinePolicy : HttpPipelineSynchronousPolicy
 
 - What should I do if I encounter issues while using the useResourceGraph parameter when calling Azure Resource Graph?
 
-    If you experience any issues while using the `useResourceGraph` parameter with ARG, create a support ticket under the Azure Resource Graph service in the [Azure portal](https://ms.portal.azure.com/#home) under **Help + Support.**
+    If you experience any issues while using the `useResourceGraph` parameter with ARG, create a support ticket under the Azure Resource Graph service in the [Azure portal](https://ms.portal.azure.com/#home) under **Help + Support.**
+
+- How do you differentiate between ARM and ARG throttling?
+
+    Please refer to [differentiating between throttling request for ARG and ARM](/azure/governance/resource-graph/concepts/guidance-for-throttled-requests).
+
+- What should I do if ARG GET/LIST API is down?
+    
+    Treat it as a backend Resource Provider down scenario with a 500 Internal Server Error. ARM does not auto-retry, so first retry with `useResourceGraph=true`. If it still fails, retry without the flag and the call will go directly to the Resource Provider.

articles/governance/resource-graph/concepts/get-list-query-service-differences.md

@@ -0,0 +1,26 @@
+---
+title: Differences between ARG GET/LIST API and ARG Query service
+description: How is Azure Resource Graph (ARG) GET/LIST API is different than Azure Resource Graph Query service 
+ms.date: 12/2/2025
+ms.topic: reference
+ms.custom: devx-track-csharp
+---
+
+# Differences between Azure Resource Graph (ARG) GET/LIST API and ARG Query service
+
+Azure Resource Graph (ARG) provides a unified, aggregated data store that consolidates resource information from all Resource Providers. This lets you query and retrieve resource details efficiently, with lower latency and substantially higher throttling quotas compared to traditional Azure Resource Manager APIs. ARG is powerful when you need to understand the state of resources at scale—across multiple subscriptions, resource groups, or large environments. 
+
+The ARG GET/LIST API extends this value even further. As a new capability within the ARG ecosystem, it delivers even higher throttling quotas specifically for point GET and LIST calls, making it ideal for services that frequently perform targeted resource lookups. 
+
+Below is a comparison table outlining how ARG Query and ARG GET/LIST API differ, and how each caters to specific scenarios—helping you decide which solution best fits your workload:
+
+| | ARG Query API | ARG GET/LIST API |
+|----|-----|-----|
+|**Solution description** | Use Azure Resource Graph query API for querying resources and Azure inventory. ARG query supports many resource types that are part of a table in Resource Graph. See the full list of [resource types tables](/azure/governance/resource-graph/reference/supported-tables-resources). |Use Azure Resource Graph GET/LIST API for querying resources and Azure inventory. The ARG GET/LIST API is currently supported only for resources in the [resources](/azure/governance/resource-graph/reference/supported-tables-resources#resources) and [computeresources](/azure/governance/resource-graph/reference/supported-tables-resources#computeresources) tables. |
+| **Supported clients** | Querying experience is available through [ARG Explorer in the Azure portal](/azure/governance/resource-graph/first-query-portal), Azure PowerShell, AzureCLI, SDKs, REST API etc. | The current experience is available through supported Azure REST APIs and certain SDKs. |
+| **API** | POST /resources: [Run Azure Resource Graph query using REST API - Azure Resource Graph Microsoft Learn](/azure/governance/resource-graph/first-query-rest-api?tabs=powershell#review-the-rest-api-syntax) | ARG GET/LIST API uses the existing control plane GET APIs appending the flag `useResourceGraph=true` to the APIs that seamlessly routes the call to the ARG GET/LIST backend. |
+| **Ideal for scenarios** | ARG Query API is a tenant level API that is meant for bulk lookups where you have a requirement to join across multiple tenants, subscriptions, resource group, MG etc., for complex analytical scenarios. Example: “Show me all resources across subscriptions”  | ARG GET/LIST API serves as a Lookup source for the entire Azure GET & LIST API path against a single subscription or resource group meant for high concurrency, high throughput and low complexity kind of scenarios. Example: “List all VMs under a specific subscription”  | 
+| **Throttling quota** | Generally lower than ARG GE/LIST API. A user can send at most 15 queries within every 5-second window 1. However this is a soft limit and is subject to change based on users calling pattern.  | Aligns with the Azure Resource Manager limits, currently set upto 4k per minute, user, and subscription. It’s a soft limit and can be raised based on scenario.  |
+| **Consistency level** | Bounded Staleness consistency level, which means data is indexed in ARG with a certain latency. | Bounded Staleness consistency level, which means data is indexed in ARG with a certain latency.|
+|**Product lifecycle stage** | Generally available | Generally available |
+| **Pricing**| Free | Free |

articles/governance/resource-graph/concepts/guidance-for-throttled-requests.md

@@ -228,7 +228,7 @@ while (!string.IsNullOrEmpty(azureOperationResponse.Body.SkipToken))
 
 ## Differentiate between throttling requests for ARG and ARM
 
-When using the ARG GET / LIST API, you may encounter throttling errors in response to your requests. It’s important to identify the source of throttling, as it can occur at two levels:
+When using ARG, you may encounter throttling errors in response to your requests. It’s important to identify the source of throttling, as it can occur at two levels:
 
 - ARG API throttling: limits applied by Azure Resource Graph.
 - ARM throttling: limits enforced by Azure Resource Manager.
@@ -271,15 +271,21 @@ ARG is introducing an alternative approach to the existing Azure control plane G
 
 The ARG GET/LIST API is meant to address scenarios where you need a lookup of a single resource by ID, or you’re listing resources under the same type and within a certain scope (subscription, resource group, or parent resource). 
 
-You should consider the ARG GET/LIST API if your service falls into one (or many) of the following categories: 
+You should consider using the ARG GET/LIST API if your service fits into one or more of the following categories: 
 
-- Your service is issuing a large volume of GET calls to retrieve data for a resource targeted to a single subscription or a single RG and do not require batches of records from multiple subscriptions through complex filtering or joins. 
-- Your service issues a large volume of GET requests, and is at risk of: 
-    - Facing throttling. 
-    - Competing for throttling quota with other customers. 
-    - Your service may be or is prone to issuing a large burst of concurrent GET requests within a short period of time. 
-- Your service requires high availability and faster performance for GET requests, for single resource management or enumeration of a list of resources within a certain scope. 
-- You require full instanceView of VMs and VMSS VMs in Uniform as well as Flex orchestration mode. 
+- **High Volume of GET Calls Within a Single Scope:** 
+    Your service issues a large number of GET requests targeting resources within a single subscription or resource group, without the need for cross-subscription queries, complex filters, or joins. 
+
+- **Risk of Throttling or Quota Competition:** 
+Your service produces a high volume of requests and may encounter issues such as: 
+    - Experience throttling during sudden traffic spikes. 
+    - Quota competition, where other workloads in the same subscription consume shared quota limits, causing your service to be throttled. 
+    - Bursty traffic patterns, where large volume of GET requests are issued within a short time window, increasing the chance of throttling. 
+
+- **Need for High Availability and Faster Performance:**
+    Your service depends on consistent; low-latency GET operations for either single-resource lookups or listing resources within a specific scope. 
+
+- You require full `instanceView` of VMs and VMSS VMs in Uniform as well as Flex orchestration mode. 
 
   > [!NOTE]
   > ARG GET/LIST API doesn't support VM and VMSS VM Health Status and extension running status in the instanceView. To learn more about the ARG GET/LIST API limits, see the [known limitations](./azure-resource-graph-get-list-api.md#known-limitations).

articles/governance/resource-graph/toc.yml

@@ -81,6 +81,8 @@
     href: ./concepts/guidance-for-throttled-requests.md
   - name: Guidance for the Azure Resource Graph GET/LIST API 
     href: ./concepts/azure-resource-graph-get-list-api.md
+  - name: Differences between the Azure Resource Graph GET/LIST API and Azure Resource Graph Query service
+    href: ./concepts/get-list-query-service-differences.md
   - name: Security
     items:
     - name: Security baseline for Azure Security Benchmark

articles/internet-peering/walkthrough-communications-services-partner.md

@@ -217,10 +217,6 @@ Get answers to frequently asked questions.
 
 **A.** Yes. A private ASN can't be in the AS path. For registered prefixes smaller than \/24, the AS path must be less than 4.
 
-**Q.** I need to set the prefix limit. How many routes will Microsoft announce?
-
-**A.** Microsoft announces roughly 280 prefixes on the internet. The number might increase by 10% to 15%. A limit of 400 to 500 is safe to set as the value for **Max prefix count**.
-
 **Q.** Will Microsoft readvertise peer prefixes to the internet?
 
 **A.** No.

articles/load-balancer/skus.md

@@ -17,11 +17,11 @@ ms.custom: template-reference, engagement-fy23
 >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. For guidance on upgrading, visit [Upgrading from Basic Load Balancer - Guidance](load-balancer-basic-upgrade-guidance.md).
 
 ## <a name="skus"></a> SKU comparison
-Azure Load Balancer has three stock-keeping units (SKUs) - Basic, Standard, and Gateway. Each SKU is catered towards a specific scenario and has differences in scale, features, and pricing. 
+Azure Load Balancer has three stock-keeping units (SKUs) - Basic(Retired), Standard, and Gateway. Each SKU is catered towards a specific scenario and has differences in scale, features, and pricing. 
 
-To compare and understand the differences between Basic and Standard SKU, see the following table. 
+To compare and understand the differences between Basic(Retired) and Standard SKU, see the following table. 
 
-| | Standard Load Balancer | Basic Load Balancer |
+| | Standard Load Balancer | Basic Load Balancer (retired) |
 | --- | --- | --- |
 | **Scenario** |  Equipped for load-balancing network layer traffic when high performance and ultra-low latency is needed. Routes traffic within and across regions, and to availability zones for high resiliency. | Equipped for small-scale applications that don't need high availability or redundancy. Not compatible with availability zones. |
 | **Backend type** | IP based, NIC based | NIC based |