Azure for the AWS User (Part 2): Virtual Machines and IaaS

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 its 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 to azure might feel a little confused with references to classic and resource manger vms (and other resources), so it is worth clearing this up. classic, or sometimes called 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 resources together, and management was much more difficult — and 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 vms, 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 vms to meet your requirements for performance and capacity, along with multiple different windows and linux operating systems. vms in azure, as with aws, are billed by the minute based on the size and operating system selected. you will find that 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 the same way that aws requires vpcs and elastic ips. 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 virtual network is a container for your vms that provides a boundary as well as networking resources and connectivity to the outside world.
• storage account : similar to ebs, this is 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 vms.
• ip address : ips are assigned 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 vms, 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 vms, including both windows and linux. vms 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, but this process does require the use of powershell.

further reading:

• azure marketplace images
• create azure custom images

machine sizes

as with aws, vms 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 vms 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-optimized vms, offering significantly more memory per core, similar to r3/4 series in aws.
• h series : these are vms designed for high-performance computing, with the fastest performing haswell cpus, ddr 4 memory, and ssd storage. they also offer low latency rdma networking. they're similar to the c3/4 series in aws.
• n series : vms 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. they're similar to the aws g2 series.

many of these vms are also available in an 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. 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 the 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 extensions that can be added to vms to install software inside the vm once provisioned. these extensions include anti-virus software, monitoring software, backup services, etc.

further reading: virtual machine extensions and features for windows

ebs and storage accounts

as with aws, persistent vm disks (so os and data) 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. that's 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 vms 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 vms, you use managed disks.

further reading: managed disks

vpc's and virtual networks

virtual networks, or vnets, are equivalent to the aws vpc. they provide 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 vms. unlike aws, azure vnets have an outbound nat gateway built in, so all vms 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 vms).

we'll go into more details on nsgs 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 nsgs include default rules for communication between subnets and for outbound internet access, though these can be overridden if required.

further reading: control network traffic flow with network security groups

nics and ip addressing

nics are top-level objects in the arm model, and a vm can have one or more nics. 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 five public ip's in a region are provided for free, but after that, there is a charge for each ip.

further reading: ip address types and allocation methods in azure

in part three of this series, we will delve deeper into vnets and azure networking services.