Merge pull request #199991 from b-ahibbard/anf-standardnetwork

standard network features. general availability

Author: jborsecnik

articles/azure-netapp-files/azure-netapp-files-network-topologies.md

@@ -12,7 +12,7 @@ ms.service: azure-netapp-files
 ms.workload: storage
 ms.tgt_pltfrm: na
 ms.topic: conceptual
-ms.date: 08/08/2022
+ms.date: 08/11/2022
 ms.author: ramakk
 ---
 # Guidelines for Azure NetApp Files network planning
@@ -23,7 +23,7 @@ Azure NetApp Files volumes are designed to be contained in a special purpose sub
 
 ## Configurable network features  
 
- The [**Standard network features**](configure-network-features.md) configuration for Azure NetApp Files is available for public preview. After registering for this feature with your subscription, you can create new volumes choosing *Standard* or *Basic* network features in supported regions. In regions where the Standard network features aren't supported, the volume defaults to using the Basic network features.  
+ Register for the [**configurable network features**](configure-network-features.md) to create volumes with standard network features. You can create new volumes choosing *Standard* or *Basic* network features in supported regions. In regions where the Standard network features aren't supported, the volume defaults to using the Basic network features.  
 
 * ***Standard***  
     Selecting this setting enables higher IP limits and standard VNet features such as [network security groups](../virtual-network/network-security-groups-overview.md) and [user-defined routes](../virtual-network/virtual-networks-udr-overview.md#user-defined) on delegated subnets, and additional connectivity patterns as indicated in this article.
@@ -60,6 +60,9 @@ Azure NetApp Files standard network features are supported for the following reg
 
 You should understand a few considerations when you plan for Azure NetApp Files network.
 
+> [!IMPORTANT]
+> [!INCLUDE [Standard network features pricing](includes/standard-networking-pricing.md)]
+
 ### Constraints
 
 The following table describes what’s supported for each network features configuration:
@@ -76,6 +79,9 @@ The following table describes what’s supported for each network features confi
 |     Load balancers for Azure   NetApp Files traffic    |     No    |     No    |
 |     Dual stack (IPv4 and   IPv6) VNet    |     No <br> (IPv4 only   supported)    |     No <br> (IPv4 only supported)    |
 
+> [!IMPORTANT]
+> Upgrade from basic to standard network feature is not currently supported.
+
 ### Supported network topologies
 
 The following table describes the network topologies supported by each network features configuration of Azure NetApp Files. 
@@ -84,7 +90,7 @@ The following table describes the network topologies supported by each network f
 |---|---|---|
 |     Connectivity to volume in a local VNet    |     Yes    |     Yes    |
 |     Connectivity to volume in a peered VNet (Same region)    |     Yes    |     Yes    |
-|     Connectivity to volume in a peered VNet (Cross region or global peering)    |     No    |     No    |
+|     Connectivity to volume in a peered VNet (Cross region or global peering)    |     Yes*    |     No    |
 |     Connectivity to a volume over ExpressRoute gateway    |     Yes    |     Yes    |
 |     ExpressRoute (ER) FastPath    |     Yes    |     No    |
 |     Connectivity from on-premises to a volume in a spoke VNet   over ExpressRoute gateway and VNet peering with gateway transit    |     Yes    |     Yes    |
@@ -93,7 +99,9 @@ The following table describes the network topologies supported by each network f
 |     Connectivity over Active/Passive VPN gateways    |     Yes    |     Yes    |
 |     Connectivity over Active/Active VPN gateways    |     Yes    |     No    |
 |     Connectivity over Active/Active Zone Redundant gateways    |     No    |     No    |
-|     Connectivity over Virtual WAN (VWAN)    |     No    |     No    |
+|     Connectivity over Virtual WAN (VWAN)    |    No    |     No    |
+
+\* This option will incur a charge on ingress and egress traffic that uses a virtual network peering connection. For more information, see [Virtual Network pricing](https://azure.microsoft.com/pricing/details/virtual-network/). For more general information, see [Virtual network peering](../virtual-network/virtual-network-peering-overview.md). 
 
 ## Virtual network for Azure NetApp Files volumes
 
@@ -107,7 +115,7 @@ Before provisioning an Azure NetApp Files volume, you need to create an Azure vi
 
 Subnets segment the virtual network into separate address spaces that are usable by the Azure resources in them.  Azure NetApp Files volumes are contained in a special-purpose subnet called a [delegated subnet](../virtual-network/virtual-network-manage-subnet.md). 
 
-Subnet delegation gives explicit permissions to the Azure NetApp Files service to create service-specific resources in the subnet.  It uses a unique identifier in deploying the service. In this case, a network interface is created to enable connectivity to Azure NetApp Files.
+Subnet delegation gives explicit permissions to the Azure NetApp Files service to create service-specific resources in the subnet. It uses a unique identifier in deploying the service. In this case, a network interface is created to enable connectivity to Azure NetApp Files.
 
 If you use a new VNet, you can create a subnet and delegate the subnet to Azure NetApp Files by following instructions in [Delegate a subnet to Azure NetApp Files](azure-netapp-files-delegate-subnet.md). You can also delegate an existing empty subnet that's not delegated to other services.
 
@@ -120,37 +128,47 @@ User-defined routes (UDRs) and Network security groups (NSGs) are only supported
 > [!NOTE]
 > Associating NSGs at the network interface level is not supported for the Azure NetApp Files network interfaces. 
 
-If the subnet has a combination of volumes with the Standard and Basic network features (or for existing volumes not registered for the feature preview), UDRs and NSGs applied on the delegated subnets will only apply to the volumes with the Standard network features.
+If the subnet has a combination of volumes with the Standard and Basic network features (or for existing volumes not registered for the feature), UDRs and NSGs applied on the delegated subnets will only apply to the volumes with the Standard network features.
 
 Configuring user-defined routes (UDRs) on the source VM subnets with address prefix of delegated subnet and next hop as NVA isn't supported for volumes with the Basic network features. Such a setting will result in connectivity issues.
 
 ## Azure native environments
 
 The following diagram illustrates an Azure-native environment:
 
-![Azure-native networking environment](../media/azure-netapp-files/azure-netapp-files-network-azure-native-environment.png)
+:::image type="content" source="../media/azure-netapp-files/azure-netapp-files-network-azure-native-environment.png" alt-text="Diagram depicting Azure native environment setup." lightbox="../media/azure-netapp-files/azure-netapp-files-network-azure-native-environment.png":::
 
 ### Local VNet
 
 A basic scenario is to create or connect to an Azure NetApp Files volume from a VM in the same VNet. For VNet 2 in the diagram, Volume 1 is created in a delegated subnet and can be mounted on VM 1 in the default subnet.
 
-### VNet peering
+### <a name="vnet-peering"></a> VNet peering
 
-If you have additional VNets in the same region that need access to each other’s resources, the VNets can be connected using [VNet peering](../virtual-network/virtual-network-peering-overview.md) to enable secure connectivity through the Azure infrastructure. 
+If you have other VNets in the same region that need access to each other’s resources, the VNets can be connected using [VNet peering](../virtual-network/virtual-network-peering-overview.md) to enable secure connectivity through the Azure infrastructure. 
 
 Consider VNet 2 and VNet 3 in the diagram above. If VM 1 needs to connect to VM 2 or Volume 2, or if VM 2 needs to connect to VM 1 or Volume 1, then you need to enable VNet peering between VNet 2 and VNet 3. 
 
-Also, consider a scenario where VNet 1 is peered with VNet 2, and VNet 2 is peered with VNet 3 in the same region. The resources from VNet 1 can connect to resources in VNet 2, but it can't connect to resources in VNet 3 unless VNet 1 and VNet 3 are peered. 
+Also, consider a scenario where VNet 1 is peered with VNet 2, and VNet 2 is peered with VNet 3 in the same region. The resources from VNet 1 can connect to resources in VNet 2 but can't connect to resources in VNet 3 unless VNet 1 and VNet 3 are peered. 
 
 In the diagram above, although VM 3 can connect to Volume 1, VM 4 can't connect to Volume 2.  The reason for this is that the spoke VNets aren't peered, and _transit routing isn't supported over VNet peering_.
 
+### Global or cross-region VNet peering
+
+The following diagram illustrates an Azure-native environment with cross-region VNet peering. 
+
+:::image type="content" source="../media/azure-netapp-files/azure-native-cross-region-peering.png" alt-text="Diagram depicting Azure native environment setup with cross-region VNet peering." lightbox="../media/azure-netapp-files/azure-native-cross-region-peering.png":::
+
+With the standard network feature, VMs are able to connect to volumes in another region via global or cross-region VNet peering. The above diagram adds a second region to the configuration in the [local VNet peering section](#vnet-peering). For VNet 4 in this diagram, an Azure NetApp Files volume is created in a delegated subnet and can be mounted on VM5 in the application subnet.
+
+In the diagram, VM2 in Region 1 can connect to Volume 3 in Region 2. VM5 in Region 2 can connect to Volume 2 in Region 1 via VNet peering between Region 1 and Region 2.
+
 ## Hybrid environments
 
 The following diagram illustrates a hybrid environment: 
 
-![Hybrid networking environment](../media/azure-netapp-files/azure-netapp-files-network-hybrid-environment.png)
+:::image type="content" source="../media/azure-netapp-files/azure-netapp-files-network-hybrid-environment.png" alt-text="Diagram depicting hybrid networking environment." lightbox="../media/azure-netapp-files/azure-netapp-files-network-hybrid-environment.png":::
 
-In the hybrid scenario, applications from on-premises datacenters need access to the resources in Azure.  This is the case whether you want to extend your datacenter to Azure, or you want to use Azure native services or for disaster recovery. See [VPN Gateway planning options](../vpn-gateway/vpn-gateway-about-vpngateways.md?toc=%2fazure%2fvirtual-network%2ftoc.json#planningtable) for information on how to connect multiple resources on-premises to resources in Azure through a site-to-site VPN or an ExpressRoute.
+In the hybrid scenario, applications from on-premises datacenters need access to the resources in Azure. This is the case whether you want to extend your datacenter to Azure or you want to use Azure native services or for disaster recovery. See [VPN Gateway planning options](../vpn-gateway/vpn-gateway-about-vpngateways.md?toc=%2fazure%2fvirtual-network%2ftoc.json#planningtable) for information on how to connect multiple resources on-premises to resources in Azure through a site-to-site VPN or an ExpressRoute.
 
 In a hybrid hub-spoke topology, the hub VNet in Azure acts as a central point of connectivity to your on-premises network. The spokes are VNets peered with the hub, and they can be used to isolate workloads.
 
@@ -163,7 +181,7 @@ In the topology illustrated above, the on-premises network is connected to a hub
 * VM 3 in the hub VNet can connect to Volume 2 in spoke VNet 1 and Volume 3 in spoke VNet 2.
 * VM 4 from spoke VNet 1 and VM 5 from spoke VNet 2 can connect to Volume 1 in the hub VNet.
 * VM 4 in spoke VNet 1 can't connect to Volume 3 in spoke VNet 2. Also, VM 5 in spoke VNet2 can't connect to Volume 2 in spoke VNet 1. This is the case because the spoke VNets aren't peered and _transit routing isn't supported over VNet peering_.
-* In the above architecture if there's a gateway in the spoke VNet as well, the connectivity to the ANF volume from on-prem connecting over the gateway in the Hub will be lost. By design, preference would be given to the gateway in the spoke VNet and so only machines connecting over that gateway can connect to the ANF volume.
+* In the above architecture if there's a gateway in the spoke VNet as well, the connectivity to the ANF volume from on-premises connecting over the gateway in the Hub will be lost. By design, preference would be given to the gateway in the spoke VNet and so only machines connecting over that gateway can connect to the ANF volume.
 
 ## Next steps
 

articles/azure-netapp-files/configure-network-features.md

@@ -12,7 +12,7 @@ ms.service: azure-netapp-files
 ms.workload: storage
 ms.tgt_pltfrm: na
 ms.topic: how-to
-ms.date: 08/03/2021
+ms.date: 08/11/2022
 ms.custom: references_regions
 ms.author: anfdocs
 ---
@@ -22,8 +22,7 @@ The **Network Features** functionality enables you to indicate whether you want
 
 This article helps you understand the options and shows you how to configure network features.
 
->[!IMPORTANT]
->The **Network Features** functionality is currently in public preview. It is not available in Azure Government regions. See [supported regions](azure-netapp-files-network-topologies.md#supported-regions) for a full list. 
+The **Network Features** functionality is not available in Azure Government regions. See [supported regions](azure-netapp-files-network-topologies.md#supported-regions) for a full list. 
 
 ## Options for network features 
 
@@ -53,7 +52,7 @@ Two settings are available for network features:
 
 ## Register the feature 
 
-The network features capability is currently in public preview. If you are using this feature for the first time, you need to register the feature first.
+Follow the registration steps if you're using the feature for the first time.
 
 1.  Register the feature by running the following commands:
 
@@ -90,11 +89,11 @@ This section shows you how to set the Network Features option.
 
     ![Screenshot that shows volume creation for Basic network features.](../media/azure-netapp-files/network-features-create-basic.png)
 
-2. Before completing the volume creation process, you can display the specified network features setting in the **Review + Create** tab of the Create a Volume screen. Click **Create** to complete the volume creation.
+2. Before completing the volume creation process, you can display the specified network features setting in the **Review + Create** tab of the Create a Volume screen. Select **Create** to complete the volume creation.
 
     ![Screenshot that shows the Review and Create tab of volume creation.](../media/azure-netapp-files/network-features-review-create-tab.png)
 
-3. You can click **Volumes** to display the network features setting for each volume:
+3. You can select **Volumes** to display the network features setting for each volume:
 
     [ ![Screenshot that shows the Volumes page displaying the network features setting.](../media/azure-netapp-files/network-features-volume-list.png)](../media/azure-netapp-files/network-features-volume-list.png#lightbox)
 

articles/azure-netapp-files/includes/standard-networking-pricing.md

@@ -0,0 +1,15 @@
+---
+title: include file
+description: include file
+author: b-ahibbard
+ms.service: azure-netapp-files
+ms.topic: include
+ms.date: 08/10/2022
+ms.author: anfdocs
+ms.custom: include file
+
+# azure-netapp-files/whats-new.md
+# azure-netapp-files/azure-netapp-files-network-topologies.md
+---
+
+You can use standard network features without charge for free through September 30, 2022. Regular billing will begin October 1, 2022. Billing will be applicable only for Global peering, which will be billed according to the [Azure pricing guidelines](https://azure.microsoft.com/pricing/details/virtual-network/).