5 years after the first feedback request, Azure has finally added the Console Access feature to its Virtual Machine service.
The history ?
In the past, accessing a virtual machine was only possible via the network. Anything preventing you for accessing it (managing it) other than from the network path (ssh, rdp, remote powershell…) has dramatically bad impact –> Redeploy
For example :
You have enabled the firewall on the Virtual Macine –> Redeploy
You have a blue screen (that you can fix by changing a setting) –> Redeploy
Your screen is stuck on the ‘Please hit a key to continue’ –> Redeploy
Today, Azure has added the feature of Serial console access, which means that you can access the Virtual Machine, just you were accessing it via the console port –> No need for network connectivity to the OS
I’m continually working on designing Cloud solutions, and specifically, Azure based Cloud solutions. One of the building blocks when starting dealing with Azure, is the Networking infrastructure that we need to build.
One of the challenges that we may and certainly will encounter is how to imagine the cross connectivity model, between the different networks. Cross connectivity can involve the following networks :
On-premises DC to Azure VNET
Azure VNET to Azure VNET
Azure VNET to Azure VNET on different region
ROBO to Azure VNET
1- The options
The following table shows the different options that you can use to cross connect different networks to Azure VNET :
Network
Options
On-premises DC
Express Route
Site to Site (S2S) VPN
3rd part S2S VPN
Azure VNET
VNET to VNET (VPN)
VNET Peering
Express Route
3rd part S2S VPN
Azure VNET Different Region
VNET to VNET (VPN)
Regional VNET Peering
Express Route
3rd part S2S VPN
ROBO
Site to Site (S2S) VPN
3rd part S2S VPN
2- Understanding the options
2.1- Site to Site VPN
The Site to Site VPN is a connectivity option that can be used to connect an Azure VNET to any network over internet, and using the VPN technology. The S2S VPN is the fastest way to establish a trusted private connection between your network and an Azure VNET.
The S2S VPN requires that you deploy an Azure VPN Gateway on the Azure VNET (An Azure managed gateway), and establish a VPN connection with a compatible VPN device on your side. The Azure VPN Gateway provides 99.9 SLA (under the hood, 2 VPN gateway instances in Active/Passive mode). You can in addition achieve a more resilient configuration with the Active/Active configuration (No published SLA)
a- Requirements and prerequisites
A VPN Gateway deployed on each VNET (2 VNETs can’t use the same VPN gateway)
A compatible VPN device on your side (Note that even if your device is not listed, it can be used as long as it supports the VPN configuration required by Azure)
ExpressRoute is the Microsoft offer that enable the customer to establish a low latency, private and high bandwidth network connection to the Azure data-centers. Without entering the technical details, ER is a Layer 3 private connection to Azure networks, it travel through a dedicated circuit from your data-center to the Azure networks, without going to Internet.
ER is a Enterprise offer to customers that require high bandwidth and low latency connection to their Azure workloads. It can provide different bandwidth options, that can go from 50Mbps to 10Gbps, and an SLA of 99.9
a- Requirements and prerequisites
An ER Gateway deployed to your VNET (An ER circuit can be shared between different VNETs)
An Exchange/Network provider that can provide the connection to Azure ER
b- Pro and Cons
Pro
Cons
High Bandwith, low latency, private connection to Azure
An ER circuit can be shared between different VNETs, providing both full mesh connection between the VNETs and a connectivity to on-premises for all VNETs
Can be extended to connect VNETs on other regions
The possibility to use Azure Microsoft peering (and Public Peering) to reach other Microsoft Services directly without going through internet. Services like Azure PaaS services (Web Apps, Azure SQL..) and Office 365 services…
Can take time to prepare and establish the circuit (weeks to months: contract with a network/exchange provider)
The cost can be significant for high bandwidth/unlimited tiers
The outbound data leaving Azure in case you subscribed to the metered plan
ER Premium Add-on in case you wish to enable premium features like sharing the ER circuit with VNETs outside the geopolitical region when the ER circuit is established
VNET Peering is an Azure technology that allows you to link/peer/connect 2 or more Azure Virtual Networks, using few clicks and without deploying any additional resource. 2 peered VNETs are like a bigger VNET, that’s it. Imagine putting a wire between two networks, and start exchanging traffic between them, this is VNET peering.
VNET peering establishes a private, LAN-like connectivity between 2 or more virtual networks. Resources within the virtual networks will see each other just like they were on the same one.
a- Requirements and prerequisites
2 or more Virtual Networks (Note that peeing VNETs in different regions are currently in preview, and not available on all regions)
b- Pro and Cons
Pro
Cons
Easy to configure (few clicks)
LAN-like performance
Not negligible Cost (The pricing model is per volume, so not very predictable)
c- Pricing
You will pay for :
The data In and Out the VNET. For example, if you send 1 GB from VNET 1 to VNET 2, you will pay 1 GB leaving VNET 1 and 1 GB entering VNET 2
2.4- VNET to VNET
The VNET to VNET connectivity is just a S2S VPN between two VNETs, provided by the Azure VPN Gateways. It’s an additional cross connectivity option, that is cost-effective
a- Requirements and prerequisites
A VPN Gateway on each VNET
b- Pro and Cons
Pro
Cons
Simple to configure
Cost-effective as traffic between 2 VNETs within the same region is free, you pay only for the VPN Gateways (per hour)
The outbound data leaving Azure in case the VNETs are not within the same region
2.5- 3rd party S2S VPN
You can opt for establishing a network cross connectivity using your own technology, by using a virtualized VPN device (Or a device that uses any tunneling protocol). By deploying a Virtual Machine where your software is running (must be supported by Azure like a Linux-based Virtual Appliance), you can establish a connection to your other networks and then route traffic to your VNET using Route Tables (UDR)
a- Requirements and prerequisites
A Virtual Network Appliance supported by Azure
b- Pro and Cons
Pro
Cons
Keep your Enterprise technology
High Availability : Most HA protocols are not supported on Azure like VRRP
In a coming post, i will share a design i have recommended to one of my customers, showing one of the architecture that we can build, using Express Route and VNET peering. But this was for the context of that particular customer. Choosing which technology to use depends on many factors including :
Budget : We saw that ER and Peering are relatively expensive comparing the S2S VPN and VNET2VNET
Needs : I don’t need an ER between my ROBO and Azure if i have few data to exchange. But i need VNET peering if latency is mandatory between my workloads spread between VNETs
Time To Market : Establishing a S2S VPN is a way quicker than an ER circuit, so an emergency may leave you with no choice, at least for the short term
My recommendations
I can’t just recommend something without knowing the context and the needs, but in general, i see the picture like the following :
If you are in a Hybrid configuration for the mid/long term (More than 1 Year), then providing an Enterprise connection between your datacenter and Azure is crucial. East-West traffic requires high bandwidth / low latency connections, so ExpressRoute is the unique good choice.
If your workloads are spread between VNETs, and the latency/bandwidth matters, VNET peering is the best choice. If the connection quality is not mandatory, then you can opt for VNET2VNET connectivity, or you can share your ExpressRoute if it already exist.
The small and medium ROBOs can use S2S VPNs to connect to Azure. If the performance matters than an alternative architecture may see place. Establishing ER for a ROBO is neither practical nor cost effective. So you can opt for a hybrid architecture where all your offices are connected to a POP with high bandwidth / Low latency links, and an ER is linking the POP to Azure.
buildwindows 