What is a VNet?

A Virtual Network, or a VNet, is an isolated network within the Microsoft Azure cloud. A VNet in Azure provides a range of networking functions comparable to AWS Virtual Private Cloud (VPC). These functions include DNS, routing, enabling customization of DHCP blocks, access control, connectivity between virtual machines (VM) and virtual private networks (VPN).

An Azure VNet is a representation of a network in the cloud and is logical isolation of the Azure cloud dedicated to a subscription. In the background, it's a software abstraction of a network that overlays Azure’s infrastructure to provide isolation from resources outside of the VNet, practically making it a private network.

Operationally, a VNet follows common IP routing principles to connection resources inside. So, it needs to have one or more address spaces associated with it (CIDR), which can be segmented into subnets, within which resources will reside. The scope of a virtual network is a single region; however, several virtual networks of the same or different regions can be connected together by virtual network peering as shown below:

VNets can be used to:

• Create a dedicated private cloud-only VNet to allow services and VMs within the VNet to communicate directly and securely in the cloud.



• Securely extend a data center, by building traditional site-to-site (S2S) VPNs or Express Route private circuits, to securely scale capacity.



• Deploy hybrid clouds by securely connecting cloud-based applications to on-premises systems.

Key components of Azure VNets, include:

• Subnets: Subdivide a VNet into multiple networks which can be used for more granular separation of services



• IP addresses: Assign public or private IP addresses to an Azure VNet.
  
  
  
  
  
  • Use public IP address for public-facing communications. A dynamic or static IP can be assigned.
  
  
  
  • Use private IP address for connectivity within a VNet when using a VPN gateway or ExpressRoute. A dynamic IP assignment is a default, but a static IP can also be assigned.
  
  
  



• Network Security Groups (NSG): Network traffic ACLs which can be applied at a subnet or NIC level for filtering



• Application Security Groups (ASG): Group common workloads in world readable tags for use in NSGs



• Service Endpoints: secure critical Azure services resources to your VNET



• Private Link: private connectivity from a VNET to an Azure PaaS resource, customer-owned service, or Microsoft partner platform.



• Firewall: Azure offers a managed Firewall service that provides the ability to define L3-7 connectivity policies for granular control of what enters and leaves the network



• Load balancing: Load balancing solutions offered by Azure include:
  
  
  
  
  
  • Azure Traffic Manager – comparable to Route53 in AWS
  
  
  
  • Azure Load Balancer
  
  
  
  • Azure Application Gateway
  
  
  
  • Azure Front Door
  
  
  



• Routing tables: As with general routing, anytime traffic needs to leave a subnet, it needs a routing function to forward packets to other subnets and networks. A router does this using a routing table, and that route table configuration is exposed in Azure for customized configuration. Route table can have rules that define where traffic should be sent to, i.e a virtual network, virtual network gateway or virtual machine.



• User Defined Route (UDR): A static entry in a Route Table which can be used to forward traffic to a different Vnet, Network Virtual Appliance, . This can be a powerful tool to build a connection between hubs.



• Network Virtual network Appliance (NVA): Optional, for integration of 3rd party solutions, a virtual network appliance can be inserted into a VNet. This appliance is a virtual machine that executes a network function, such as a firewall, WAN optimization or other network function. To see a list of virtual network applications that can be deployed in a virtual network, see Azure Marketplace.

VPN with VNET

It is very common, if not ubiquitous, to need to have the cloud resources connect to On-Premises or other cloud resources. This is normally achieved by setting up a Virtual Private Network (VPN) between the two environments. As mentioned earlier, Azure VNet supports VPN connectivity as well. Such connectivity can be built between different VNets, or from a VNet to On-premises as shown in the picture below.

Azure support various VPN modes, such as Site-Site, Point-Site, Policy-based and Route-based. This gives the cloud user flexibility to choose the best option for their tunnel according to their use cases and endpoint devices. There a couple of key components involved in the setup:

• Virtual Network Gateway: Virtual Network Gateway sits on the boundary of a VNet’s subnet and enables connectivity between that subnet and other networks or VPNs. This is where most of the VPN configuration resides.



• Local Network Gateway: Local Network Gateway is a representation of customers gateway on the other end of the tunnel. This simply holds configuration that tunnel needs to know about to build a VPN tunnel to the other end



• Border Gateway Protocol (BGP): When setting up a hybrid cloud, we need to ensure that both ends of connection know about networks that reside on the other end. While static routing is an option, it normally isn’t the most suitable approach for a production network. In order to learn on-prem routes efficiently, there is a need for a routing protocol to communicate routes dynamically. BGP is the defacto choice of today, and Azure supports BGP over IPSec with route-based VPN options. With BGP running on top of you Azure VPN Gateway or ExpressRoute connection, you can propagate local BGP routes across your cloud and on-prem routers without the need for manual admin intervention. More information about the use of BGP with Azure VPN Gateway and ExpressRoute.

ExpressRoute with VNET

For business critical workloads in Azure, many organizations require a private connectivity method with higher bandwidth options along with increased reliability and lower latency.  To meet these requirements, Azure offers customers ExpressRoute circuits which are private connections between the Azure datacenters and a customer’s on-premise infrastructure.

Customers establish connections to Azure at an ExpressRoute location, such as an Exchange provider facility or Network service provider, and create peerings to access Azure IaaS, PaaS, and SaaS services.  For connectivity to VNETs, ExpressRoute private peering is used and the circuit is logically terminated on one, or multiple, VNETs.  This termination occurs using a virtual network gateway in the VNET which is deployed in a dedicated subnet called a ‘Gateway Subnet’.

There a couple of key components involved in the setup:

• Local Edge Routers: Traditional ExpressRoute Circuits are provided via connectivity providers like Equinix or AT&T.  Customer connectivity can be provided as a Layer 2 or managed Layer 3 service.  The Local Edge routers represent the connectivity providers routers that a customer would use to connect to the ExpressRoute circuit.



• Microsoft Edge Routers (MSEE): The MSEE routers represent the Microsoft Edge routers that terminate the ExpressRoute circuits.  These are peering locations for ExpressRoute specifically that are not tied to Azure Regions.  Customers typically select the peering locations closest to the Azure Region their workloads are deployed in.



• ExpressRoute Circuit: The ExpressRoute Circuit is initially deployed from the Azure portal and corresponds to the physical connectivity between the connectivity provider and the MSEE routes.   These circuits have varying bandwidth options as well as SKU selections depending on customer requirements.



• ExpressRoute Gateway:  A gateway is deployed in the customer VNET to terminate the logical connection of the ExpressRoute circuit. Gateways come in various bandwidth options as well as support availability zone deployments.  A gateway connect to multiple physical ExpressRoute circuits to provide additional levels of redundancy.



• Border Gateway Protocol (BGP): BGP is required for all ExpressRoute Circuits and is run between Microsoft and either the customer (for Layer 2 configurations) or the connectivity provider (for Layer 3 configurations).  AS-PATH Prepending is the only attribute currently supported across ExpressRoute circuits.