Merge branch 'main' into release-rsa-sentinel-platform

Author: v-alje

articles/api-management/v2-service-tiers-overview.md

@@ -6,7 +6,7 @@ author: dlepow
 
 ms.service: azure-api-management
 ms.topic: concept-article
-ms.date: 02/05/2026
+ms.date: 03/27/2026
 ms.author: danlep
 ms.custom:
   - references_regions
@@ -17,11 +17,11 @@ ms.custom:
 
 [!INCLUDE [api-management-availability-basicv2-standardv2-premiumv2](../../includes/api-management-availability-basicv2-standardv2-premiumv2.md)]
 
-The API Management v2 tiers (SKUs) are built on a new, more reliable and scalable platform and are designed to make API Management accessible to a broader set of customers and offer flexible options for a wider variety of scenarios. The v2 tiers are in addition to the existing classic tiers (Developer, Basic, Standard, and Premium) and the Consumption tier. [See detailed comparison of API Management tiers](api-management-features.md).
+The API Management v2 tiers (SKUs) are built on a new, more reliable and scalable platform. They're designed to make API Management accessible to a broader set of customers and offer flexible options for a wider variety of scenarios. The v2 tiers are in addition to the existing classic tiers (Developer, Basic, Standard, and Premium) and the Consumption tier. [See detailed comparison of API Management tiers](api-management-features.md).
 
 The following v2 tiers are generally available:
 
-* **Basic v2** - The Basic v2 tier is designed for development and testing scenarios, and is supported with an SLA.
+* **Basic v2** - The Basic v2 tier is designed for development and testing scenarios, and it comes with an SLA.
 
 * **Standard v2** - Standard v2 is a production-ready tier with support for network-isolated backends.
 
@@ -33,7 +33,7 @@ The following v2 tiers are generally available:
 
 * **Simplified networking** - The Standard v2 and Premium v2 tiers provide [networking options](#networking-options) to isolate API Management's inbound and outbound traffic.
 
-* **More options for production workloads** - The v2 tiers are all supported with an SLA. 
+* **More options for production workloads** - The v2 tiers all come with an SLA. 
 
 * **Developer portal options** - Enable the [developer portal](api-management-howto-developer-portal.md) when you're ready to let API consumers discover your APIs. 
 
@@ -42,11 +42,11 @@ The following v2 tiers are generally available:
 
 ### API version
 
-The latest capabilities of the v2 tiers are supported in API Management API version **2024-05-01** or later.
+API Management supports the latest capabilities of the v2 tiers in API version **2024-05-01** or later.
 
 ## Networking options
 
-* **Standard v2** and **Premium v2** support **virtual network integration** to allow your API Management instance to reach API backends that are isolated in a single connected virtual network. The API Management gateway, management plane, and developer portal remain publicly accessible from the internet. The virtual network must be in the same region and subscription as the API Management instance. [Learn more](integrate-vnet-outbound.md).
+* **Standard v2** and **Premium v2** support **virtual network integration**. This feature allows your API Management instance to reach API backends that are isolated in a single connected virtual network. The API Management gateway, management plane, and developer portal remain publicly accessible from the internet. The virtual network must be in the same region and subscription as the API Management instance. [Learn more](integrate-vnet-outbound.md).
 
 * **Standard v2** and **Premium v2** also support inbound [private endpoint connections](private-endpoint.md) to the API Management gateway.
 
@@ -58,7 +58,7 @@ For a current list of regions where the v2 tiers are available, see [Availabilit
 
 ### Classic feature availability
 
-Most capabilities of the classic API Management tiers are supported directly in the v2 tiers. However, some features have replacements in the v2 tiers, and some currently aren't available. For detailed comparisons, see 
+The v2 tiers support most capabilities of the classic API Management tiers. However, some features have replacements in the v2 tiers, and some features currently aren't available. For detailed comparisons, see: 
 
 * [Feature-based comparison of the Azure API Management tiers](api-management-features.md)
 * [API Management gateways overview](api-management-gateways-overview.md)
@@ -76,7 +76,7 @@ Most capabilities of the classic API Management tiers are supported directly in
 
 #### Currently unavailable features
 
-The following are currently unavailable in the v2 tiers.
+The following features are currently unavailable in the v2 tiers.
 
 **Infrastructure and configuration**
 * Multi-region deployment 
@@ -111,15 +111,15 @@ The following limits apply to the v2 tiers:
 
 ## Deployment
 
-Deploy a v2 tier instance using the Azure portal or using tools such as the Azure REST API, Azure Resource Manager, Bicep file, or Terraform.
+Deploy a v2 tier instance by using the Azure portal or tools such as the Azure REST API, Azure Resource Manager, Bicep file, or Terraform.
 
 ## Frequently asked questions
 
 ### Q: Can I migrate from my existing API Management instance to a new v2 tier instance?
 
-A: No. Currently you can't migrate an existing API Management instance (in the Consumption, Developer, Basic, Standard, or Premium tier) to a new v2 tier instance. Currently the v2 tiers are available for newly created service instances only.
+A: No. Currently, there's no automated tooling to migrate an existing API Management instance (in the Consumption, Developer, Basic, Standard, or Premium tier) to a new v2 tier instance. The v2 tiers are currently available for newly created service instances only.
 
-### Q: Will I still be able to provision Developer, Basic, Standard, or Premium tier services? 
+### Q: Can I still provision Developer, Basic, Standard, or Premium tier services? 
 
 A: Yes, there are no changes to the classic Developer, Basic, Standard, or Premium tiers. 
 
@@ -135,10 +135,10 @@ A: No, such a deployment is only supported in the Premium and Premium v2 tiers.
 
 ### Q: What's the relationship between the stv2 compute platform and the v2 tiers?
 
-A: They're not related. stv2 is a compute platform version of the Developer, Basic, Standard, and Premium tier service instances. stv2 is a successor to the stv1 compute platform that retired in 2024.
+A: There's no relationship. The stv2 compute platform is a compute platform version of the Developer, Basic, Standard, and Premium tiers only. It's the successor to the stv1 compute platform that retired in 2024.
 
 ## Related content
 
 * Compare the API Management [tiers](api-management-features.md).
-* Learn more about the [API Management gateways](api-management-gateways-overview.md)
+* Learn more about the [API Management gateways](api-management-gateways-overview.md).
 * Learn about [API Management pricing](https://azure.microsoft.com/pricing/details/api-management/).

articles/app-service/app-service-hybrid-connections.md

@@ -296,7 +296,7 @@ After you edit the configuration file, restart the Hybrid Connection Manager ser
 - **Windows**: Restart the service through **Services** from the **Start Menu**.
 - **Linux**: Run `systemctl restart hybridconnectionmanager.service`.
 
-Configuring a proxy server routes requests from the Hybrid Connection Manager through the selected proxy server before reaching the destination. Ensure your proxy server supports HTTP/HTTPS traffic so that the Hybrid Connection Manager can communicate with the Azure Relay Service.
+Configuring a proxy server routes requests from the Hybrid Connection Manager through the selected proxy server before reaching the destination. Ensure your proxy server supports HTTP/HTTPS and WebSocket traffic over port 443 so that the Hybrid Connection Manager can communicate with Azure Relay. If your proxy supports DNS allowlisting, allow `*.servicebus.windows.net`. If you can't use a wildcard, allow the specific Relay namespace hostname and the gateway hostnames for that namespace.
 
 > [!NOTE]
 > All addresses set in `appsettings.json` (`ProxyAddress`, `BypassList`) should be in RegEx format if not an exact match.
@@ -387,7 +387,7 @@ The status of **Connected** means that at least one Hybrid Connection Manager is
 - Does your host have outbound access to Azure on port 443? You can test from your Hybrid Connection Manager host using the PowerShell command `Test-NetConnection Destination -P Port`.
 - Is your Hybrid Connection Manager potentially in a bad state? Try restarting the **Azure Hybrid Connection Manager Service** local service.
 - Do you have conflicting software installed? Hybrid Connection Manager can't coexist with Biztalk Hybrid Connection Manager or Service Bus for Windows Server. When you install the Hybrid Connection Manager, you should remove any versions of these packages first.
-- Do you have a firewall between your Hybrid Connection Manager host and Azure? If so, you need to allow outbound access to both the Service Bus endpoint URL *AND* the Service Bus gateways that service your Hybrid Connection.
+- Do you have a firewall between your Hybrid Connection Manager host and Azure? If so, allow outbound HTTPS and WebSocket traffic over port 443. If your firewall supports DNS allowlisting, allow `*.servicebus.windows.net`, which is the preferred configuration. If you can't use a wildcard, allow the Relay namespace hostname and the gateway hostnames for that namespace. IP allowlists aren't recommended because the Relay gateway IP addresses can change.
 
   - You can find the Service Bus endpoint URL in the Hybrid Connection Manager GUI.
 
@@ -397,31 +397,33 @@ The status of **Connected** means that at least one Hybrid Connection Manager is
   
     :::image type="content" source="media/app-service-hybrid-connections/hybrid-connections-service-bus-endpoint-cli.png" alt-text="Screenshot of Hybrid Connection Service Bus endpoint in the CLI.":::
 
-  - The Service Bus gateways are the resources that accept the request into the Hybrid Connection and pass it through the Azure Relay. You need to allow list all of the gateways. The gateways are in the format: `G#-prod-[stamp]-sb.servicebus.windows.net` and `GV#-prod-[stamp]-sb.servicebus.windows.net`. The number sign, `#`, is a number between 0 and 127 and `stamp` is the name of the instance within your Azure data center where your Service Bus endpoint exists.
+  - The Service Bus gateways are the resources that accept the request into the Hybrid Connection and pass it through Azure Relay. The gateway hostnames are in the format `G#-prod-[stamp]-sb.servicebus.windows.net` and `GV#-prod-[stamp]-sb.servicebus.windows.net`. The number sign, `#`, is a number between 0 and 127 and `stamp` is the name of the instance within your Azure datacenter where your Service Bus endpoint exists.
 
-  - If you can use a wildcard, you can allow list *\*.servicebus.windows.net*.
-  - If you can't use a wildcard, you must allow list all 256 of the gateways.
+  - If your firewall or proxy supports DNS allowlisting, allow `*.servicebus.windows.net`. This approach is simpler to maintain and avoids relying on changing IP addresses.
+  - If your firewall or proxy doesn't support wildcard DNS rules, allow the namespace hostname shown in the Hybrid Connection Manager and all gateway hostnames for that namespace. Use hostnames, not IP addresses.
 
     You can find out the stamp using *nslookup* on the Service Bus endpoint URL.
 
     :::image type="content" source="media/app-service-hybrid-connections/hybrid-connections-stamp-name.png" alt-text="Screenshot of terminal showing where to find the stamp name for the Service Bus.":::
 
-    In this example, the stamp is `sn3-010`. To allow list the Service Bus gateways, you need the following entries:
-
-    G0-prod-sn3-010-sb.servicebus.windows.net  
-    G1-prod-sn3-010-sb.servicebus.windows.net  
-    G2-prod-sn3-010-sb.servicebus.windows.net  
-    G3-prod-sn3-010-sb.servicebus.windows.net  
-    ...  
-    G126-prod-sn3-010-sb.servicebus.windows.net  
-    G127-prod-sn3-010-sb.servicebus.windows.net  
-    GV0-prod-sn3-010-sb.servicebus.windows.net  
-    GV1-prod-sn3-010-sb.servicebus.windows.net  
-    GV2-prod-sn3-010-sb.servicebus.windows.net  
-    GV3-prod-sn3-010-sb.servicebus.windows.net  
-    ...  
-    GV126-prod-sn3-010-sb.servicebus.windows.net  
+    In this example, the stamp is `sn3-010`. If you need namespace-specific DNS rules instead of `*.servicebus.windows.net`, allow the namespace hostname and the following gateway hostnames:
+
+    ```text
+    G0-prod-sn3-010-sb.servicebus.windows.net
+    G1-prod-sn3-010-sb.servicebus.windows.net
+    G2-prod-sn3-010-sb.servicebus.windows.net
+    G3-prod-sn3-010-sb.servicebus.windows.net
+    ...
+    G126-prod-sn3-010-sb.servicebus.windows.net
+    G127-prod-sn3-010-sb.servicebus.windows.net
+    GV0-prod-sn3-010-sb.servicebus.windows.net
+    GV1-prod-sn3-010-sb.servicebus.windows.net
+    GV2-prod-sn3-010-sb.servicebus.windows.net
+    GV3-prod-sn3-010-sb.servicebus.windows.net
+    ...
+    GV126-prod-sn3-010-sb.servicebus.windows.net
     GV127-prod-sn3-010-sb.servicebus.windows.net
+    ```
 
 If your status says **Connected** but your app can't reach your endpoint then:
 

articles/app-service/configure-authentication-provider-aad.md

@@ -80,6 +80,8 @@ To use an existing registration, select either:
 
     You can also configure the application to [use an identity instead of a client secret][fic-config]. Support for using an identity is currently in preview.
   - **Issuer URL**. This URL takes the form `<authentication-endpoint>/<tenant-id>/v2.0`. Replace `<authentication-endpoint>` with the authentication endpoint [value that's specific to the cloud environment](/entra/identity-platform/authentication-national-cloud#azure-ad-authentication-endpoints). For example, a workforce tenant in global Azure would use `https://login.microsoftonline.com` as its authentication endpoint.
+
+      You can find this value in the Microsoft Entra admin center. Go to **App registrations**, select your app, and then select **Endpoints**. Copy the **OpenID Connect metadata document** endpoint for your tenant, and then remove `/.well-known/openid-configuration` from the end of the URL. For example, if the metadata endpoint is `https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration`, use `https://login.microsoftonline.com/<tenant-id>/v2.0` as the issuer URL.
 
     > [!NOTE]
     > If you created your identity provider using the express setup (Option 1), the issuer URL is automatically set to use the legacy `https://sts.windows.net` endpoint. To align with current Microsoft Entra ID best practices, edit your identity provider and update the issuer URL to use `https://login.microsoftonline.com/<tenant-id>/v2.0` instead.
@@ -169,7 +171,7 @@ To use an existing registration, select **Provide the details of an existing app
 
 - **Application (client) ID**
 - **Client secret**
-- **Issuer URL**
+- **Issuer URL**. In the Microsoft Entra admin center, go to **App registrations**, select your app, and then select **Endpoints**. Copy the **OpenID Connect metadata document** endpoint for your tenant, and then remove `/.well-known/openid-configuration` from the end of the URL. For example, if the metadata endpoint is `https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration`, use `https://login.microsoftonline.com/<tenant-id>/v2.0` as the issuer URL.
 
 If you need to manually create an app registration in an external tenant, see [Register an app in your external tenant](/entra/external-id/customers/how-to-register-ciam-app?tabs=webapp#register-your-web-app).
 
@@ -219,6 +221,8 @@ For **Tenant requirement**, choose whether to:
 - Allow requests from specific tenants.
 - Use default restrictions based on the app registration's tenant.
 
+For **Allowed token audiences**, add any audience values that your app should accept in the `aud` claim of incoming access tokens. You commonly need this setting when clients request tokens by using the app registration's **Application ID URI**, such as `api://<application-client-id>` or a custom URI like `https://contoso.com/api`. The app registration's client ID is already accepted by default, so you typically add values here only if your app accepts another audience format.
+
 Your app might still need to make other authorization decisions in code. For more information, see [Use a built-in authorization policy](#use-a-built-in-authorization-policy) later in this article.
 
 ## Configure authentication settings