Networks are one of the most simple and robust ways of achieving security in a distributed system. A web application can talk to a database on another server and using networks, I can restrict access to the database only to the web server and perhaps my desktop machine, I can also setup routes generally which mean that no other machine could even route to the database server, even if they were on the same physical network.

On the cloud of course, we don't have loads of techies running around and plugging things into different sockets for us, we achieve the same effect in software - a virtual network. For the most part, these serve the same purpose: configure IP addresses; setup routes; configure gateways and firewalls etc.

In short, they are a must-have for secure companies.

BUT

If you use these on the Azure cloud, currently, you are severely limited as to what services have complete compatibility with virtual networks. Obviously the expensive services are, like app service environments, but many of us do not use these for our current workloads or cashflow and using them with app services is only partially supported. That is the same for redis, which only supports vnets on the Premium platform (> £300/month). Surprisngly, it also supports Cloud Services, a relic of the olden days, which were a very thin layer over a VM and are generally considered a poor alternative to both App Services and also Virtual Machine Sets.

I decided to see whether I could get a PixelPin deployment running on VNets so that only the app service had public access and all the backend services were only on the private network. I was going to worry about operations access later. This is what I found:


  1. Setting up virtual networks is not particularly straight-forward until you understand the various elements, which you might understand in theory but not how they relate to Azure services. For example, you can create a Virtual Network and this will also create you a default subnet of IP addresses (which you can't rename afterwards) but it doesn't create or ask about a gateway when creating it, which means it cannot be accessed from outside
  2. I found out that I needed expensive Redis platforms, in order to work with vnets (I created one anyway, just to carry on, even though I wouldn't have paid that every month)
  3. I discovered something called Service endpoints, which appear to be a half-hearted, or maybe stop-gap solution for connecting services that do NOT support vnet natively into your vnet. I needed these for both CosmosDB and also for SQL Azure and storage (storage!). These allow some of the security of the vnet i.e. you cannot connect to the service except from the subnet (good) but they do not see the vnets ip addresses, so firewalling them requires you to "allow connections from all Azure service", which is crap!
  4. I then tried to connect my App Services web app to the network. First lesson was that you needed to use the Standard tier, which is OK, except that when testing these things, it is nice to use cheap or free tiers since you don't need performance, you only want to wire it up. That was fine for production though since we already use the standard tier. I then also found out that you can only connect it to one vnet, which was probably OK in a simple case but still a shame you can't add arbitrary cards to the app services machine (even if there was a limit of, say, 3 or 4).
Basically, none of it was great. I can't remember what made me finally give up but there were too many limitations currently.

On Amazon, everything can go into a virtual network, if I understand ti correctly, but of course, they are not an MS house and do not support Windows or DotNet anywhere near as well as Azure do.

Most of these comparisons are 6 of one and half-a-dozen of the other but the danger here is that people might just decide to leave MS and head to AWS because the network segregation if more important than the extra work require to deploy dotnet to AWS so MS need to sort this out with urgency and make it all work much more consistently. Also, instead of forcing people into expensive tiers to try these things, they should instead impose other restrictions to allow people who can afford it and need the performance to pay big money and those of us testing things out not having to.

Let's hope they do it soon!