Merge branch 'MicrosoftDocs:main' into main

Author: ZarrVenkat

.openpublishing.redirection.json

@@ -145,6 +145,11 @@
       "redirect_url": "/previous-versions/azure/azure-app-configuration/rest-api-fiddler",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/articles/azure-app-configuration/run-experiments-aspnet-core.md",
+      "redirect_url": "/azure/azure-app-configuration/concept-experimentation",
+      "redirect_document_id": false
+    },
     {
       "source_path_from_root": "/articles/public-multi-access-edge-compute-mec/considerations-for-deployment.md",
       "redirect_url": "/previous-versions/azure/public-multi-access-edge-compute-mec/considerations-for-deployment",

articles/active-directory-b2c/custom-domain.md

@@ -108,7 +108,7 @@ Follow these steps to create an Azure Front Door:
 
 1. To choose the directory that contains the Azure subscription that you’d like to use for Azure Front Door and *not* the directory containing your Azure AD B2C tenant select the **Settings** icon in the top menu to switch to your Azure AD B2C tenant from the **Directories + subscriptions** menu.
 
-1. Follow the steps in [Create Front Door profile - Quick Create](../frontdoor/create-front-door-portal.md#create-front-door-profile---quick-create) to create a Front Door for your Azure AD B2C tenant using the following settings: 
+1. Follow the steps in [Create Front Door profile - Quick Create](../frontdoor/create-front-door-portal.md#create-an-azure-front-door-profile) to create a Front Door for your Azure AD B2C tenant using the following settings: 
 
 
     |Key  |Value  |
@@ -202,7 +202,7 @@ To create a CNAME record for your custom domain:
 The **default-route** routes the traffic from the client to Azure Front Door. Then, Azure Front Door uses your configuration to send the traffic to Azure AD B2C. Follow these steps to enable the default-route.
 
 1. Select **Front Door manager**.
-1. To add enable the **default-route**, first expand an endpoint from the list of endpoints in the Front Door manager. Then, select the **default-route**. 
+1. To enable the **default-route**, first expand an endpoint from the list of endpoints in the Front Door manager. Then, select the **default-route**. 
 
     The following screenshot shows how to select the default-route.
 

articles/app-service/configure-language-java-deploy-run.md

@@ -473,7 +473,7 @@ When clustering is enabled, the JBoss EAP instances use the FILE_PING JGroups di
 > [!Note]
 > You can avoid JBoss clustering timeouts by [cleaning up obsolete discovery files during your app startup](https://github.com/Azure/app-service-linux-docs/blob/master/HowTo/JBOSS/avoid_timeouts_obsolete_nodes.md).
 
-The Premium V3 and Isolated V2 App Service Plan types can optionally be distributed across Availability Zones to improve resiliency and reliability for your business-critical workloads. This architecture is also known as [zone redundancy](../availability-zones/migrate-app-service.md). The JBoss EAP clustering feature is compatible with the zone redundancy feature.
+The Premium V3 and Isolated V2 App Service Plan types can optionally be distributed across Availability Zones to improve resiliency and reliability for your business-critical workloads. This architecture is also known as [zone redundancy](../reliability/migrate-app-service.md). The JBoss EAP clustering feature is compatible with the zone redundancy feature.
 
 ### Autoscale Rules
 

articles/app-service/environment/migrate.md

@@ -33,7 +33,7 @@ At this time, the in-place migration feature doesn't support migrations to App S
 - China East 2
 - China North 2
 
-The following App Service Environment configurations can be migrated using the in-place migration feature. The table gives the App Service Environment v3 configuration when using the in-place migration feature based on your existing App Service Environment. All supported App Service Environments can be migrated to a [zone redundant App Service Environment v3](../../availability-zones/migrate-app-service-environment.md) using the in-place migration feature as long as the environment is [in a region that supports zone redundancy](./overview.md#regions). You can [configure zone redundancy](#choose-your-app-service-environment-v3-configurations) during the migration process.
+The following App Service Environment configurations can be migrated using the in-place migration feature. The table gives the App Service Environment v3 configuration when using the in-place migration feature based on your existing App Service Environment. All supported App Service Environments can be migrated to a [zone redundant App Service Environment v3](../../reliability/migrate-app-service-environment.md) using the in-place migration feature as long as the environment is [in a region that supports zone redundancy](./overview.md#regions). You can [configure zone redundancy](#choose-your-app-service-environment-v3-configurations) during the migration process.
 
 |Configuration                                                                                      |App Service Environment v3 Configuration                   |
 |---------------------------------------------------------------------------------------------------|-----------------------------------------------------------|
@@ -136,10 +136,10 @@ Azure Policy can be used to deny resource creation and modification to certain p
 
 ### Choose your App Service Environment v3 configurations
 
-Your App Service Environment v3 can be deployed across availability zones in the regions that support it. This architecture is known as [zone redundancy](../../availability-zones/migrate-app-service-environment.md). Zone redundancy can only be configured during App Service Environment creation. If you want your new App Service Environment v3 to be zone redundant, enable the configuration during the migration process. Any App Service Environment that is using the in-place migration feature to migrate can be configured as zone redundant as long as you're using a [region that supports zone redundancy for App Service Environment v3](./overview.md#regions). If you're existing environment is in a region that doesn't support zone redundancy, the configuration option is disabled and you can't configure it. The in-place migration feature doesn't support changing regions. If you'd like to use a different region, use one of the [manual migration options](migration-alternatives.md).
+Your App Service Environment v3 can be deployed across availability zones in the regions that support it. This architecture is known as [zone redundancy](../../reliability/migrate-app-service-environment.md). Zone redundancy can only be configured during App Service Environment creation. If you want your new App Service Environment v3 to be zone redundant, enable the configuration during the migration process. Any App Service Environment that is using the in-place migration feature to migrate can be configured as zone redundant as long as you're using a [region that supports zone redundancy for App Service Environment v3](./overview.md#regions). If you're existing environment is in a region that doesn't support zone redundancy, the configuration option is disabled and you can't configure it. The in-place migration feature doesn't support changing regions. If you'd like to use a different region, use one of the [manual migration options](migration-alternatives.md).
 
 > [!NOTE]
-> Enabling zone redundancy can lead to additional charges. Review the [zone redundancy pricing model](../../availability-zones/migrate-app-service-environment.md#pricing) for more information.
+> Enabling zone redundancy can lead to additional charges. Review the [zone redundancy pricing model](../../reliability/migrate-app-service-environment.md#pricing) for more information.
 >
 
 If your existing App Service Environment uses a custom domain suffix, you're prompted to configure a custom domain suffix for your new App Service Environment v3. You need to provide the custom domain name, managed identity, and certificate. For more information on App Service Environment v3 custom domain suffix including requirements, step-by-step instructions, and best practices, see [Configure custom domain suffix for App Service Environment](./how-to-custom-domain-suffix.md). You must configure a custom domain suffix for your new environment even if you no longer want to use it. Once migration is complete, you can remove the custom domain suffix configuration if needed.

articles/app-service/environment/networking.md

@@ -16,7 +16,11 @@ App Service Environment is a single-tenant deployment of Azure App Service that
 
 ## Subnet requirements
 
-You must delegate the subnet to `Microsoft.Web/hostingEnvironments`, and the subnet must be empty.
+The following are the minimum set of requirements for the subnet your App Service Environment is in.
+
+- The subnet must be delegated to `Microsoft.Web/hostingEnvironments`.
+- The subnet must be empty.
+- The subnet's `addressPrefix` property must be formatted as a string, not an array. 
 
 The size of the subnet can affect the scaling limits of the App Service plan instances within the App Service Environment. For production scale, we recommend a `/24` address space (256 addresses) for your subnet. If you plan to scale near max capacity of 200 instances in our App Service Environment and you plan frequent up/down scale operations, we recommend a `/23` address space (512 addresses) for your subnet.
 

articles/app-service/environment/overview.md

@@ -69,7 +69,7 @@ A benefit of using an App Service Environment instead of a multitenant service i
 App Service Environment v3 differs from earlier versions in the following ways:
 
 - There are no networking dependencies on the customer's virtual network. You can secure all inbound and outbound traffic and route outbound traffic as you want.
-- You can deploy an App Service Environment v3 that's enabled for zone redundancy. You set zone redundancy only during creation and only in regions where all App Service Environment v3 dependencies are zone redundant. Zone redundancy is a deployment time only decision. Changing zone redundancy isn't possible after it has been deployed. With zone redundant App Service Environment, each App Service Plan on the App Service Environment needs to have a minimum of three instances so that they can be spread across zones. For more information, see [Migrate App Service Environment to availability zone support](../../availability-zones/migrate-app-service-environment.md).
+- You can deploy an App Service Environment v3 that's enabled for zone redundancy. You set zone redundancy only during creation and only in regions where all App Service Environment v3 dependencies are zone redundant. Zone redundancy is a deployment time only decision. Changing zone redundancy isn't possible after it has been deployed. With zone redundant App Service Environment, each App Service Plan on the App Service Environment needs to have a minimum of three instances so that they can be spread across zones. For more information, see [Migrate App Service Environment to availability zone support](../../reliability/migrate-app-service-environment.md).
 - You can deploy an App Service Environment v3 on a dedicated host group. Host group deployments aren't zone redundant.
 - Scaling is faster than with an App Service Environment v2. Although scaling still isn't immediate, as in the multitenant service, it's a lot faster.
 - Front-end scaling adjustments are no longer required. App Service Environment v3 front ends automatically scale to meet your needs and are deployed on better hosts.

articles/app-service/environment/side-by-side-migrate.md

@@ -56,7 +56,7 @@ The following App Service Environment configurations can be migrated using the s
 |[External (ELB/internet facing with public IP)](create-external-ase.md) App Service Environment v2 |ELB App Service Environment v3                             |
 |ILB App Service Environment v2 with a custom domain suffix                                         |ILB App Service Environment v3 with a custom domain suffix |
 
-App Service Environment v3 can be deployed as [zone redundant](../../availability-zones/migrate-app-service-environment.md). Zone redundancy can be enabled as long as your App Service Environment v3 is [in a region that supports zone redundancy](./overview.md#regions).
+App Service Environment v3 can be deployed as [zone redundant](../../reliability/migrate-app-service-environment.md). Zone redundancy can be enabled as long as your App Service Environment v3 is [in a region that supports zone redundancy](./overview.md#regions).
 
 If you want your new App Service Environment v3 to use a custom domain suffix and you aren't using one currently, custom domain suffix can be configured at any time once migration is complete. For more information, see [Configure custom domain suffix for App Service Environment](./how-to-custom-domain-suffix.md). If your existing environment has a custom domain suffix and you no longer want to use it, you must configure a custom domain suffix for the migration. You can remove the custom domain suffix after migration is complete.
 

articles/app-service/environment/toc.yml

@@ -28,7 +28,7 @@
   - name: Resiliency
     items:
     - name: Migrate to availability zone support
-      href: ../../availability-zones/migrate-app-service-environment.md
+      href: ../../reliability/migrate-app-service-environment.md
   - name: Certificates
     href: overview-certificates.md
   - name: Diagnostics

articles/app-service/networking-features.md

@@ -118,8 +118,14 @@ Some use cases for this feature:
 * Expose your app on a private IP in your virtual network. 
 * Protect your app with a WAF.
 
-Private endpoints prevent data exfiltration because the only thing you can reach across the private endpoint is the app with which it's configured. 
- 
+Private endpoints prevent data exfiltration because the only thing you can reach across the private endpoint is the app with which it's configured.
+
+### Network Security Perimeter
+
+Azure [Network Security Perimeter](../private-link/network-security-perimeter-concepts.md) (NSP) is a service that provides a secure perimeter for communication of Platform as a Service (PaaS) services. These PaaS services can communicate with each other within the perimeter, and can also communicate with resources outside the perimeter using public inbound and outbound access rules.
+
+NSP rule enforcement is primarily using identity-based security which cannot be fully enforced in platform services like App Services and Functions that allow you to deploy your own code and use the identity to represent the platform. If you need to communicate with PaaS services that are part of an NSP you will need to add virtual network integration to you App Service or Functions instances and communicate with the PaaS resources using private endpoints.
+
 ### Hybrid Connections
 
 App Service Hybrid Connections enables your apps to make *outbound* calls to specified TCP endpoints. The endpoint can be on-premises, in a virtual network, or anywhere that allows outbound traffic to Azure on port 443. To use the feature, you need to install a relay agent called Hybrid Connection Manager on a Windows Server 2012 or newer host. Hybrid Connection Manager needs to be able to reach Azure Relay at port 443. You can download Hybrid Connection Manager from the App Service Hybrid Connections UI in the portal. 

articles/app-service/tutorial-multi-region-app.md

@@ -45,7 +45,7 @@ To complete this tutorial:
 
 ## Create two instances of a web app
 
-You need two instances of a web app that run in different Azure regions for this tutorial. You use the [region pair](../availability-zones/cross-region-replication-azure.md#azure-paired-regions) East US/West US as your two regions and create two empty web apps. Feel free to choose your own regions if needed.
+You need two instances of a web app that run in different Azure regions for this tutorial. You use the [region pair](../reliability/cross-region-replication-azure.md#azure-paired-regions) East US/West US as your two regions and create two empty web apps. Feel free to choose your own regions if needed.
 
 To make management and clean-up simpler, you use a single resource group for all resources in this tutorial. Consider using separate resource groups for each region/resource to further isolate your resources in a disaster recovery situation.