All that was, and ever will be starts with the network. After all, without networking, servers wouldn't serve, and just be lonely boxes (physical or virtual) sitting in a datacenter. Humming away in the night, with nobody to consume the services they so ambitiously provide...
Azure features virtual networks (as is expected), called ‘Azure Virtual Network’ or ‘VNet’. These are fundamental building blocks and enable Azure resources to securily communicate with each other, the internet, and the on-premises networks.
With everything in a cloud provider, VNet brings scale, availability, and isolation. Not so different from a well managed datacenter then! Our little servers need not worry, they shall be heard!
Starting our journey in to the deep reaches of Azure, there are a lot of concepts that will need to be named and defined. When it comes to Azure Networking, we’re going to start with these:
Address space: Just like in a on-premises network, VNets need to be assigned an IP address space. Each resource in a VNet is going to be assigned a private IP address from this address space, so don’t work with overlapping address spaces. Unless you want headaches later on!
Subnets: Again, this isn’t any different from the on-premises world. Subnets allow for segmenting VNets in to one or more sub-networks. That gives you the ability to deploy resources in to specific subnets.
Regions: VNets are scoped to a single region or location. But it is possible to connect multiple VNets togethet using Virtual Network Peering.
Subscription: Hey! This is a paying service after all! VNets belong to a subscription… They are not accessible outside of this subscription unless you do funkey stuff.
Don’t worry, I’m going to make a page with concepts that’ll get updated as I go along. Nothing quite as annoying as seeing a word and having no clue what it means (happens a lot to me…)
‘This is Jimmy’
All resources in a VNet can communicate outbound with the internet by default. Incoming communication is also possible, but you’ll have to assign a public ip address to the resource or use other services that allow this communication, such as load balancers.
Azure resources chat each other up in a secure and stylish fashion. Through virtual networks, Virtual network Service endpoints, or VNet peering.
It is also possible to connect on-premises computers and networks to VNets by Point-to-site VPN, Site-to-Site VPN, or Azure ExpressRoute.
I’ve never quite grown in to the Senseo rage, so filters are still deeply asociated with coffee filters in my mind. When it comes to Azure, Network traffic can be filtered by using Security groups or Network virtual appliances.
Without routing, networks aren’t going to be able to communicate with each others. Azure will route traffic between subnets, connected virtual networks, on-premises networks and the internet by default.
It is possible to implement Route tables or BGP routes to override the default behavior.
As with everything, there are some limitations when it comes to how many of things you can have. You can only have 1 000 VNets, 3 000 subnets per VNet, and 500 000 concurrent TCP or UDP flows per NIC of a virtual machine or role instance. Typically the limitations that exist are not going to be an issue, but just to be certain, check this page to ensure you’re not going to hit some weird issue in your design: