We are excited to announce that Azure SQL Database and Azure SQL Data Warehouse VNET Service Endpoints are now in public preview in the following regions: West Central US, West US2, and East US1.
This feature allows you to isolate connectivity to your SQLDB to only a given Subnet or set of Subnets within your VNET(s). Even though the connectivity will be on Azure SQL Databases public endpoint, the traffic will stay within the Azure backbone network. This direct route will be preferred over any forced-tunneling route to take Internet traffic back to on-premises. We also provide for separation of roles with the ability to provision VNET Service Endpoints either on the Network Admin, the Database Admin, splitting the roles between these two, or the ability to create a new entity with the help of custom RBAC roles. The following diagram gives more information on the architecture:
Limitations
Each SQL Server can have up to 128 Virtual Network based ACLs
Applies only to ARM VNETs
This does not extend to on-premises via Expressroute, Site-to-Site (S2S) VPN, or Peered VNets.
Considerations
At the time of this preview, Network Security Groups (NSGs) should be opened to the Internet to allow Azure SQL Database traffic. In future, NSGs could be opened to only IP ranges for the PaaS services. IP tags for Azure SQL Database are on the roadmap for CY17.
With VNET Service Endpoints, source IP addresses of resources in your VNet's subnet will switch from using public IPV4 addresses to VNet's private addresses, for traffic to Azure SQL Database. Any existing open TCP connections to your databases service may be closed during this switch. Please make sure no critical tasks are run when Service Endpoints is turned on or off.
If traffic to Azure SQL Database is to be inspected by a network virtual appliance (NVA), it is recommended that VNET Service Endpoints is turned on for the NVA subnet, instead of the subnet where the Azure SQL Database is originating from in the given VNET.
When Service Endpoints is turned on, a Subnet it is sequentially applied to all VMs in that Subnet. The call commits only when Service Endpoints is successfully applied to all VMs. You will be able to ACL given VNET/Subnet your Server only after Service Endpoints from the VNET/Subnet is successfully applied. So there can be potential downtime after the Service Endpoints call is issued until when you ACL the Server.
To learn more check out VNet Service Endpoints and rules for Azure SQL Database.
Quelle: Azure
Published by