fixed merge conflict

Author: duongau

articles/api-center/build-register-apis-vscode-extension.md

@@ -28,7 +28,7 @@ The following Visual Studio Code extensions are needed for the specified scenari
 * [GitHub Actions](https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-github-actions) - to register APIs using a CI/CD pipeline with GitHub Actions
 * [Azure Pipelines](https://marketplace.visualstudio.com/items?itemName=ms-azure-devops.azure-pipelines) - to register APIs using a CI/CD pipeline with Azure Pipelines
 * [GitHub Copilot](https://marketplace.visualstudio.com/items?itemName=GitHub.copilot) - to generate OpenAPI specification files from API code
-* [GitHub Copilot for Azure](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azure-github-copilot) - to generate OpenAPI specification files using the Azure API Center Plugin for GitHub Copilot for Azure
+* [GitHub Copilot for Azure](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azure-github-copilot) - to generate OpenAPI specification files using the Azure API Center Plugin for [GitHub Copilot for Azure](/azure/developer/github-copilot-azure/introduction) (preview)
 
 [!INCLUDE [vscode-extension-setup](includes/vscode-extension-setup.md)]  
 
@@ -66,7 +66,7 @@ After generating the OpenAPI specification file and checking for accuracy, you c
 
 ## Generate OpenAPI spec using natural language prompts
 
-The API Center plugin for [GitHub Copilot for Azure](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azure-github-copilot) helps you design new APIs starting from natural language prompts. With AI assistance, quickly generate an OpenAPI spec for API development that complies with your organization's standards.
+The API Center plugin for [GitHub Copilot for Azure](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azure-github-copilot) (preview) helps you design new APIs starting from natural language prompts. With AI assistance, quickly generate an OpenAPI spec for API development that complies with your organization's standards.
 
 > [!NOTE]
 > This feature is available in the pre-release version of the API Center extension.
@@ -98,4 +98,5 @@ The API Center plugin for [GitHub Copilot for Azure](https://marketplace.visuals
 * [Discover and consume APIs with the Azure API Center extension for Visual Studio Code](discover-apis-vscode-extension.md)
 * [Govern APIs with the Azure API Center extension for Visual Studio Code](govern-apis-vscode-extension.md)
 * [Enable and view platform API catalog in Visual Studio Code](enable-platform-api-catalog-vscode-extension.md)
+* [Overview of GitHub Copilot for Azure](/azure/developer/github-copilot-azure/introduction)
 

articles/api-management/breaking-changes/workspaces-breaking-changes-march-2025.md

@@ -65,7 +65,7 @@ The following are abbreviated steps to add a workspace gateway to a workspace. F
 
 > [!NOTE]
 > * The workspace gateway incurs additional charges. For more information, see [API Management pricing](https://aka.ms/apimpricing).
-> * API Management currently supports a dedicated gateway per workspace only. If this is impacting your migration plans, see the workspaces roadmap in the [workspaces GA announcement](https://aka.ms/apim/workspaces/ga-announcement).
+> * We're introducing the ability to associate multiple workspaces with a workspace gateway, helping organizations manage APIs with workspaces at a lower cost. This feature is being rolled out starting in December 2024 and it may not be available to all eligible services before January. [Learn more](https://aka.ms/apim/workspaces/sharedgateway)
 
 1. In the [Azure portal](https://portal.azure.com), navigate to your API Management instance.
 1. In the left menu, under **APIs**, select **Workspaces**.

articles/api-management/how-to-create-workspace.md

@@ -5,7 +5,7 @@ author: dlepow
 ms.topic: how-to
 ms.service: azure-api-management
 ms.author: danlep
-ms.date: 07/10/2024
+ms.date: 11/12/2024
 ms.custom:
 ---
 
@@ -24,7 +24,8 @@ Follow the steps in this article to:
 * Assign permissions to the workspace
 
 > [!NOTE]
-> Currently, creating a workspace gateway is a long-running operation that can take up to 3 hours or more to complete. 
+> * Currently, creating a workspace gateway is a long-running operation that can take up to 3 hours or more to complete. 
+> * We're introducing the ability to associate multiple workspaces with a workspace gateway, helping organizations manage APIs with workspaces at a lower cost. This feature is being rolled out starting in December 2024 and it may not be available to all eligible services before January. [Learn more](https://aka.ms/apim/workspaces/sharedgateway)
 
 ## Prerequisites
 

articles/api-management/workspaces-overview.md

@@ -67,12 +67,13 @@ Workspace gateways are managed independently from the API Management service and
 * For information on the cost of workspace gateways, see [API Management pricing](https://aka.ms/apimpricing).
 * For a detailed comparison of API Management gateways, see [API Management gateways overview](api-management-gateways-overview.md).
 
+> [!NOTE]
+> We're introducing the ability to associate multiple workspaces with a workspace gateway, helping organizations manage APIs with workspaces at a lower cost. This feature is being rolled out starting in December 2024 and it may not be available to all eligible services before January. [Learn more](https://aka.ms/apim/workspaces/sharedgateway)
+
 ### Gateway hostname
 
 Each association of a workspace to a workspace gateway creates a unique hostname for APIs managed in that workspace. Default hostnames follow the pattern `<workspace-name>-<hash>.gateway.<region>.azure-api.net`. Currently, custom hostnames aren't supported for workspace gateways.
 
-> [!NOTE]
-> Through October 2024, APIs in workspaces can be accessed at runtime using the gateway hostname of your API Management instance in addition to the hostname of the workspace gateway.
 
 ### Network isolation
 
@@ -109,7 +110,6 @@ Workspace gateways are currently available in the following regions:
 The following constraints currently apply to workspace gateways:
 
 * A workspace gateway needs to be in the same region as the API Management instance's primary Azure region and in the same subscription. 
-* A gateway can be associated only with one workspace
 * A workspace can't be associated with a self-hosted gateway
 * Workspace gateways don't support inbound private endpoints
 * APIs in workspace gateways can't be assigned custom hostnames

articles/app-service/media/tutorial-sidecar/add-sidecar-container.png

@@ -48,7 +48,7 @@ You can use Azure Policy to help audit your resources when it comes to minimum T
 App Service also allows you to set minimum TLS version for incoming requests to your web app and to SCM site. By default, the minimum TLS version for incoming requests to your web app and to SCM is set to 1.2 on both portal and API. 
 
 ### TLS 1.3
-A [Minimum TLS Cipher Suite](#minimum-tls-cipher-suite-preview) setting is available with TLS 1.3. This includes two cipher suites at the top of the cipher suite order:
+A [Minimum TLS Cipher Suite](#minimum-tls-cipher-suite) setting is available with TLS 1.3. This includes two cipher suites at the top of the cipher suite order:
 - TLS_AES_256_GCM_SHA384  
 - TLS_AES_128_GCM_SHA256 
 
@@ -62,10 +62,10 @@ To ensure backward compatibility for TLS 1.0 and TLS 1.1, App Service will conti
 > Incoming requests to web apps and incoming requests to Azure are treated differently. App Service will continue to support TLS 1.0 and 1.1 for incoming requests to the web apps. For incoming requests directly to the Azure control plane, for example through ARM or API calls, it is not recommended to use TLS 1.0 or 1.1.
 >
 
-## Minimum TLS cipher suite (preview)
+## Minimum TLS cipher suite
 
 > [!NOTE]
-> Minimum TLS Cipher Suite is supported on Premium SKUs and higher on multi-tenant App Service.
+> Minimum TLS Cipher Suite is supported on Basic SKUs and higher on multi-tenant App Service.
 
 The minimum TLS cipher suite includes a fixed list of cipher suites with an optimal priority order that you cannot change. Reordering or reprioritizing the cipher suites is not recommended as it could expose your web apps to weaker encryption. You also cannot add new or different cipher suites to this list. When you select a minimum cipher suite, the system automatically disables all less secure cipher suites for your web app, without allowing you to selectively disable only some weaker cipher suites.
 
@@ -77,7 +77,7 @@ A cipher suite is a set of instructions that contains algorithms and protocols t
 
 For App Service Environments with `FrontEndSSLCipherSuiteOrder` cluster setting, you need to update your settings to include two TLS 1.3 cipher suites (TLS_AES_256_GCM_SHA384 and TLS_AES_128_GCM_SHA256). Once updated, restart your front-end for the change to take effect. You must still include the two required cipher suites as mentioned in the docs. 
 
-## End-to-end TLS Encryption (preview)
+## End-to-end TLS Encryption
 
 End-to-end (E2E) TLS encryption is available in Standard App Service plans and higher. Front-end intra-cluster traffic between App Service front-ends and the workers running application workloads can now be encrypted.
 

articles/app-service/media/tutorial-sidecar/app-insights-view.png

@@ -72,7 +72,7 @@ Virtual network integration depends on a dedicated subnet. When you create a sub
 
 When you scale up/down in instance size, the amount of IP addresses used by the App Service plan is temporarily doubled while the scale operation completes. The new instances need to be fully operational before the existing instances are deprovisioned. The scale operation affects the real, available supported instances for a given subnet size. Platform upgrades need free IP addresses to ensure upgrades can happen without interruptions to outbound traffic. Finally, after scale up, down, or in operations complete, there might be a short period of time before IP addresses are released. In rare cases, this operation can be up to 12 hours and if you rapidly scale in/out or up/down, you need more IPs than the maximum scale.
 
-Because subnet size can't be changed after assignment, use a subnet that's large enough to accommodate whatever scale your app might reach. You should also reserve IP addresses for platform upgrades. To avoid any issues with subnet capacity, we recommand allocating double the IPs of your planned maximum scale. A `/26` with 64 addresses cover the maximum scale of a single multitenant App Service plan. When you're creating subnets in Azure portal as part of integrating with the virtual network, a minimum size of `/27` is required. If the subnet already exists before integrating through the portal, you can use a `/28` subnet.
+Because subnet size can't be changed after assignment, use a subnet that's large enough to accommodate whatever scale your app might reach. You should also reserve IP addresses for platform upgrades. To avoid any issues with subnet capacity, we recommend allocating double the IPs of your planned maximum scale. A `/26` with 64 addresses cover the maximum scale of a single multitenant App Service plan. When you're creating subnets in Azure portal as part of integrating with the virtual network, a minimum size of `/27` is required. If the subnet already exists before integrating through the portal, you can use a `/28` subnet.
 
 With multi plan subnet join (MPSJ), you can join multiple App Service plans in to the same subnet. All App Service plans must be in the same subscription but the virtual network/subnet can be in a different subscription. Each instance from each App Service plan requires an IP address from the subnet and to use MPSJ a minimum size of `/26` subnet is required. If you plan to join many and/or large scale plans, you should plan for larger subnet ranges.