Microsoft Azure - Virtual Networks (VNets) Explained
What is a Virtual Network?
A Virtual Network, also known as a VNet is an isolated network within the Microsoft Azure cloud.
VNets are synonymous to AWS VPC (Virtual Private Cloud), providing a range of networking features such as the ability to customize DHCP blocks, DNS, routing, inter-VM connectivity, access control and Virtual Private Networks (VPN).
Azure Portal (ARM) Screenshot ; Shows various networking options
Always Deploy VNet First - You should always build your VNet before you deploy your VM instance. If you do not then Azure will create a default VNet, which may contain an overlapping address range with your onprem network.
Moving VMs between VNets - A VM can be moved from one subnet to another within a VNet. However to move a VM from one VNet to another VNet, you must delete the VM and recreate using the previous VHD.
Azure provides 2 deployment models, Classic (ASM) and ARM.
ARM is the new deployment model that all resources within the Azure Cloud are being transition to. The key point to note is that the configuration, management, and functionality of resources (Compute, Network and Storage), along with portals are different between the 2.
Below outlines the key differences,
|ASM (Azure Service Management)||ARM (Azure Resource Manager)|
|Also known as Classic||Also known as IaaS v2|
|Old deployment model||New deployment model|
|REST based API||REST based API|
|Uses XML data serialization||Uses JSON data serialization|
|Does NOT support Resource Groups||Supports Resource Groups|
What are resource groups ?
A Resource Group is a logical container for a collection of resources, on which monitoring, provisioning and billing can be performed.
Below are the key components within Microsoft Azure Virtual Networks.
A subnet is a range of IP addresses in the VNet, you can divide a VNet into multiple subnets for organization and security. Additionally you can configure VNet routing tables and Network Security Groups (NSG) to a subnet.
There are 2 types of IP addresses that can be assigned to an Azure resource - Public or Private.
- Used for internet/Azure public facing communication.
- A dynamic IP is assigned to the VM, by default. At the point the VM is started /stopped the IP is released/renewed.
- A static IP can be assigned to a VM which is only released when the VM is deleted.
- Used for connectivity within a VNet, and also when using a VPN gateway or ExpressRoute.
- A dynamic IP, by default, is allocated to the VM from the resources subnet via DHCP. At the point the VM is started/stopped the IP may be released/renewed based on the DHCP lease.
- A static IP can be assigned to the VM.
Network Security Groups
Network Security Groups (NSGs) allow you to permit or deny traffic (via a rule base), to either a subnet or a network interface. By default the inbound and outbound rules include an implied deny all. Finally NSGs are stateful, meaning that the TCP sequence numbers are checked in addition to, if the connection is already established.
Azure provides three different load balancing solutions. They are,
- Azure Traffic Manager - Similar to Route53 within AWS, DNS is used to direct traffic to necessary destination. There are 3 destination selection methods - failover, performance or round robin.
- Azure Loadbalancer - Performs L4 loadbalancing within a Virtual Network. Currently only supports round robin distribution.
- Azure Application Gateway - Performs L7 loadbalancing. Supports HTTP Request based loadbalancing, SSL Termination and cookie based persistence.
Although Azure automates the provisioning of system routes, there may be a scenario where you need to further dictate how your traffic is routed.
Routes are applied on traffic leaving a subnet, and traffic can be sent to a next hop of either a virtual network, virtual network gateway or virtual machine.
There will be times when you will need to encrypt your data when sending it over the internet. Or there may be times where you need to send traffic between 2 VNets. This is where Azure VPNs come into play.
There are 2 types of gateways, VPN and Express Route. Further details are shown below,
- VPN - Traffic is encrypted between the endpoints. There are 3 modes,
- Site-to-Site - Traffic is secured using IPSEC/IKE between 2 VPN gateways, for example between Azure and your onprem firewall.
- Point-to-Site - Via a VPN client, a user connects onto Azure, and traffic is encrypted using TLS.
- VNet-to-VNet - Traffic is secured between 2 Virtual Networks using IPSEC/IKE.
- Express Route - This provides a dedicated peered connection into Azure. This is covered in more detail within the Express Route section.
The amount of traffic and/or tunnels that your gateway can support is controlled via a set of 3 SKUs, these SKUs are updated via powershell cmdlets.
There are 2 types of VPN - policy based and route based. Each coming with their own caveats.
Policy Based - Traffic is encrypted/decrypted based upon a policy. This policy contains the IPs and subnets or the endpoints on each side. Policy based VPNs are named 'static routing gateway' within the Classic (ASM) deployment model. However there are some key caveats,
- Supports IKEv1 only.
- Only 1 Site-2-Site VPN can be configured. Multi-point not supported.
- Point-to-Site is not supported.
- VNet-to-VNet VPN is not supported.
Route Based - Traffic is routed via a tunnel interface. This interface then encrypts or decrypts the packets that pass the tunnel. Route based VPNs are named 'dynamic routing gateway' in the Classic deployment model. Additionally they only supports IKEv2.
Microsoft Azure ExpressRoute lets you extend your on-premises networks into the Microsoft cloud over a dedicated private connection facilitated by a connectivity provider. This offers greater bandwidth, improved reliability, and also greater security due to bypassing the internet.
Express Route offers 2 connectivity options:
You connect into Azure via a point-to-point connection, through an Exchange provider who has a direct connection into Azure. With this option you have full control over routing, however is not ideal for multi-point WANs, due to the point-to-point connection requirement.
Network Service Provider
With this option you connect your MPLS WAN into Azure via your Network Service Provider.
Routing is typically managed via your Network Service Provider. However this option does provide multiple-point connectivity (i.e each branch/site) into Azure, unlike point-to-point as this goes via an Exchange Provider.
Further details on the 2 options can be found at http://windowsitpro.com/networking/q-what-are-differences-between-network-services-provider-nsp-and-exchange-provider-exp.