Azure Virtual Machine Serial Access : Finally available

Hi all,

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

This is a so waited and wanted feature that is currently on Public Preview, check it here :

Future improvements

  • Adding the F8 keyboard key support to handle accessing early stage booting screen
  • Adding RDP support to Windows because only cmd or powershell administration is provided today

Enjoy !!


Azure Networking Cross connectivity : The Options

Hi all,

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


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)

b- Pro and Cons

Pro Cons
The fastest way to establish cross connectivity

No special configuration (VPN over internet)

A good solution for ROBO

No quality SLA (internet : latency, jitter…)

A maximum of 1.25 Gbps

c- Pricing

You will pay for :

2.2- Express Route

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.

ExpressRoute connectivity (Microsoft Credit picture)

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

Cannot be easily used for ROBO

c- Pricing

You will pay for :

  • The deployed ER Gateway (Per hour)
  • 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
  • The ER circuit

2.3- VNET Peering

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)


c- Pricing

You will pay for :

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

Cost : That depends

Bandwidth/Latency : Traffic is over internet

Additional Management (Not a managed service)

c- Pricing

You will pay for :

  • The Virtual Machines you deploy
  • The outbound data leaving Azure

3- How to choose between the solutions

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.