Update sql-database-managed-instance-vnet-configuration.md

Author: srdan-bozovic-msft

articles/sql-database/sql-database-managed-instance-vnet-configuration.md

@@ -38,30 +38,30 @@ For Managed Instance creation you need to dedicate a subnet inside the VNet that
 - **No NSG**: The subnet must not have a Network Security Group associated with it. 
 - **Have specific route table**: The subnet must have a User Route Table (UDR) with 0.0.0.0/0 Next Hop Internet as the only route assigned to it. For more information, see [Create the required route table and associate it](#create-the-required-route-table-and-associate-it)
 3. **Optional custom DNS**: If custom DNS is specified on the VNet, Azure's recursive resolvers IP address (such as 168.63.129.16) must be added to the list. For more information, see [Configuring Custom DNS](sql-database-managed-instance-custom-dns.md).
-4. **No Service endpoints**: The subnet must not have a Service endpoints associated to it. Make sure that Service endpoints option is Disabled when creating VNet.
+4. **No Service endpoints**: The subnet must not have a Service endpoint associated to it. Make sure that Service endpoints option is Disabled when creating VNet.
 5. **Sufficient IP addresses**: The subnet must have the bare minimum of 16 IP addresses (recommended minimum is 32 IP addresses). For more information, see [Determine the size of subnet for Managed Instances](#determine-the-size-of-subnet-for-managed-instances)
 
 > [!IMPORTANT]
 > You won’t be able to deploy new Managed Instance if the destination subnet is not compatible with all of the preceding requirements. The destination Vnet and the subnet must be kept in accordance with these Managed Instance requirements (before and after deployment), as any violation may cause instance to enter faulty state and become unavailable. Recovering from that state requires you to create new instance in a VNet with the compliant networking policies, recreate instance level data, and restore your databases. This introduces significant downtime for your applications.
 
-With introduction of _Network Intent Policy_ we allow you to add Network security group (NSG) on Managed Instance subnet after the Managed Instance is created.
+With introduction of _Network Intent Policy_, you can add a Network security group (NSG) on a Managed Instance subnet after the Managed Instance is created.
 
-You could now use NSG to narrow down the IP ranges from which applications and users could query and manage the data by filtering network traffic that goes to port 1433.
+You can now use an NSG to narrow down the IP ranges from which applications and users can query and manage the data by filtering network traffic that goes to port 1433. 
 
 > [!IMPORTANT]
-> When you are configuring the NSG rules that will restrain access to port 1433 you will also need to insert the highest priority inbound rules displayed in the table below. Otherwise Network Intent Policy will block the change as non compliant.
+> When you are configuring the NSG rules that will restrain access to port 1433, you also need to insert the highest priority inbound rules displayed in the table below. Otherwise Network Intent Policy blocks the change as non compliant.
 
 | NAME       |PORT                        |PROTOCOL|SOURCE           |DESTINATION|ACTION|
 |------------|----------------------------|--------|-----------------|-----------|------|
 |management  |9000, 9003, 1438, 1440, 1452|Any     |Any              |Any        |Allow |
 |mi_subnet   |Any                         |Any     |MI SUBNET        |Any        |Allow |
 |health_probe|Any                         |Any     |AzureLoadBalancer|Any        |Allow |
 
-We also improved routing experiance so in addition to 0.0.0.0/0 next hop type Internet route you could now add UDR to route traffic towards your on-premises private IP ranges through virtual network gateway or virtual network appliance (NVA).
+The routing experiance has also been improved so that in addition to the 0.0.0.0/0 next hop type Internet route, you can now add UDR to route traffic towards your on-premises private IP ranges through virtual network gateway or virtual network appliance (NVA).
 
 ##  Determine the size of subnet for Managed Instances
 
-When you create a Managed Instance, Azure allocates a number of virtual machines depending on the tier you selected during the provisioning. Because these virtual machines are associated with your subnet, they require IP addresses. To ensure high availability during regular operations and service maintenance, Azure may allocate additional virtual machines. As a result, the number of required IP addresses in a subnet is larger than the number of Managed Instances in that subnet. 
+When you create a Managed Instance, Azure allocates a number of virtual machines depending on the tier you selected during provisioning. Because these virtual machines are associated with your subnet, they require IP addresses. To ensure high availability during regular operations and service maintenance, Azure may allocate additional virtual machines. As a result, the number of required IP addresses in a subnet is larger than the number of Managed Instances in that subnet. 
 
 By design, a Managed Instance needs a minimum of 16 IP addresses in a subnet and may use up to 256 IP addresses. As a result, you can use subnet masks /28 to /24 when defining your subnet IP ranges. 
 
@@ -77,7 +77,7 @@ If you plan to deploy multiple Managed Instances inside the subnet and need to o
 **Example**: You plan to have three General Purpose and two Business Critical Managed Instances. That means you need 5 + 3 * 2 + 2 * 4 = 19 IP addresses. As IP ranges are defined in power of 2, you need the IP range of 32 (2^5) IP addresses. Therefore, you need to reserve the subnet with subnet mask of /27. 
 
 > [!IMPORTANT]
-> Calculation displayed above will become obsolete with further improvements and for ease of use replaced with the online Managed Instance subnet size estimator. 
+> Calculation displayed above will become obsolete with further improvements. 
 
 ## Create a new virtual network for Managed Instance using Azure Resource Manager deployment
 
@@ -116,7 +116,7 @@ If you would like to create new one:
 - Follow the steps in [Add, change, or delete a virtual network subnet](../virtual-network/virtual-network-manage-subnet.md). 
 - Create a route table that contains single entry, **0.0.0.0/0**, as the next hop Internet and associate it with the subnet for the Managed Instance.  
 
-In case you would like to create a Managed Instance inside an existing subnet we recommend you to use the PowerShell script below to prepare the subnet.
+If you want to create a Managed Instance inside an existing subnet, we recommend the following PowerShell script to prepare the subnet.
 ```powershell
 $scriptUrlBase = 'https://raw.githubusercontent.com/Microsoft/sql-server-samples/master/samples/manage/azure-sql-db-managed-instance/prepare-subnet'