There were several updates announced at Ignite recently. One of them is Virtual Network Service Endpoints. Today most of the Azure services including Azure storage and Azure SQL have public IPs. These public IPs are configured for internet traffic from on-premises firewalls or if you are using NSGs, or advanced firewalls and virtual networks, all of these firewalls have to be opened to internet outbound to talk to Azure services. Anyone would be able to connect to these services over a public IP address and secure access either using a firewall or a security token. A lot of customers are not happy using a public facing service as this can be a huge compliance and security issue as well as the attack vectors these services have. Since the IPs are public and accessible from everywhere, it poses a challenge for customers where your own administrators can go to any public internet location and access these Azure resources. Private connectivity to services is critical for workloads to be moved to Azure. The resources should be available only to the private environment and not accessible from the internet. Since there isn’t a way to pull the Azure storage into your VNet, Microsoft introduced a concept called Virtual Network Service Endpoints. This is a route that is setup on the Virtual Network that extends the address space and allows you to connect your VNet address space to Azure services. You can also restrict access to the services to be from your VNet only. This allows you to secure access to Azure resources from your VNet only. The service currently supports Azure Storage & Azure SQL with more services coming in the near future. Although the service remains multi-tenant, your resources on your VNet, for anyone accessing it from any other network, is denied access to the locked resources. VNet-to-Service traffic always stays on the Microsoft network backbone. A detailed representation is as shown below: Azure Virtual Network Service Endpoints (Preview) feature, right now, is available only in these regions: Azure Storage: WestUS2, WestCentralUS, EastUS, WestUS, AustraliaEast, and AustraliaSouthEast Azure SQL Database: WestCentralUS, WestUS2, and EastUS. Good news is this feature is free and there is no additional charge for using service endpoints. The current pricing model for Azure services (Azure Storage, Azure SQL Database) applies as-is today. Access from On-premises If you are accessing resources from on-premises, you will have to use NAT IPs and if you’re coming over an ExpressRoute circuit, you will come over the ExpressRoutee Public peering and all the NAP IPs. Storage now has IP firewalls as well. So, you can allow virtual networks and IP firewalls. Similarly, for SQL, it’s always had firewalls and you’ll continue using that in conjunction with virtual network traffic. In general, Service Endpoints work between Virtual Networks and service instances in the same Azure region. When Service Endpoints are used with Azure Storage, this scope is expanded to include the paired region. This allows continuity during a regional failover as well as seamless access to read-only geo-reduntant storage (RA-GRS) instances. When planning for disaster recovery during a regional outage, you should provision the Virtual Networks in the paired region in advance. Service Endpoints for Azure Storage should be enabled, and network rules granting access from these alternative Virtual Networks should be applied to your geo-redundant storage accounts.