Azure for the AWS user Part 2 : Virtual Machines and IaaS

Azure, AWS, Virtual Machines

In the second part of this series we look at Virtual Machine and other associated IaaS components and how these translate from AWS to Azure. As with the previous article, the intent here is to provide a high level overview of the service and relate it to it’s AWS counterpart so those of you that are coming to Azure from AWS know where to start looking for the services you need and the documentation to help you get started.

A Note on Classic and Resource Manager

Those new two Azure might feel a little confused with references to Classic and Resource Manger VM’s (and other resources) so it is worth clearing this up. Classic, or sometimes ASM (Azure Service Management) is the older style of resource, usually created in the older Azure portal and supporting the cloud service model of deployment. This classic model provided no real way to group resource together and management was much more difficult, but it also obfuscated a lot of concepts away from the user making custom configuration harder. The Azure Resource Manager or ARM stack introduced the Resource Group as a unit to group resources, and broke out resources like load balancers and IP addresses into their own top level resource. ARM also introduced the JSON based deployment template for automating the deployment process.

In this and future posts, we are going to focus solely on the ARM stack, as this is a much better way to deploy and manage VM’s and all new services are being deployed on ARM.

Further Reading:Resource Manager Deployment Model

Virtual Machines

Virtual machines form the core of IaaS services in both AWS and Azure (and underlay many PaaS services as well). Like EC2, Azure provides a variety or sizes of VM’s to meet your requirements for performance and capacity, along with multiple different Windows and Linux operating systems. VM’s, as with AWS are billed by the minute based on the size and operating system select. You will find VM services in Azure are very similar to AWS in a lot of ways, but with slightly different naming conventions.

When deploying a virtual machine, you will also need a number of other resources to go along with it, in teh same way teh AWS requires VPC’s and Elastic IP’s. When creating the VM through the portal it will guide you through the process of creating these resources you need to be able to start your first VM.

  • Virtual Network – Similar to a VPC, a container for your VM’s that provides a boundary as well as networking resources and connectivity to the outside world.
  • Storage Account – Similar to EBS, a place to store your Azure VM disks. This has been made less complicated with the introduction of managed disks (see below)
  • Network Card – NICs are now a top level resource with ARM VM’s
  • IP Address – IPs are assigned to to a NIC and can be external or internal, static or dynamic

We will go into more detail on all of these below, but if this is your first time creating Azure VM’s I recommend using the portal and letting it guide you through creating the required resources.

Further Reading: Overview of Windows virtual machines in Azure

Images

As with AWS, Azure offers a large array of VM images to create VM’s, including both Windows and Linux. VM’s can be created using gallery images for standard operating systems, or if you want more complex custom images then the Azure Marketplace can provide this.

It is also possible to create custom images yourself, however this process does require the use of PowerShell.

Further Reading:

Azure Marketplace Images

Create Azure Custom Images

Machine Sizes

As with AWS VM’s can be created in a variety of different sizes based on your requirements

  • A series – The original general purpose virtual machine, similar to the T2 Series in AWS. These can be deployed on a variety of different physical hardware, throttled to offer consistent performance. - The Av2 series is an updated A SKU with more modern CPU architectures, similar to the M4 AWS series
  • The A0 VM size is the only Azure VM where hardware is oversubscribed and other users may impact performance. This VM size is only intended for very simple test workloads
  • D Series are intended for workloads that require higher compute power and temporary Disk performance. They include SSD based temporary disks, faster processors and a higher CPU to Memory ratio. They are similar to the I2 series in AWS - The Dv2 series is an updated D SKU, with newer CPU architecture offering 33% more performance.
  • F Series – these are similar to the D series but offer less memory per core and less SSD space, at a lower price point.
  • G Series – These are memory optimised VM’s, offering significantly more memory per core, similar to R3/4 series in AWS
  • H series – VM’s designed for High Performance Computing, with the fastest performing Haswell CPU’s, DDR 4 memory and SSD storage. They also offer low latency RDMA networking. Similar to the C3/4 series in AWS
  • N Series- VM’s offering GPU based processing. These are available in two variants, NV, offering the NVidia Tesla M60 GPU and the NC instance offering Tesla K80 cards. Similar to AWS G2 series.

Many of these VM’s are also available in a S configuration (e.g. DS, GS series). These machines offer the same hardware as the non S series, but with the ability to connect to Azure premium storage, which provides SSD based storage for additional data disks, similar to the EBS SSD offering.

Each category of VM has multiple sizes within it, such as A2 and D14 etc. For the A and D series these numbers are somewhat arbitrary and indicate the increasing size of the VM, from the F series onwards the number indicates number of CPU cores.

Further Reading: Sizes for Windows virtual machines in Azure

Virtual Machine Extensions

Microsoft and many third parties provide services through virtual machine extensions. These are extension that can be added to VM’s to install software inside the VM once provisioned. These extensions includ Anti Virus, Monitoring software, Backup Services etc.

Further Reading: [Virtual machine extensions and features for Windows](http://(https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-extensions-features)

EBS and Storage Accounts

As with AWS, persistent VM Disks (so OS and Data) disk are backed by storage, in this case Azure Storage. Up until very recently, this differed from AWS in that when you create a VM you need to also create a storage account and specify this for use with the VM, unlike EBS where you can just specify that you wish to EBS back a volume and the platform works it all out for you. Similarly, you need to manage the distribution of VM’s over storage accounts for higher availability etc. Storage accounts can be standard (HDD) or Premium (SSD).

However, in the last few weeks Azure released Managed Disks, this is basically the same concept as EBS backed volumes. You specify the size and how many disks and the platform takes care of allocating storage accounts and dealing with all the work behind the scenes. I recommend that if you are creating new VM’s you use managed disks.

Further Reading: Managed Disks

VPC’s and Virtual Networks

Virtual Networks or VNets are the equivalent of the AWS VPC, they provide the basic networking functionality as well as forming the boundary with the rest of Azure and the wider internet. VNets contain subnets and subnets in turn contain VM’s. Unlike AWS, Azure VNets have an outbound NAT gateway built in, so all VM’s have outbound internet access by default. There is no cost for a VNet, but obviously there may be costs for services that go into it (such as VM’s).

We’ll go into more details on NSG’s and associated network functions (such as load balancers) in a post dedicated to this.

Further Reading: Virtual Networks

ACL/Security Groups and Network Security Groups

Azure has a single network security item, the Network Security Group or NSG, rather than AWS’s ACL and Security groups. An NSG can be applied either to a VM or a subnet and defines inbound and outbound network rules. The NSG’s include default rules for communication between subnets and for outbound internet access, however these can be overridden if required.

Further Reading: Control network traffic flow with network security groups

NICS and IP Addressing

Network Interfaces (NICs) are top level objects in the ARM model, and a VM can have one or more NIC. A NIC will have
a private IP, which by default is dynamic, but can be made static if required. Additionally a NIC can be assigned a public IP (essentially the same as an AWS elastic IP) which can again be static or dynamic. The first 5 public IP’s in a region are provided free, after that there is charge for each IP.

Further Reading: IP address types and allocation methods in Azure

In part 3 of this series we will delve deeper into Virtual Networks and Azure Networking Services.