acrofix

Author: Ankita Dutta

articles/site-recovery/azure-to-azure-about-networking.md

@@ -8,21 +8,21 @@ ms.date: 09/11/2024
 ms.author: ankitadutta
 ms.custom: engagement-fy23
 ---
-# About networking in Azure VM disaster recovery
+# About networking in Azure virtual machine disaster recovery
 
 
 
-This article provides networking guidance for platform connectivity when you're replicating Azure VMs from one region to another, using [Azure Site Recovery](site-recovery-overview.md).
+This article provides networking guidance for platform connectivity when you're replicating Azure virtual machines from one region to another, using [Azure Site Recovery](site-recovery-overview.md).
 
 ## Before you start
 
 Learn how Site Recovery provides disaster recovery for [this scenario](azure-to-azure-architecture.md).
 
 ## Typical network infrastructure
 
-The following diagram depicts a typical Azure environment, for applications running on Azure VMs:
+The following diagram depicts a typical Azure environment, for applications running on Azure virtual machines:
 
-![Diagram that depicts a typical Azure environment for applications running on Azure VMs.](./media/site-recovery-azure-to-azure-architecture/source-environment.png)
+![Diagram that depicts a typical Azure environment for applications running on Azure virtual machines.](./media/site-recovery-azure-to-azure-architecture/source-environment.png)
 
 If you're using Azure ExpressRoute or a VPN connection from your on-premises network to Azure, the environment is as follows:
 
@@ -43,24 +43,24 @@ If you're using a URL-based firewall proxy to control outbound connectivity, all
 
 **URL** | **Details**
 --- | ---
-*.blob.core.windows.net | Required so that data can be written to the cache storage account in the source region from the VM. If you know all the cache storage accounts for your VMs, you can allow access to the specific storage account URLs (Ex: cache1.blob.core.windows.net and cache2.blob.core.windows.net) instead of *.blob.core.windows.net
+*.blob.core.windows.net | Required so that data can be written to the cache storage account in the source region from the virtual machine. If you know all the cache storage accounts for your virtual machines, you can allow access to the specific storage account URLs (Ex: cache1.blob.core.windows.net and cache2.blob.core.windows.net) instead of *.blob.core.windows.net
 login.microsoftonline.com | Required for authorization and authentication to the Site Recovery service URLs.
-*.hypervrecoverymanager.windowsazure.com | Required so that the Site Recovery service communication can occur from the VM.
-*.servicebus.windows.net | Required so that the Site Recovery monitoring and diagnostics data can be written from the VM.
+*.hypervrecoverymanager.windowsazure.com | Required so that the Site Recovery service communication can occur from the virtual machine.
+*.servicebus.windows.net | Required so that the Site Recovery monitoring and diagnostics data can be written from the virtual machine.
 *.vault.azure.net | Allows access to enable replication for ADE-enabled virtual machines via portal
 *.automation.ext.azure.com | Allows enabling autoupgrade of mobility agent for a replicated item via portal
 
 ## Outbound connectivity using Service Tags
 
 Apart from controlling URLs, you can also use service tags to control connectivity. To do so, you must first create a [Network Security Group](../virtual-network/network-security-group-how-it-works.md) in Azure. Once created, you need to use our existing service tags and create an NSG rule to allow access to Azure Site Recovery services. 
 
-The advantages of using service tags to control connectivity, when compared to controlling connectivity using IP addresses, is that there is no hard dependency on a particular IP address to stay connected to our services. In such a scenario, if the IP address of one of our services changes, then the ongoing replication is not impacted for your machines. Whereas, a dependency on hard coded IP addresses causes the replication status to become critical and put your systems at risk. Moreover, service tags ensure better security, stability and resiliency than hard coded IP addresses.
+The advantages of using service tags to control connectivity, when compared to controlling connectivity using IP addresses, is that there's no hard dependency on a particular IP address to stay connected to our services. In such a scenario, if the IP address of one of our services changes, then the ongoing replication isn't impacted for your machines. Whereas, a dependency on hard coded IP addresses causes the replication status to become critical and put your systems at risk. Moreover, service tags ensure better security, stability and resiliency than hard coded IP addresses.
 
 While using NSG to control outbound connectivity, these service tags need to be allowed.
 
 - For the storage accounts in source region:
     - Create a [Storage service tag](../virtual-network/network-security-groups-overview.md#service-tags) based NSG rule for the source region.
-    - Allow these addresses so that data can be written to the cache storage account, from the VM.
+    - Allow these addresses so that data can be written to the cache storage account, from the virtual machine.
 - Create a [Microsoft Entra service tag](../virtual-network/network-security-groups-overview.md#service-tags) based NSG rule for allowing access to all IP addresses corresponding to Microsoft Entra ID
 - Create an EventsHub service tag-based NSG rule for the target region, allowing access to Site Recovery monitoring.
 - Create an Azure Site Recovery service tag-based NSG rule for allowing access to Site Recovery service in any region.
@@ -70,10 +70,10 @@ While using NSG to control outbound connectivity, these service tags need to be
 
 ## Example NSG configuration
 
-This example shows how to configure NSG rules for a VM to replicate.
+This example shows how to configure NSG rules for a virtual machine to replicate.
 
 - If you're using NSG rules to control outbound connectivity, use "Allow HTTPS outbound" rules to port:443 for all the required IP address ranges.
-- The example presumes that the VM source location is "East US" and the target location is "Central US".
+- The example presumes that the virtual machine source location is "East US" and the target location is "Central US".
 
 ### NSG rules - East US
 
@@ -103,18 +103,18 @@ These rules are required so that replication can be enabled from the target regi
 
 ## Network virtual appliance configuration
 
-If you're using network virtual appliances (NVAs) to control outbound network traffic from VMs, the appliance might get throttled if all the replication traffic passes through the NVA. We recommend creating a network service endpoint in your virtual network for "Storage" so that the replication traffic doesn't go to the NVA.
+If you're using network virtual appliances (NVAs) to control outbound network traffic from virtual machines, the appliance might get throttled if all the replication traffic passes through the NVA. We recommend creating a network service endpoint in your virtual network for "Storage" so that the replication traffic doesn't go to the NVA.
 
 ### Create network service endpoint for Storage
 
 You can create a network service endpoint in your virtual network for "Storage" so that the replication traffic doesn't leave Azure boundary.
 
-- Select your Azure virtual network and click on 'Service endpoints'
+- Select your Azure virtual network and select **Service endpoints**.
 
     ![storage-endpoint](./media/azure-to-azure-about-networking/storage-service-endpoint.png)
 
-- Click 'Add' and 'Add service endpoints' tab opens
-- Select 'Microsoft.Storage' under 'Service' and the required subnets under 'Subnets' field and click 'Add'
+- Select **Add** and **Add service endpoints** tab opens.
+- Select *Microsoft.Storage* under **Service** and the required subnets under 'Subnets' field and select **Add**.
 
 >[!NOTE]
 >If you're using firewall enabled cache storage account or target storage account, ensure you ['Allow trusted Microsoft services'](../storage/common/storage-network-security.md). Also, ensure that you allow access to at least one subnet of source Vnet.

articles/site-recovery/azure-to-azure-network-mapping.md

@@ -1,6 +1,6 @@
 ---
 title: Map virtual networks between two regions in Azure Site Recovery
-description: Learn about mapping virtual networks between two Azure regions for Azure VM disaster recovery with Azure Site Recovery.
+description: Learn about mapping virtual networks between two Azure regions for Azure virtual machine disaster recovery with Azure Site Recovery.
 author: ankitaduttaMSFT
 ms.service: azure-site-recovery
 ms.topic: how-to
@@ -28,74 +28,74 @@ Map networks as follows:
 
     :::image type="content" source="./media/site-recovery-network-mapping-azure-to-azure/network-mapping1.png" alt-text="Screenshot of Create a network mapping." lightbox="./media/site-recovery-network-mapping-azure-to-azure/network-mapping1.png":::
 
-3. In **Add network mapping**, select the source and target locations. In our example, the source VM is running in the East Asia region, and replicates to the Southeast Asia region.
+3. In **Add network mapping**, select the source and target locations. In our example, the source virtual machine is running in the East Asia region, and replicates to the Southeast Asia region.
 
     :::image type="content" source="./media/site-recovery-network-mapping-azure-to-azure/network-mapping2.png" alt-text="Screenshot of Select source and target." lightbox="./media/site-recovery-network-mapping-azure-to-azure/network-mapping2.png":::
-3. Now create a network mapping in the opposite direction. In our example, the source will now be Southeast Asia, and the target will be East Asia.
+3. Now create a network mapping in the opposite direction. In our example, the source is now Southeast Asia, and the target is East Asia.
 
     :::image type="content" source="./media/site-recovery-network-mapping-azure-to-azure/network-mapping3.png" alt-text="Screenshot of Add network mapping pane - Select source and target locations for the target network." lightbox="./media/site-recovery-network-mapping-azure-to-azure/network-mapping3.png":::
 
 
 ## Map networks when you enable replication
 
-If you haven't prepared network mapping before you configure disaster recovery for Azure VMs, you can specify a target network when you [set up and enable replication](azure-to-azure-how-to-enable-replication.md). When you do this the following happens:
+If you haven't prepared network mapping before you configure disaster recovery for Azure virtual machines, you can specify a target network when you [set up and enable replication](azure-to-azure-how-to-enable-replication.md). When you do this, the following happens:
 
 - Based on the target you select, Site Recovery automatically creates network mappings from the source to target region, and from the target to source region.
 - By default, Site Recovery creates a network in the target region that's identical to the source network. Site Recovery adds **-asr** as a suffix to the name of the target network. You can customize the target network. For example, if the source network name was *contoso-vnet*, then the target network is named *contoso-vnet-asr*.
 
-So, if the source network name was "contoso-vnet", then the target network name will be "contoso-vnet-asr". Source network's name will not be edited by ASR.
-- If network mapping has already occurred for a source network, the mapped target network will always be the default at the time of enabling replications for more VMs. You can choose to change the target virtual network by choosing other available options from the dropdown.
+So, if the source network name was "contoso-vnet", then the target network name is `contoso-vnet-asr`. Source network's name won't be edited by Azure Site Recovery.
+- If network mapping has already occurred for a source network, the mapped target network is always the default at the time of enabling replications for more virtual machines. You can choose to change the target virtual network by choosing other available options from the dropdown.
 - To change the default target virtual network for new replications, you need to modify the existing network mapping.
 - If you wish to modify a network mapping from region A to region B, ensure that you first delete the network mapping from region B to region A. After reverse mapping deletion, modify the network mapping from region A to region B and then create the relevant reverse mapping.
 
 >[!NOTE]
->* Modifying the network mapping only changes the defaults for new VM replications. It does not impact the target virtual network selections for existing replications.
+>* Modifying the network mapping only changes the defaults for new virtual machine replications. It does not impact the target virtual network selections for existing replications.
 >* If you wish to modify the target network for an existing replication, go to **Network** Settings of the replicated item.
 
 ## Specify a subnet
 
-The subnet of the target VM is selected based on the name of the subnet of the source VM.
+The subnet of the target virtual machine is selected based on the name of the subnet of the source virtual machine.
 
-- If a subnet with the same name as the source VM subnet is available in the target network, that subnet is set for the target VM.
+- If a subnet with the same name as the source virtual machine subnet is available in the target network, that subnet is set for the target virtual machine.
 - If a subnet with the same name doesn't exist in the target network, the first subnet in the alphabetical order is set as the target subnet.
-- You can modify the target subnet in the **Network** settings for the VM.
+- You can modify the target subnet in the **Network** settings for the virtual machine.
 
     :::image type="content" source="./media/site-recovery-network-mapping-azure-to-azure/modify-subnet.png" alt-text="Screenshot of Network compute properties window." lightbox="./media/site-recovery-network-mapping-azure-to-azure/modify-subnet.png":::
 
-## Set up IP addressing for target VMs
+## Set up IP addressing for target virtual machines
 
 The IP address for each NIC on a target virtual machine is configured as follows:
 
-- **DHCP**: If the NIC of the source VM uses DHCP, the NIC of the target VM is also set to use DHCP.
-- **Static IP address**: If the NIC of the source VM uses static IP addressing, the target VM NIC will also use a static IP address.
+- **DHCP**: If the NIC of the source virtual machine uses DHCP, the NIC of the target virtual machine is also set to use DHCP.
+- **Static IP address**: If the NIC of the source virtual machine uses static IP addressing, the target virtual machine NIC is also use a static IP address.
 
 The same holds for the Secondary IP Configurations as well.
 
 ## IP address assignment during failover
 
 >[!Note]
->The following approach is used to assign IP address to the target VM, irrespective of the NIC settings.
+>The following approach is used to assign IP address to the target virtual machine, irrespective of the NIC settings.
 
 **Source and target subnets** | **Details**
 --- | ---
-Same address space | IP address of the source VM NIC is set as the target VM NIC IP address.<br/><br/> If the address isn't available, the next available IP address is set as the target.
-Different address space | The next available IP address in the target subnet is set as the target VM NIC address.
+Same address space | IP address of the source virtual machine NIC is set as the target virtual machine NIC IP address.<br/><br/> If the address isn't available, the next available IP address is set as the target.
+Different address space | The next available IP address in the target subnet is set as the target virtual machine NIC address.
 
 
 
 ## IP address assignment during test failover
 
 **Target network** | **Details**
 --- | ---
-Target network is the failover VNet | - Target IP address will be static with the same IP address. <br/><br/>  - If the same IP address is already assigned, then the IP address is the next one available at the end of the subnet range. For example: If the source IP address is 10.0.0.19 and failover network uses range 10.0.0.0/24, then the next IP address assigned to the target VM is 10.0.0.254.
-Target network isn't the failover VNet | - Target IP address will be static with the same IP address, only if it is available in the target virtual network. <br/><br/>  - If the same IP address is already assigned, then the IP address is the next one available at the end of the subnet range.<br/><br/> For example: If the source static IP address is 10.0.0.19 and failover is on a network that isn't the failover network, with the range 10.0.0.0/24, then the target static IP address will be 10.0.0.19 if available, and otherwise it will be 10.0.0.254.
+Target network is the failover VNet | - Target IP address is static with the same IP address. <br/><br/>  - If the same IP address is already assigned, then the IP address is the next one available at the end of the subnet range. For example: If the source IP address is `10.0.0.19` and failover network uses range `10.0.0.0/24`, then the next IP address assigned to the target virtual machine is `10.0.0.254`.
+Target network isn't the failover VNet | - Target IP address is static with the same IP address, only if it's available in the target virtual network. <br/><br/>  - If the same IP address is already assigned, then the IP address is the next one available at the end of the subnet range.<br/><br/> For example: If the source static IP address is `10.0.0.19` and failover is on a network that isn't the failover network, with the range `10.0.0.0/24`, then the target static IP address is `10.0.0.19` if available. Otherwise it is `10.0.0.254`.
 
 - The failover VNet is the target network that you select when you set up disaster recovery.
-- We recommend that you always use a non-production network for test failover.
-- You can modify the target IP address in the **Network** settings of the VM.
+- We recommend that you always use a nonproduction network for test failover.
+- You can modify the target IP address in the **Network** settings of the virtual machine.
 
 
 ## Next steps
 
-- Review [networking guidance](./azure-to-azure-about-networking.md) for Azure VM disaster recovery.
+- Review [networking guidance](./azure-to-azure-about-networking.md) for Azure virtual machine disaster recovery.
 - [Learn more](site-recovery-retain-ip-azure-vm-failover.md) about retaining IP addresses after failover.