Fixing something

Author: normesta

articles/azure-functions/functions-infrastructure-as-code.md

@@ -2016,7 +2016,7 @@ You might also need to use these settings when your function app has network res
 ::: zone pivot="flex-consumption-plan,premium-plan,dedicated-plan" 
 ### Considerations for network restrictions
 
-When you're restricting access to the storage account through the private endpoints, you aren't able to access the storage account through the portal or any device outside the virtual network. You can give access to your secured IP address or virtual network in the storage account by [Managing the default network access rule](../storage/common/storage-network-security.md#change-the-default-network-access-rule).
+When you're restricting access to the storage account through the private endpoints, you aren't able to access the storage account through the portal or any device outside the virtual network. You can give access to your secured IP address or virtual network in the storage account by [Managing the default network access rule](../storage/common/storage-network-security-set-default-access.md).
 ::: zone-end
 ## Function access keys
 

articles/remote-rendering/how-tos/create-an-account.md

@@ -74,7 +74,7 @@ The value for **`arrAccountKey`** can either be primary or secondary key.
 
 This paragraph explains how to link storage accounts to your Remote Rendering account. With a linked account, it isn't necessary anymore to generate a SAS URI every time you want to interact with the data in your account. Instead, you can use the storage account names directly as described in the [loading a model section](../concepts/models.md#loading-models).
 
-Another advantage of this approach is that the storage access level can be limited to private endpoints as described in the [Azure documentation how to configure Storage firewalls and virtual networks](../../storage/common/storage-network-security.md#change-the-default-network-access-rule). Loading from blob storage through a SAS token on the other hand only works if the blob storage has been configured with the "Enabled from all networks" option.
+Another advantage of this approach is that the storage access level can be limited to private endpoints as described in the [Azure documentation how to configure Storage firewalls and virtual networks](../../storage/common/storage-network-security-set-default-access.md). Loading from blob storage through a SAS token on the other hand only works if the blob storage has been configured with the "Enabled from all networks" option.
 
 The steps in this paragraph have to be performed for each storage account that should use this access method. If you haven't created storage accounts yet, you can walk through the respective step in the [convert a model for rendering quickstart](../quickstarts/convert-model.md#storage-account-creation).
 

articles/remote-rendering/resources/troubleshoot.md

@@ -26,7 +26,7 @@ Sometimes during [linking of a storage account](../how-tos/create-an-account.md#
 
 ## Cannot load model through a SAS token
 
-If the client application fails to load a model from storage through a valid SAS-token, it might be caused by the [public network access level](../../storage/common/storage-network-security.md#change-the-default-network-access-rule) configured on the blob storage. Loading an ARR model from SAS token only works if it has been configured with the "Enabled from all networks" option:
+If the client application fails to load a model from storage through a valid SAS-token, it might be caused by the [public network access level](../../storage/common/storage-network-security-set-default-access.md) configured on the blob storage. Loading an ARR model from SAS token only works if it has been configured with the "Enabled from all networks" option:
 ![Screenshot of Azure portal settings for public network access level on blob storage.](./media/portal-blob-access-restrictions.png)
 
 If limiting to private endpoints is a requirement, the [storage account must be linked](../how-tos/create-an-account.md#link-storage-accounts) and the model must be loaded through the non-SAS code path as [described here](../tutorials/unity/security/security.md#securing-your-content-in-azure-blob-storage).

articles/storage/common/storage-network-security.md

@@ -19,31 +19,35 @@ When you disable public network access to your storage account, all incoming req
 > Clients from allowed sources must also meet the authorization requirements of the storage account to access the data. See [Authorization](storage-network-security-overview.md).
 
 <a id="grant-access-from-a-virtual-network"></a>
+<a id="azure-storage-cross-region-service-endpoints"></a>
 
 ## Virtual network subnets
 
-You can enable traffic from specific subnets in one or more virtual networks. These virtual networks can come from any subscription, in any Microsoft Entra tenant and from any Azure region. To enable traffic, you create a *virtual network rule*. Each storage account supports up to **400** virtual network rules. You can combine these rules with [IP network rules](storage-network-security-ip-address-range.md).
+You can enable traffic from specific subnets in one or more virtual networks. These virtual networks can come from any subscription, in any Microsoft Entra tenant and from any Azure region. To enable traffic, you create a *virtual network rule* for each subnet. Each storage account supports up to **400** virtual network rules. You can combine these rules with [IP network rules](storage-network-security-ip-address-range.md).
 
-To enable traffic from a virtual network, you must enable a Virtual Network *service endpoint* for Azure Storage in the virtual network settings. Service endpoints provides secure and direct connectivity to Azure services over an optimized route over the Azure backbone network. These endpoints enable private IP addresses in the virtual network to reach the endpoint of an Azure service without needing a public IP address on the virtual network. The identities of the subnet and the virtual network are also transmitted with each request. To learn more, see [Virtual Network service endpoints](../../virtual-network/virtual-network-service-endpoints-overview.md). 
+To enable traffic from a virtual network, you must enable a Virtual Network *service endpoint* for Azure Storage in the virtual network settings. To learn more about service endpoints, see [Virtual Network service endpoints](../../virtual-network/virtual-network-service-endpoints-overview.md). 
 
-### Azure Storage service endpoint
+The following table describes each type of service endpoint that you can enable for Azure Storage:
 
-The Azure Storage service endpoint *(Microsoft.Storage)* is designed to enable communication between a virtual network and storage accounts that are located in the **same region**.   
+| Service endpoint | Resource name | Description |
+|---|---|--|
+| Azure Storage endpoint | Microsoft.Storage | Allows traffic from a virtual network that is located in the **same region** as the storage account. |
+| Azure Storage cross-region service endpoint | Microsoft.Storage.Global | Allows traffic from a virtual network that is located in **any region**. | 
 
-<a id="azure-storage-cross-region-service-endpoints"></a>
+ To learn how to configure a virtual network rule and enable service endpoints, see [Configure Azure Storage to accept requests from virtual networks](storage-network-security-virtual-networks.md).
 
-### Azure Storage cross-region service endpoint
+Local and cross-region service endpoints can't coexist on the same subnet. To replace existing service endpoints with cross-region ones, delete the existing `Microsoft.Storage` endpoints and re-create them as cross-region endpoints (`Microsoft.Storage.Global`). 
 
-The Azure Storage cross-region service endpoint *(Microsoft.Storage.Global)* is designed to enable communication between a virtual network and storage accounts that are located in the **any region**.
+<a id="grant-access-from-an-internet-ip-range"></a>
+<a id="managing-ip-network-rules"></a>
 
-Configuring service endpoints between virtual networks and service instances in a [paired region](../../best-practices-availability-paired-regions.md) can be an important part of your disaster recovery plan. Service endpoints allow continuity during a regional failover and access to read-only geo-redundant storage (RA-GRS) instances. Network rules that grant access from a virtual network to a storage account also grant access to any RA-GRS instance.
+### Paired regions
 
-When you're planning for disaster recovery during a regional outage, create the virtual networks in the paired region in advance. Enable service endpoints for Azure Storage, with network rules granting access from these alternative virtual networks. Then apply these rules to your geo-redundant storage accounts.
+By default, service endpoints work between virtual networks and service instances in the same Azure region. When using service endpoints with Azure Storage, service endpoints also work between virtual networks and service instances in a [paired region](../../best-practices-availability-paired-regions.md).
 
-Local and cross-region service endpoints can't coexist on the same subnet. To replace existing service endpoints with cross-region ones, delete the existing `Microsoft.Storage` endpoints and re-create them as cross-region endpoints (`Microsoft.Storage.Global`).
+Configuring service endpoints between virtual networks and service instances in a [paired region](../../best-practices-availability-paired-regions.md) can be an important part of your disaster recovery plan. Service endpoints allow continuity during a regional failover and access to read-only geo-redundant storage (RA-GRS) instances. Network rules that grant access from a virtual network to a storage account also grant access to any RA-GRS instance.
 
-<a id="grant-access-from-an-internet-ip-range"></a>
-<a id="managing-ip-network-rules"></a>
+When you're planning for disaster recovery during a regional outage, create the virtual networks in the paired region in advance. Enable service endpoints for Azure Storage, with network rules granting access from these alternative virtual networks. Then apply these rules to your geo-redundant storage accounts.
 
 ## IP address ranges
 

articles/storage/common/storage-private-endpoints.md

@@ -44,7 +44,7 @@ Storage account owners can manage consent requests and the private endpoints thr
 > [!TIP]
 > If you want to restrict access to your storage account through the private endpoint only, configure the storage firewall to deny or control access through the public endpoint.
 
-You can secure your storage account to only accept connections from your VNet by [configuring the storage firewall](storage-network-security.md#change-the-default-network-access-rule) to deny access through its public endpoint by default. You don't need a firewall rule to allow traffic from a VNet that has a private endpoint, since the storage firewall only controls access through the public endpoint. Private endpoints instead rely on the consent flow for granting subnets access to the storage service.
+You can secure your storage account to only accept connections from your VNet by [configuring the storage firewall](storage-network-security-set-default-access.md) to deny access through its public endpoint by default. You don't need a firewall rule to allow traffic from a VNet that has a private endpoint, since the storage firewall only controls access through the public endpoint. Private endpoints instead rely on the consent flow for granting subnets access to the storage service.
 
 > [!NOTE]
 > When copying blobs between storage accounts, your client must have network access to both accounts. So if you choose to use a private link for only one account (either the source or the destination), make sure that your client has network access to the other account. To learn about other ways to configure network access, see [Configure Azure Storage firewalls and virtual networks](storage-network-security.md?toc=/azure/storage/blobs/toc.json).