What is an Azure VM?

A virtual machine (VM) is an image file that acts as an actual computer. Put another way, a VM is a computer hosted inside another computer.

A VM is generally sandboxed from the rest of the host (hypervisor) system and the other VMs (guests) running on that host. This enables you to build an isolated environment to run different workloads while optimizing hardware resources like compute (CPUs, memory), networking interfaces, and storage available on that host. You can separate or connect each VM with other VMs depending on your needs. This has the added benefit of ensuring that the effects of malware (such as viruses) and cyber-attacks can be restricted to specific exposed or interconnected VMs.

With Azure VMs, the same virtualization principle is extended to physical servers hosted in different Azure regions across the world. In a traditional virtualization environment, the organization hosting the VMs would also manage the physical host infrastructure, including all related infrastructure workloads like firewalls, routers, switches, and so on. In an Azure-hosted VM, Microsoft is largely responsible for ensuring that the back-end hardware services are up and running for customer consumption as and when needed. This removes the overhead of maintaining, upgrading, and managing the physical infrastructure layer from in-house IT teams.

Organizations use Azure VMs in a few different ways. Five common examples are as follows:

• To run test and dev workloads Organizations that are heavily invested in on-premises infrastructure generally find it easier to deploy test and dev workloads in Azure VMs. This enables their IT teams to become familiar with the cloud while also testing and verifying their on-premises applications to better plan for future migrations to the cloud. Organizations might also initiate new application builds or transformation projects by hosting the initial test and dev workloads in the cloud, so the application code will be built with cloud-native features for maximum benefits.

• To run applications requiring scalability and flexibility VMs are often used to accommodate applications that require the ability to scale quickly or in short bursts for temporary or infrequent loads.

• To provide redundancy for the datacenter Some organizations use Azure VMs to host their disaster-recovery environment and/or redundant infrastructure.

• To reduce on-premises hardware footprint Some organizations move to Azure VMs when refreshing or upgrading hardware to reduce the hardware footprint in the on-premises or co-located datacenters. This also helps reduce related datacenter costs, such as for power, cooling, security, and compliance audits.

• To reduce on-premises management overhead Some organizations use Azure VMs to reduce the management overhead of underlying hardware, hypervisors and upgrades, and other interconnected components, such as networking, security solutions, and so on.

Operating system support

Microsoft Azure supports both Windows- and Linux-based VMs. However, make sure to check that your version of Windows or Linux is supported, as these change over time. (See Table 1-1.) Also, although versions older than Windows Server 2008 R2 are supported, clients must bring their own images and have an active support agreement with Microsoft for operating systems that have reached their end-of-life.

VM series

Microsoft provides various specialized Azure VM series. It’s critical that you understand these series, as well as your application requirements, so you can decide which VM series to run your workloads on. As of early 2022, some of these series are as follows:

• A-series VMs These are basic, entry-level VMs with CPU performance and memory configurations best suited for workloads used for test and development. A-series VMs might also be good for low-traffic web servers, small to medium databases, servers for proof of concepts, and code repositories. They provide a low-cost option to get started with Azure.

• Bs-series VMs These are a great option for workloads that typically require low to moderate baseline CPU utilization, but occasionally require significantly higher CPU utilization for brief periods when demand rises. Web servers handling low traffic volumes are an ideal workload to host on such servers. Bs-series VMs are an economical option to use even for dev and test workloads, where CPU utilization levels are not that high for most of the development cycle. Other use cases include small databases, micro services, servers used for proof of concepts, and low-intensity workloads, such as AD domain controllers, print servers, Windows Update servers, and similar workloads in most environments.

• D-series VMs D-series VMs are the most versatile Azure VM series. There are multiple VM subseries available under the D-series: Ds, Dds, and Das-series, each with different VM types. Each VM type uses different processor types and can achieve different levels of CPU performance, providing multiple options based on the application requirements. The CPU and memory combinations available in the D-series address the needs of most production environments. In addition to the use cases mentioned in the preceding bullets, D-series VMs work well for analytics workloads and workloads requiring in-memory caching.

• DC-series VMs DC-series VMs use the latest generation of Intel XEON E-2288G processor with SGX technology. They include Software Guard Extensions (SGX), which are a set of instructions that increases the security of the in-memory application code and data to protect it from tampering. This makes them ideal for workloads that require confidential data processing and storage. Some use cases for DC-series VMs include blockchain, intelligence analysis, fraud detection, confidential machine learning, and so on.

• E-series VMs E-series VMs are optimized for memory-intensive workloads; they have a higher memory-to-core ratio. Ideal use cases include SQL, Oracle, or SAP HANA databases (which require more in-memory capacity), business intelligence and in-memory analytics workloads, and so on.

• F-series VMs F-series VMs are built to support more CPU-intensive workloads; they have a higher core-to-memory ratio. They are ideal for workloads that run compute-intensive applications, such as batch, gaming, and web servers.

• H-series VMs Also called high-performance computing VMs, H-series VMs are optimized to support large computing and modeling application requirements, such as financial modeling, weather-pattern analysis, computational chemistry, and similar applications. These VMs have a very high resource capacity and are optimized for intensive computing.

• N-series VMs N-series VMs are GPU-enabled VMs that are ideal for graphics-intensive workloads, such as gaming, deep learning, graphics rendering, and so on. There are different VM offerings within this series that are aimed for different computing scenarios. Some of these VM offerings support InfiniBand connections, which provide extremely high networking throughput and performance.

Azure regions

Azure VMs are available in datacenters spread globally across 54 regions, with new regions added on a near-constant basis to address area needs. Each region consists of a set of datacenters located within very low latency perimeters. Regions are connected together with dedicated high-speed networks.

The location of the users who will employ your VMs will be a key factor in deciding which region to choose for your workloads. For example, if most of your users are based on the east coast of the U.S., you will most likely choose to use VMs in that location. This will improve the likelihood that your users will have the best possible experience when accessing these resources. If, on the other hand, your users are split among multiple geographies, you will have to choose by possibly hosting test and dev workloads to determine which region might be best-suited for your needs.

Depending on your application design, you might opt to use VMs across multiple regions to host your workloads, thereby providing an optimal experience to users in different geographic areas. Be sure you have a clear understanding of application functionality and hosting requirements before making your decision about which region(s) to choose.

If the primary users of your application(s) are external-facing customers, where you choose to host certain workloads might depend on where those users are based. For example, the location of external-facing application workloads could reflect where your customers are, while the location of internal-facing workloads, for employees, might depend on where those employees are.

You should review the list of Azure regions available to select the region based on your needs, accounting for the factors that will affect the usage and growth of your workloads. When determining which region should host your workloads, latency is a particularly critical factor. Fortunately, there are online tools to enable you to gauge the average latency between your location (or other locations or ISPs used within your organization) and various Azure datacenters around the world. For example, Figure 1-1 shows the average latency from my workstation to the different datacenters in the U.S. Datacenters in the West US region have the lowest latency, but the West US 2 region has acceptable latency, too. So, in my case, I would specify the West US region as my primary datacenter candidate (meaning I would use the VMs in datacenters in this region by default) and the West US 2 region as my secondary datacenter candidate (meaning I would use VMs in datacenters in this region if there were not adequate VMs in the US West region).

Compute sizing and pricing

In addition to selecting the appropriate VM series and region, you need to choose the right compute size for your workloads. Your choice will depend on your performance needs as well as your budgetary constraints.

As shown in Figure 1-2, the compute resources with different VM types have various prices. These are based on a number of factors, including the processor, memory, and network resources available on the underlying hardware level. Prices will vary depending on when you run the comparison, so it is imperative to look at VM prices near or on the date of workload creation rather than relying on earlier cost comparisons, especially if those comparisons are weeks or months old.

Naturally, price is important. But when comparing prices for VMs, you must ensure that the VMs you are choosing from meet your technical needs. A VM that does not support your application’s technical requirements will generally cause more harm than good in terms of cost savings. On a similar note, if a particular datacenter is the only one capable of meeting your needs with regard to latency, then there’s no need to compare VM costs across regions.

Azure VM creation walkthrough

The following sections step you through the process of creating an Azure VM using the Azure Portal, Azure PowerShell, and Azure CLI.

#Define required variables
$rg = "RG01"
$vmname = "VM01"
$location = "EastUS"
$vnet = "vNET01"
$subnet = "Subnet01"
$nsg = "NSG01"
$publicip = "publicIP01"
#Create resource group for VM
New-AzResourceGroup -Name $rg -Location $location
#Create VM
New-AzVm `
    -ResourceGroupName $rg `
    -Name $vmname `
    -Location $location `
    -VirtualNetworkName $vnet `
    -SubnetName $subnet `
    -Image Win2019Datacenter `
    -SecurityGroupName $nsg `
    -PublicIpAddressName $publicip `
    -OpenPorts 3389

#Define required variables
rg = "RG01"
location = "EastUS"
vmname = "VM01"
nsg = "NSG-01"
publicip = "publicIP-01"
#Create resource group for VM
az group create --name $rg --location $location
#Create VM and open RDP
az vm create 
    --resource-group $rg 
    --name $vmname 
    --image Win2019Datacenter 
    --nsg $nsg 
    --public-ip-address $publicip 
    --public-ip-sku Standard 
    --nsg-rule RDP 
    --admin-username azureuser

az vm open-port -g $rg -n $vmname --port 3389 --priority 100

Availability sets

An availability set is a group of two or more VMs hosted in the same Azure datacenter but on different hardware. This ensures that if the datacenter experiences a physical hardware failure, one or more VMs will remain online. The VMs in an availability set are generally of the same configuration and host the same application or service, so there is redundancy if one VM goes offline. Microsoft offers a 99.95% SLA for availability sets.

For configurations in which multiple web servers or application front-ends are located in the same Azure region and are hosting the same workload across multiple servers for redundancy and scalability, adding VMs to an availability set would be highly recommended. Database servers set up with DB replication would also benefit from using availability sets.

Each availability set is assigned three fault domains and 20 update domains, and each VM in an availability set is assigned to one fault domain and one update domain. If the number of VMs exceeds three, the fourth VM will share the same fault domain as the first VM. (See Figure 1-10.)

• A fault domain is a set of VMs that are using the same storage, power source, and networking resources. Any sudden hardware or physical infrastructure failure in an Azure datacenter that pertains to hard disks, power, or networking in a physical rack can result in unplanned downtimes. In such unplanned maintenance events, Azure automatically fails over any VMs hosted on the affected fault domain to another fault domain, assuming those VMs are part of an availability set.

• An update domain is a set of VMs that receive Microsoft updates at the same time. As you know, Microsoft patches any security vulnerabilities on a periodic basis. This helps to improve security, reliability, and performance. Generally, when these updates are performed, it does not affect the hosted VMs. However, on occasion, patched VMs require a reboot for the updates to take effect. In a large cloud environment, such a complex operation is planned well in advance to minimize the business impact on affected clients. This is where update domains come in. Update domains enable Azure to reboot VMs in groups rather than all at once. When the VMs in one update domain are finished updating, Azure can move onto the next one.

Availability set walkthrough

The following sections step you through the process of creating an availability set using the Azure Portal, Azure PowerShell, and Azure CLI.

#Define variables
$rg = "RG01"
$location = "EastUS"
$avs = "AVSet-01"
$vm = "vm-01"
$vNet = "vNET-01"
$subnet = "Subnet01"
$nsg = "NSG-01"
$publicip = "PublicIP-01"
#Create an availability set
New-AzAvailabilitySet `
   -Location $location `
   -Name $avs `
   -ResourceGroupName $rg `
   -Sku aligned `
   -PlatformFaultDomainCount 2 `
   -PlatformUpdateDomainCount 5
#Create a VM in the availability set
New-AzVm `
        -ResourceGroupName $rg `
        -Name $vm `
        -Location $location `
        -VirtualNetworkName $vNet `
        -SubnetName $Subnet `
        -SecurityGroupName $nsg `
        -PublicIpAddressName $publicip `
        -AvailabilitySetName $avs

#Define variables
rg="RG02"
avs="AVSet-01"
vm="VM-02"
vnet="vNET-01"
subnet="Subnet-01"
avs="AVSet-01"
publicip="publicip-01"
#Create availability set
az vm availability-set create 
    --resource-group $rg 
    --name $avs 
    --platform-fault-domain-count 2 
    --platform-update-domain-count 5
# Create VM inside the availability set
az vm create 
     --resource-group $rg 
     --name $vm 
     --availability-set $avs 
     --vnet-name $vnet 
     --subnet $subnet 
     --public-ip-sku Standard 
     --public-ip $publicip
     --image Win2019Datacenter 
     --admin-username azureuser

Availability zones

Each Azure region is made up of three availability zones. (See Figure 1-13.) An availability zone consists of one or more datacenters equipped with their own power, cooling, and networking. If one datacenter in the availability zone experiences an outage, VMs in another datacenter in the availability zone will still be available. For this reason, availability zones provide a higher level of redundancy than availability sets. Microsoft offers 99.99% SLA for availability zones.

The concepts of fault domains and update domains also apply to availability zones. Azure automatically ensures that VMs are split between fault domains and update domains, even between availability zones.

Availability zones walkthrough

The following sections step you through the process of assigning a VM to an availability zone using the Azure Portal, Azure PowerShell, and Azure CLI.

#Define variables
$rg = "RG01"
$location = "EastUS2"
$vm = "vm01"
$vNet = "vNET-01"
$subnet = "Subnet01"
$nsg = "NSG-01"
$publicip = "PublicIP-01"
#Create a VM in the availability zone
New-AzVm `
        -ResourceGroupName $rg `
        -Name $vm `
        -Location $location `
        -VirtualNetworkName $vNet `
        -SubnetName $Subnet `
        -SecurityGroupName $nsg `
        -PublicIpAddressName $publicip `
                   -Zone 2

#Define variables
rg="RG01"
location="EastUS2"
vm="vm01"
# Create VM
az vm create --resource-group $rg --name $vm --location $location
--image Win2019Datacenter --zone 2

Proximity placement groups

As your use of VMs grows, those VMs might be placed in different datacenters across an Azure region. This can result in higher than acceptable network latency between VMs. Placing your VMs in proximity placement groups ensures that the VMs are located as close to each other as possible. This enables you to achieve the lowest possible latency and avoid performance issues. This might be important for interconnected workloads, such as applications and databases.

Proximity placement groups walkthrough

The following sections step you through the process of creating a proximity placement group as assigning a VM to it during VM creation using the Azure Portal, Azure PowerShell, and Azure CLI.

#Define the required variables
$resourceGroup = "RG01"
$location = "East US 2"
$ppgName = "PPG-01"
$vmName = "VM01"
# create the proximity placement group
$ppg = New-AzProximityPlacementGroup `
   -Location $location `
   -Name $ppgName `
   -ResourceGroupName $resourceGroup `
   -ProximityPlacementGroupType Standard
#create a VM in the Proximity Placement Group
New-AzVm `
  -ResourceGroupName $resourceGroup `
  -Name $vmName `
  -Location $location `
  -ProximityPlacementGroup $ppg.Id

#Define the required variables
resourcegroup = "RG01"
location = "East US 2"
ppgname = "PPG-01"
vmname = "VM01"
#Create a Proximity placement group
az ppg create -n $ppgname 
   -g $resourcegroup 
   -l $location 
   -t standard
#Create a VM in the Proximity Placement Group
az vm create 
   -n $vmname 
   -g $resourcegroup 
   --image Win2019Datacenter 
   --ppg $ppgname  
   --size Standard_D3_v4  
   -l $location

Managed disks

Managed disks do not require an Azure storage account in the back end to host the disk. This removes all applicable limitations on the storage account. Managed disks can scale independently and have much higher levels of availability and durability.

Some key features of managed disks are as follows:

• Secure by default Managed disks support disk encryption by default using both Azure-managed and customer-managed encryption keys. Encryption can be performed on the OS level, too, providing an additional layer of protection.

• Built-in high availability Designed for 99.999% availability, managed disks are extremely durable and highly available by default. In addition, managed disks always maintain three replicas of data, making them highly tolerant against failures.

• Zone resilient Managed disks offer support for availability zones, making them resilient to zone failures.

• Scalable Managed disks can support up to 50,000 VM disks per region, making them highly scalable—especially when compared to unmanaged disks.

• Easier to manage Managed disks offer support for role-based access controls (RBAC), allowing for granular access control.

• Higher performance Compared to unmanaged disks, managed disks provide predictable and high IOPS for all disk types.

• Backup support Azure Backup can be used to back up and restore managed disks.

Unmanaged disks

Unmanaged disks require you to create an Azure storage account to hold the VM disk files. So, they are subject to all the limitations that apply to the storage account level, such as IOPS throttling, the number of disks supported per storage account, and so on.

Some key characteristics of unmanaged disks are as follows:

• Performance limitations IOPS limitations on the Azure storage account level apply to all standard unmanaged disks sharing a storage account. Premium disks provide predictable performance levels.

• Scalability limitations It is recommended to have a maximum of 40 disks per standard storage account.

• Customer-managed encryption Encryption is performed on the storage-account level and must be enabled manually.

• Geo-redundancy options You can set up geo-redundancy for unmanaged disks using either the GRS or RA-GRS options during disk creation.

• Support for migration to managed disks Unmanaged disks can be easily migrated to managed disks, which provide higher resiliency and security and offer more features.

Disk roles

Azure VMs support three main disk roles (see Figure 1-22):

• OS disk An OS disk is a default disk that is attached to every VM and contains the operating system running on the VM. In addition to hosting the OS, this disk can be used to host small applications or web services that do not have high IOPS or storage needs.

• Data disk A data disk is an additional disk that can be attached to a VM to store applications, databases, or other data required for the VM to perform its functions. Multiple data disks can be attached to a VM (depending on the VM SKU limitations). Each disk is provided a custom drive letter and can be scaled to up to 32 TB in size.

• Temporary disk The Azure platform provides a temporary disk on most VMs. The size of the disk depends on the VM SKU. This disk is to be used only for paging or swap files, as the data on this disk is not persistent; a forced VM restart or platform-level maintenance can result in data loss. It is not recommended to store any application, database, or other critical files on this disk.

Disk SKUs

Azure currently provides four disk SKUs. Each of these can be selected in different scenarios based on OS, app, or database requirements:

• Standard HDD This SKU provides low-cost reliable HDD disks to Azure VMs. The performance of Standard HDDs is highly variable and unpredictable, making them ideal for low-intensity or low-criticality workloads, such as for dev/test VMs, AD domain controllers, low-traffic web servers, and so on.

• Standard SSD This SKU provides cost-effective SSD disks that are optimized for workloads that require lower IOPS at a consistent level. It is a good entry-level SSD disk experience and, considering the cost, is ideal for workloads that do not work well on Standard HDD disks but do not require the high levels of performance provided by Premium and Ultra SSD disks. Standard SSD disks are more reliable and provide lower latency than Standard HDD disks, making them ideal for most web servers and lightly used application servers.

• Premium SSD This SKU provides a high-level of IOPS and low latency. It is suitable for workloads requiring high-performing disks. Premium SSD disks are an ideal choice for most mission-critical workloads, including SAP HANA, Microsoft SQL databases, and Enterprise ERP applications.

• Ultra disk This SKU provides the highest levels of throughput and IOPS coupled with low levels of latency compared to the other disk types available in Azure. Ultra disks support dynamic disk performance optimization without affecting the workload running on top. This makes them ideal for data-intensive workloads, such as with relational databases, enterprise applications such as SAP HANA, and other transaction-intensive workloads.

Network interfaces

Network interfaces connections (NICs) allow VMs to be connected within an Azure virtual network so they can communicate with other resources or accept traffic from users. Every VM requires a minimum of one NIC; some VM SKUs support multiple network NICs. Each NIC connects a VM to a specific subnet.

IP addresses

Every VM NIC must be assigned a private IP address, but it can also be assigned a public IP address depending on the VM’s access and connectivity requirements and the network design.

The private IP address is used primarily for internal communications within a VNET, which is an interconnected on-premises network. Internet communications are possible using network address translation (NAT) via a web application firewall (WAF) or Azure Firewall, which must be defined for every VM. The public IP address is used when VMs require direct internet connectivity for inbound and outbound communications or when communicating with other Azure services not connected to a VNET. Assigning a public IP address is optional and should be done with caution, as exposing every VM to the public internet is not recommended.

Public IP addresses can be defined on a VM level. However, the recommended approach is to use external load balancers or WAFs to manage internet-based ingress traffic and routes to the VMs’ private IPs. This protects VMs from being attacked directly from the internet.

Network security groups

To protect a VM’s inbound and outbound communication, you can set up a network security group (NSG) on the VM NIC or on the subnet where the VM is hosted. An NSG allows you to define rules to restrict or allow network traffic from other Azure resources, IP addresses, or IP ranges. It is recommended that you define NSGs for critical workloads or publicly exposed VMs either on the VM NIC or on the subnet level to only allow the required traffic to and from the VM. This will reduce the VM’s attack surface.

Reserved instances

Reserved instances (RIs) are VMs that are reserved on the Azure platform for a specific period of time, which can vary from one to three years. When a VM is set up as a reserved instance, the underlying hardware resources for that VM are reserved, ensuring that the VM will have access to them regardless of whether it is placed offline during the reservation period, no matter how long. There is no performance difference between a regular VM and a reserved VM of the same model and size. However, the reservation unlocks value in terms of large cost savings for your organization, as Microsoft provides discounts ranging from 20% to 60% on VM compute costs.

Understanding RI cost savings

Before you commit to using RIs, it is recommended that you run your VM workloads without RIs and gather consumption data. This data will help you understand your actual server usage, which will enable you to make a more informed decision about the VM size to reserve.

Microsoft offers different levels of savings for RIs. These depend on the number and size of the RIs you need to cover your projected workload and the term for which you want to reserve. Because RIs require upfront payment, you should review the pricing guidelines before you buy. Figure 1-23 shows the savings at the time of this writing for a D16a v14 VM hosted in the West US 2 datacenter. As you can see, the cost changes dramatically for the same instance when moving from a one-year RI to a three-year RI.

Therefore, you should consider the instance sizing requirements, based on either monitored use (Azure/on-premises) or specifications from the application developer, and the minimum timeframe for the load and subsequent usage that the application will experience to make a final decision.

Reservations walkthrough

The following section steps you through the process of creating a reservation using the Azure Portal.

Using the Azure Portal

To create a reservation using the Azure Portal, follow these steps:

1. In the Azure Portal, type reservations in the search bar. Then, under Services, click Reservations. (See Figure 1-24.)

   

2. Click Purchase Now to start the Purchase Reservations wizard. (See Figure 1-25.)

   

3. In the Products tab of the Purchase Reservations wizard, click Virtual Machine. (See Figure 1-26.)

4. The Select the Product You Want to Purchase page opens, with recommended reservations based on your usage history. (See Figure 1-27.) Click one of the recommended reservations to select it. Alternatively, click All Products and select a different VM SKU. Then click the Add to Cart button.

   

   

5. In the Products tab, enter the following information (see Figure 1-28), and click Review + Buy:

   • Reservation Name Enter a unique name for the reservation.

   • Billing Frequency Choose Upfront or Monthly to specify how you want to be billed.

   • Quantity Enter how many VMs you want to reserve.

   

6. On the Review + Buy tab, verify your settings and click the Buy Now button. (See Figure 1-29.)

   

   Azure initiates the procurement of the reservation. This can take a few hours, during which the reservation status will show as Pending. (See Figure 1-30.)

   

7. Monitor the status of the reservation to ensure that it is procured. (See Figure 1-31.)

   

8. Select the reservation. You will see the following options (see Figure 1-32):

   • Refund Click this to initiate a refund if you no longer require this reservation.

   • Exchange Click this to exchange this reservation for a higher VM SKU.

   • Rename Click this to rename the reservation.

   • Change Directory Click this to move the reservation to a different Azure subscription.

Azure Hybrid Benefit

Another great way to reduce costs is to leverage Azure Hybrid Benefit for Windows, SQL Server, RedHat, and SUSE Linux workloads. Azure Hybrid Benefit is a licensing configuration that can help you significantly reduce the expenses associated with running your workloads in the cloud. It works by allowing you to use your on-premises Software Assurance–empowered Windows Server and SQL Server licenses on Azure. Presently, this advantage applies to RedHat and SUSE Linux workloads too.

By using this benefit, you can reduce your licensing costs while running your workloads in Azure by 20 to 80% (or more), depending on your licensing contracts. To better understand how to leverage this benefit, consult your licensing partner(s), who helped you procure your license.

Azure Hybrid Benefit walkthrough

The following sections step you through the process of setting up Hybrid Use Benefit for a Windows VM workload using the Azure Portal, Azure PowerShell, and the Azure CLI.

#Define variables
$rg = "RG01"
$vm = "VM01"
$location = "East US"
#Create VM
New-AzVm `
    -ResourceGroupName $rg `
    -Name $vm `
    -Location $location `
    -ImageName "Win2019Datacenter" `
    -LicenseType "Windows_Server"

#Define variables
rg = "RG01"
vm = "VM01"
location = "East US"
#Create VM
az vm create 
    --resource-group $rg 
    --name $vm 
    --location $location 
    --image win2019datacenter 
    --license-type Windows_Server

Spot instances

Azure spot instances offer significant cost savings when performing scale-out operations. Spot instances enable you to run your workloads at a discount when there is unused capacity in the region where your VMs are hosted. Using spot instances is ideal for organizations running different types of workloads, such as the following:

• Test/dev workloads (including continuous delivery and integration workloads)

• Batch-processing jobs, large compute workloads, or graphics rendering applications or jobs

• Analytics and big data workloads

If the Azure platform determines that it needs the capacity back to handle a workload request from a pay-as-you-go client in the same region (who is charged a higher rate), it will terminate, or evict, the spot instance. Azure supports two eviction models:

• Capacity only With this eviction model, the VM instance is evicted only if Azure needs the capacity for a pay-as-you-go instance request in that region.

• Price or capacity With this eviction model, you set a maximum price (per hour) that you are willing to pay to run the spot instance. So, if Azure needs to free up capacity to handle a pay-as-you-go request, it will perform a price comparison. If the maximum price you set is more than the pay-as-you-go price, Azure will continue handling your spot instance. If not, your spot instance will be evicted.

The eviction process is managed by an eviction policy, which you set up when you create a spot instance. The eviction policy also enables you to specify whether a VM should be deallocated or deleted when a spot instance is de-provisioned:

• When a VM is deallocated, the compute capacity is removed, and any charges associated with this capacity no longer apply. However, the underlying disks remain in place—meaning, those charges do still apply.

• When a VM is deleted, the underlying disks are also deleted. This reduces the costs associated with the workload, which can be significant depending on your disk size, disk top, the number of spot instances you put in place, and so on. However, when you are ready to reinstate the workload, you will need to retrieve the source data from its original location, which can take time.

Deallocating rather than deleting the VM enables you to quickly spin your workload back up when you need it or when capacity becomes available. The option you choose will depend on your application design and requirements.

Azure spot instance walkthrough

The following sections step you through the process of setting up spot instances for VM workloads using the Azure Portal, Azure PowerShell, and the Azure CLI.

#Define variables
$rg = "RG01"
$vm = "VM01"
$location = "East US"
#Create Spot Instance with vmconfig
$vmConfig = New-AzVMConfig -VMName $vm -VMSize Standard_D1 -Priority "Spot" -MaxPrice -1 -EvictionPolicy Deallocate | `
New-AzVM -ResourceGroupName $rg -Location $location -VM $vmConfig

#Define variables
rg = "RG01"
vm = "VM01"
location = "East US"
#Create Spot Instance with vmconfig
az vm create 
    --resource-group $rg 
    --name $vm 
    --location $location 
    --image WindowsServer2019Datacenter 
    --admin-username adminuser 
    --priority Spot 
    --max-price -1 
    --eviction-policy Deallocate

Dedicated hosts

In a regular Azure VM setup, the underlying host can be shared across multiple clients, which can create compliance, security, and/or regulatory issues. Using a dedicated host helps address these issues.

Azure dedicated hosts provide physical servers to host Azure VMs. The physical server and its workload capacity is used exclusively by a single organization. It is not shared with other Microsoft Azure customers. Once a dedicated host is provisioned, the organization has control over its infrastructure and can define host-level maintenance policies.

Benefits of dedicated hosts

Using dedicated hosts offers a few benefits. These are discussed here.

VM SKU consolidation

You can set up VMs of different sizes on the same dedicated host. However, the VMs must be of the same series. For example, suppose you need to host VMs of different sizes within the Exds series—E2ds, E4ds, E8ds, and E16ds. In this case, you could select an Edsv4-Type 1 dedicated host to host all these VM SKUs.

Depending on the size of the dedicated host you select, you can set up different VMs, taking into account the total compute capacity available. Figure 1-38 shows how you can use 31 E2ds v4 VMs, 15 E4ds v4 VMs, or 7 E8ds v4 VMs on an Edsv4-Type1 host. Alternatively, as shown in Figure 1-39, you can use a combination of different types of VMs. (Note that this is not an exhaustive list of combinations, but rather an indicative sample set.)

Dedicated host walkthrough

The following sections step you through the process of setting up a dedicated host and adding a VM to it using the Azure Portal, Azure PowerShell, and Azure CLI.

#Define variables
$rg = "RG01"
$location = "East US"
$vnet = "vNet-01"
$HostGrpName = "HostGroup"
$Dhostname = "DHost-01"
$vm = "VM01"
#Create Host Group
New-AzHostGroup `
   -Location $location `
   -Name $HostGrpName `
   -PlatformFaultDomain 2 `
   -ResourceGroupName $rg `
   -Zone 1
#Create Dedicated Host
New-AzHost `
   -HostGroupName $hostGrpName `
   -Location $location `
    -Name $Dhostname `
   -ResourceGroupName $rg `
   -Sku ESv3-Type1 `
   -AutoReplaceOnFailure 1 `
   -PlatformFaultDomain 1
#Define Credentials
$cred = Get-Credential
#Create VM in Dedicated Host
New-AzVM `
   -Credential $cred `
   -ResourceGroupName $rg `
   -Location $location `
   -Name $vm `
   -HostId $dhost.Id `
   -Size Standard_E2s_v3 `
   -Image Win2019Datacenter `
   -Zone 1

#Define variables
rg="RG01"
location="EastUS2"
vnet="vNet-01"
hostgrpname="HostGroup"
dhostname="DHost-01"
vm="VM01"
#Create Host Group
az vm host group create 
   --name $hostgrpname 
   --resource-group $rg 
   --location $location 
   --zone 1 
   --automatic-placement true 
   --platform-fault-domain-count 1
#Create Dedicated Host
az vm host create 
   --host-group $hostgrpname 
   --name $dhostname 
   --sku ESv3-Type1 
   --location $location 
   -g $rg
#Create VM in Dedicated Host
az vm create 
   -n $vm 
   --image Win2019Datacenter 
   --host-group $hostgrpname 
   --size Standard_E2s_v3 
   --location $location 
   -g $rg 
   --zone 1

Backup

It is highly recommended that you have a backup solution in place for every production VM—either Azure Backup or a third-party solution that supports integration with Azure. Regardless of what tool you use, a detailed backup strategy is critical to recovery in the event of data corruption or a malicious attack. This strategy should include monitoring backups on a regular basis and immediately fixing any backup issues. You should also test the restoration of VM backups in isolated networks to validate that the data restores correctly and adheres to the compliance requirements of the organization.

If you are using Azure Backup, you can store VM backups redundantly across multiple geographies. This is highly recommended, as it allows you to restore data in an alternate region in case of regional failure—especially important if you have no disaster-recovery solution.

Although backing up production VMs is strongly recommended, for dev/test VMs, it might be optional, depending on the data stored on the VMs and DevOps processes in place. If cost is not a restricting factor, then consider keeping backups for the dev/test environment, but with a lower retention level than for production VMs.

Azure uses Recovery Services vaults to create, store, and manage backups. Each vault can contain backup policies and configuration for thousands of VMs and other Azure workloads that are supported for backup. You can create a vault on your own. Alternatively, enabling Azure Backup for a VM will set one up for you automatically.

Backup walkthrough

The following section steps you through the process of setting up Azure Backup for a VM during VM creation using the Azure Portal.

Disaster recovery

A regional failure will result in all Azure VMs being unavailable until Microsoft recovers the region and brings all the workloads back online. If such an outage is not acceptable for your organization, you need to develop a disaster-recovery strategy for all production VMs (and optionally for dev/test VMs).

Azure Site Recovery natively integrates with Azure VMs to implement disaster recovery in a secondary Azure region of your choice. The service seamlessly manages replication, usually resulting in a very low recovery time objective (RTO). Azure Site Recovery also supports the creation of a recovery plan that can help automate the entire disaster-recovery process.

If Azure Site Recovery is not ideal for your environment, you can use a third-party solution that supports Azure VMs instead. Regardless of which solution you use, be sure you document the entire disaster-recovery process and test it on a regular basis to ensure your environment comes online in the secondary site per your recovery point objective (RPO) requirements.

Site recovery walkthrough

The following section steps you through the process of setting up Azure Site Recovery during VM creation using the Azure Portal.