It’s been a while since my last blog post, but the beauty of time marching forwards is that lovely new features get released in Azure for me to write about.
Something I always remember as a kid is that when we got a cool new bit of technology, I'd use it for a while and then my next port of call would be “this is awesome, but how does this actually work?” So, when Azure service endpoints were released for Azure SQL and Azure Storage accounts, this was a great new feature that I immediately started playing about with. I doubt this is just me and I believe I speak for many people working in engineering fields today.
In case you’re not aware, service endpoints allow us to connect certain platform services into our virtual networks. This means that our Azure virtual machines can interact with Azure SQL and Azure Storage accounts as if they’re part of the same virtual network, rather than our Azure virtual machines accessing them over the public endpoint – very neat! However, after a while, that question from my childhood came about, helped by a lively debate about it with my colleagues – how does this actually work?
When enabling the service endpoint, you can do this in two ways. The first way is to
- Enable the service endpoint of your choosing under the virtual network and specify the subnet.
- Once completed you can then visit the platform service, for example the Azure SQL Server, and under firewalls and virtual networks add the virtual network and subnet that we just configured.
Alternatively, we can now perform the latter step even if we haven’t enabled the service endpoint; the blade will let us enable it at the same time.
Now here is where the interesting part happens. Using an existing Azure virtual machine NIC on the subnet where we’d like our service endpoints to be enabled, we can use a troubleshooting tool known as “effective routes” to see what's going on.
Effective routes show us what networking routes this particular virtual machine will know about, so I took a screenshot before enabling the service endpoint for SQL as well as after.
On comparison I have a new route added (highlighted) that has been inherited from the subnet. This new route includes the entire public IP range for the Azure SQL Server service and instructs traffic that in order to get to anything within these ranges, it should go via a “virtual network service endpoint”. This will be an ingress into the Azure fabric which will forward the traffic to our Azure SQL instance rather than going out and via the public endpoint as it would have done before.
Now it’s important to state that using service endpoints does not remove the public endpoint from Azure SQL or Azure Storage accounts – it’s just a redirection of traffic. So, while we have traffic over the new virtual network service endpoint for a particular subnet, anything outside of that subnet will still access the Azure SQL Server, SQLDBs or Storage account over the public endpoint(s); so we need to have our Azure Storage and Azure SQL firewalls white/black listed appropriately.
Now if only my curiosity had stopped there as a kid I may not have bricked our Windows 95 machine. Sorry Dad!
