acrolinx

Author: asudbring

articles/virtual-network/vnet-integration-for-azure-services.md

@@ -41,7 +41,7 @@ Deploying a dedicated Azure service into your virtual network provides the follo
 
 - Service instances are deployed into a subnet in a virtual network. Inbound and outbound network access for the subnet must be opened through network security groups, per guidance provided by the service.
 
-- Certain services impose restrictions on the subnet they're deployed in. These restrictions limit the application of policies, routes, or combining VMs and service resources within the same subnet. Check with each service on the specific restrictions as they may change over time. Examples of such services are Azure NetApp Files, Dedicated HSM, Azure Container Instances, App Service.
+- Certain services impose restrictions on the subnet they're deployed in. These restrictions limit the application of policies, routes, or combining VMs and service resources within the same subnet. Check with each service on the specific restrictions as they might change over time. Examples of such services are Azure NetApp Files, Dedicated HSM, Azure Container Instances, App Service.
 
 - Optionally, services might require a delegated subnet as an explicit identifier that a subnet can host a particular service. Azure services have explicit permission to create service-specific resources in the delegated subnet with delegation.
 
@@ -123,7 +123,7 @@ Rather than looking only at their differences, it's worth pointing out that both
 
 Both features are used for more granular control over the firewall on the target service. For example, restricting access to SQL Server databases or storage accounts. The operation is different for both though, as discussed in more detail in the previous sections.
 
-Both approaches overcome the problem of [Source Network Address Translation (SNAT) port exhaustion](../load-balancer/load-balancer-outbound-connections.md#scenarios). You may find exhaustion when you're tunneling traffic through a Network Virtual Appliance (NVA) or service with SNAT port limitations. When you use service endpoints or private endpoints, the traffic takes an optimized path directly to the target service. Both approaches can benefit bandwidth intensive applications since both latency and cost are reduced.
+Both approaches overcome the problem of [Source Network Address Translation (SNAT) port exhaustion](../load-balancer/load-balancer-outbound-connections.md#scenarios). You might find exhaustion when you're tunneling traffic through a Network Virtual Appliance (NVA) or service with SNAT port limitations. When you use service endpoints or private endpoints, the traffic takes an optimized path directly to the target service. Both approaches can benefit bandwidth intensive applications since both latency and cost are reduced.
 
 In both cases, you can still ensure that traffic into the target service passes through a network firewall or NVA. This procedure is different for both approaches. When using service endpoints, you should configure the service endpoint on the **firewall** subnet, rather than the subnet where the source service is deployed. When using private endpoints you put a User Defined Route (UDR) for the private endpoint's IP address on the **source** subnet. Not in the subnet of the private endpoint.
 
@@ -144,7 +144,7 @@ To compare and understand the differences, see the following table.
 | Impacts the cost of your solution                                                                                                                | No                                                                                                                          | Yes (see [Private link pricing](https://azure.microsoft.com/pricing/details/private-link/))                                                                       |
 | Impacts the [composite SLA](/azure/architecture/framework/resiliency/business-metrics#composite-slas) of your solution | No                                                                                                                          | Yes (Private link service itself has a [99.99% SLA](https://azure.microsoft.com/support/legal/sla/private-link/))                                                 |
 | Setup and maintenance | Simple to set up with less management overhead | Extra effort is required |
-| Limits | No limit on the total number of service endpoints in a virtual network. Azure services may enforce limits on the number of subnets used for securing the resource. (see [virtual network FAQ](virtual-networks-faq.md#are-there-any-limits-on-how-many-service-endpoints-i-can-set-up-from-my-virtual-network)) | Yes (see [Private Link limits](../azure-resource-manager/management/azure-subscription-service-limits.md#azure-private-link-limits)) |
+| Limits | No limit on the total number of service endpoints in a virtual network. Azure services might enforce limits on the number of subnets used for securing the resource. (see [virtual network FAQ](virtual-networks-faq.md#are-there-any-limits-on-how-many-service-endpoints-i-can-set-up-from-my-virtual-network)) | Yes (see [Private Link limits](../azure-resource-manager/management/azure-subscription-service-limits.md#azure-private-link-limits)) |
 
 **Azure service resources secured to virtual networks aren't reachable from on-premises networks. If you want to allow traffic from on-premises, allow public (typically, NAT) IP addresses from your on-premises or ExpressRoute. These IP addresses can be added through the IP firewall configuration for the Azure service resources. For more information, see the [virtual network FAQ](virtual-networks-faq.md#can-an-on-premises-devices-ip-address-thats-connected-through-an-azure-virtual-network-gateway-vpn-or-expressroute-gateway-access-azure-paas-services-over-virtual-network-service-endpoints).