To start this article, we need to go back in time, to the beginning of Azure in 2009. During its first year(s), the primary or almost only focus was on Platform-as-a-Service (PaaS), applications built for the internet. This concept also applied to core services, which are still heavily used today, like Storage, Databases, etc. which had to be available with a public endpoint.
Over time, things have improved strategy has changed, and in the meantime, many customers have extended their datacenter to Azure – Infrastructure-as-a-Service (IaaS) has become a foundational requirement. In the case of IaaS, those above-mentioned core services are only used for internal applications. This means the endpoints don’t have to be exposed to the internet anymore. However, they still are… During //build 2017, Microsoft announced the possibility to lockdown those internal used core services and introduced the concept of “Virtual Network Service Endpoints”.
Virtual Netwok Service Endpoint
The Virtual Network Service Endpoints comes in very handy, as it allows to isolate connectivity to a resource from a defined subnet with the virtual network. Service Endpoints provide the following top three benefits:
- Improved Security: By entirely removing public internet access for the resources, only traffic from selected Virtual Networks will be allowed;
- Optimal Routing: The network traffic will always be routed/connected through the Azure backbone network and never leave such.
- Simple Setup: No additional overhead to maintaining the endpoints, no NAT, or reserved Public IP. A simple configuration in the Azure Portal.
As always, there are also some limitations to be aware of. This feature supports only Virtual Networks deployed through ARM – this shouldn’t be the biggest blocker. However, the resource, for example, the Storage Account, will keep its Public IP. Even the traffic will always stay within the Azure Backbone network. This can be confusing…
This feature is available for the following Azure Services and Regions (as of August 2018, some are still in public preview). There is no additional charge for using Service Endpoints:
- Azure Storage
- Azure SQL Database
- Azure Cosmos DB
- Azure SQL Data Warehouse
- Azure Service Bus
- Azure Event Hubs
- Azure Key Vault
- Azure Database for PostgreSQL server
- Azure Database for MySQL server
The capability is expanding to other services and regions on. You can see the progress on the public Azure Roadmap for “Virtual Network”. A Microsoft colleague of mine, Riccardo Pomato, wrote an article about the setup you might want to follow. You can also find further information about this feature in the Azure Docs.
More Security Using Azure Firewall
You may have heard of Azure Firewall (currently in preview), a cloud-based network security service that protects Virtual Network resources. This service works across subscriptions and virtual networks, which “simplifies” the management for a more extensive deployment.
Azure Firewall allows to centrally create allow or deny network filtering rules by source and destination IP address, port, and protocol. Azure Firewall is fully stateful so that it can distinguish legitimate packets for different types of connections. Rules are enforced and logged across multiple subscriptions and virtual networks. You might want to give a try as soon as the service is available publicly.
There’s Just one More Thing…
Service Endpoints are configured very quickly. However, you have to be aware that network rules Network Rules are enforced on all network protocols, including REST and SMB. Tools like the AZCopy, Storage Explorer or even the Azure Portal require explicit access when network rules are enforced.
If you get an access denied message, you have to add your management/client IP Address to the firewall to gain access again.
