VM sizes

At the time of writing this book, the following VM series and sizes are available:

VM series are updated constantly. New series, types, and sizes are added and removed frequently. To stay up to date with these changes, you can refer to the following site:

https://docs.microsoft.com/en-us/azure/virtual-machines/sizes.

Azure Spot Virtual Machines

Azure offers the ability to buy unused compute capacity for significantly reduced costs. This provides a greatmechanism for test or development workloads that can handle interruptions at a very low cost. The limitation is that when Azure needs the capacity again, it will evict the Azure Spot Virtual Machines. The sizes available are completely dependent on the current capacity used within Azure. They will be influenced by factors such as region and the time of day.

When configuring spot instances, you define an eviction policy based on capacity and the maximum price you are willing to pay for the VM. You will also select the action to be taken upon eviction being either to deallocate or to delete.

When the VM is deployed, the following rules will apply:

• Max price is set to >= the current price: The VM will be deployed if capacity and quota are available.

• Max price is set to <= the current price: The VM will be evicted and you will be given 30 seconds’ notice.

•   The max price option is set to -1: The VM will not be evicted due to pricing reasons. You will pay up the amount of the standard VM charges and it will not exceed those costs.

• Changing the max price: Before you can change the max price on a VM, the VM will need to be deallocated and you will need to define your new max price to apply.

There are limitations that apply on spot instances, such as VMs can’t be migrated, there are no offered SLAs, and there are no high availability guarantees.

The following subscription types support spot instances: Enterprise Agreement (EA), Pay-as-you-go (003P), Sponsored (0036P and 0136P), and Cloud Service Provider (CSP).

Networking

VMs on Azure have a plethora of networking options available to them, as you will see further in the chapter when we deploy a VM. The virtual network and subnet can be created on the creation of a VM. Alternatively, we can join an existing subnet on a VNet we have created. Networking can be controlled through a basic five-tuple network firewalling service named a network security group.

Network security groups

Network security groups (NSGs) act as a basic five-tuple firewall service for network-connected resources. These can be either applied at a subnet layer or a network interface card (NIC) layer in Azure. NICs are typically associated directly with VMs but could also be from services that have a private endpoint attached. NSG rules are defined by the following components: source, destination, port, protocol, and action (deny or allow). Each rule is given a priority and the lower the priority, the higher the precedence. The first rule matched on the traffic will be the rule that is chosen and followed. We use NSGs to restrict who can access services, from what source (such as IP address), and to what hosts (normally the destination). You can choose to associate a single NSG with a NIC and/or subnet. The same NSG can be applied several times and associated with several NICs and subnets. For VM deployments, you will likely open port 3389 (RDP – Windows) or 22 (SSH – Linux) for management of the VM, but carefully consider the source addresses you allow.