Azure Essential

ARM or Azure Resource Manager quick view

Resource Manager request model


If you’re new to Azure Resource Manager, there are some terms you might not be familiar with.

  • resource – A manageable item that is available through Azure. Virtual machines, storage accounts, web apps, databases, and virtual networks are examples of resources.
  • resource group – A container that holds related resources for an Azure solution. The resource group includes those resources that you want to manage as a group. You decide which resources belong in a resource group based on what makes the most sense for your organization. See Resource groups.
  • resource provider – A service that supplies Azure resources. For example, a common resource provider is Microsoft. Compute, which supplies the virtual machine resource. Microsoft. Storage is another common resource provider. See Resource providers and types.
  • Resource Manager template – A JavaScript Object Notation (JSON) file that defines one or more resources to deploy to a resource group or subscription. The template can be used to deploy the resources consistently and repeatedly. See the Template deployment overview.
  • declarative syntax – Syntax that lets you state “Here is what I intend to create” without having to write the sequence of programming commands to create it. The Resource Manager template is an example of the declarative syntax. In the file, you define the properties for the infrastructure to deploy to Azure. See Template deployment overview.

hierarchy of Management Group, Subscription, and Resource group


Availability Zone

Availability zones expand the level of control you have to maintain the availability of the applications and data on your VMs. An Availability Zone is a physically separate zone, within an Azure region. There are three Availability Zones per supported Azure region.

Each Availability Zone has a distinct power source, network, and cooling. By architecting your solutions to use replicated VMs in zones, you can protect your apps and data from the loss of a datacenter. If one zone is compromised, then replicated apps and data are instantly available in another zone.

Availability zones

Fault Domain, Update Domain

A fault domain is a logical group of the underlying hardware that shares a common power source and network switch, similar to a rack within an on-premises datacenter.

Update domains

An update domain is a logical group of the underlying hardware that can undergo maintenance or be rebooted at the same time.

This approach ensures that at least one instance of your application always remains running as the Azure platform undergoes periodic maintenance. The order of update domains being rebooted may not proceed sequentially during maintenance, but only one update domain is rebooted at a time.

Availability sets

An availability set is a logical grouping of VMs within a datacenter that allows Azure to understand how your application is built to provide for redundancy and availability. We recommended that two or more VMs are created within an availability set to provide for a highly available application and to meet the 99.95% Azure SLA. There is no cost for the Availability Set itself, you only pay for each VM instance that you create. When a single VM is using Azure premium SSDs, the Azure SLA applies for unplanned maintenance events.

In an availability set, VMs are automatically distributed across these fault domains. This approach limits the impact of potential physical hardware failures, network outages, or power interruptions.

For VMs using Azure Managed Disks, VMs are aligned with managed disk fault domains when using a managed availability set. This alignment ensures that all the managed disks attached to a VM are within the same managed disk fault domain.

Only VMs with managed disks can be created in a managed availability set. The number of managed disk fault domains varies by region – either two or three managed disk fault domains per region. You can read more about these managed disk fault domains for Linux VMs or Windows VMs.

Managed availability set


VMs within an availability set are also automatically distributed across update domains.

Availability sets

Deploy a Simple VM using Azure CLI, PowerShell, and ARM Template

Azure Cli

# Create Resoruce Group
az group create -l eastus -n myResourceGroup
# Create VM
az vm create \
    --resource-group myResourceGroup \
    --name myVM \
    --image win2016datacenter \
    --admin-username azureuser \
    --admin-password myPassword123
#Open Port for RDP
az vm open-port --port 3389 --resource-group myResourceGroup --name myVM
#Delete Resource Group 
#az group delete --name myResourceGroup


#Create Resource Group
New-AzResourceGroup -Name myResourceGroup -Location EastUS

# Create VM, It will prompt you for user and password
New-AzVm `
    -ResourceGroupName "myResourceGroup" `
    -Name "myVM" `
    -Location "East US" `
    -VirtualNetworkName "myVnet" `
    -SubnetName "mySubnet" `
    -SecurityGroupName "myNetworkSecurityGroup" `
    -PublicIpAddressName "myPublicIpAddress" `
    -OpenPorts 80, 3389

Get-AzPublicIpAddress -ResourceGroupName "myResourceGroup" | Select "IpAddress"
#Delete Resource Group 
#Remove-AzResourceGroup -Name myResourceGroup

ARM Template

Template File

  "$schema": "",
  "contentVersion": "",
  "parameters": {
    "adminUsername": {
      "type": "string",
      "metadata": {
        "description": "Username for the Virtual Machine."
    "adminPassword": {
      "type": "securestring",
      "metadata": {
        "description": "Password for the Virtual Machine."
    "dnsLabelPrefix": {
      "type": "string",
      "metadata": {
        "description": "Unique DNS Name for the Public IP used to access the Virtual Machine."
    "windowsOSVersion": {
      "type": "string",
      "defaultValue": "2016-Datacenter",
      "allowedValues": [
      "metadata": {
        "description": "The Windows version for the VM. This will pick a fully patched image of this given Windows version."
    "vmSize": {
      "type": "string",
      "defaultValue": "Standard_A2_v2",
      "metadata": {
        "description": "Size of the virtual machine."
    "location": {
      "type": "string",
      "defaultValue": "[resourceGroup().location]",
      "metadata": {
        "description": "Location for all resources."
  "variables": {
    "storageAccountName": "[concat(uniquestring(resourceGroup().id), 'sawinvm')]",
    "nicName": "myVMNic",
    "addressPrefix": "",
    "subnetName": "Subnet",
    "subnetPrefix": "",
    "publicIPAddressName": "myPublicIP",
    "vmName": "SimpleWinVM",
    "virtualNetworkName": "MyVNET",
    "subnetRef": "[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('virtualNetworkName'), variables('subnetName'))]",
    "networkSecurityGroupName": "default-NSG"
  "resources": [
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2018-11-01",
      "name": "[variables('storageAccountName')]",
      "location": "[parameters('location')]",
      "sku": {
        "name": "Standard_LRS"
      "kind": "Storage",
      "properties": {}
      "type": "Microsoft.Network/publicIPAddresses",
      "apiVersion": "2018-11-01",
      "name": "[variables('publicIPAddressName')]",
      "location": "[parameters('location')]",
      "properties": {
        "publicIPAllocationMethod": "Dynamic",
        "dnsSettings": {
          "domainNameLabel": "[parameters('dnsLabelPrefix')]"
      "comments":  "Default Network Security Group for template",
      "type":  "Microsoft.Network/networkSecurityGroups",
      "apiVersion":  "2019-08-01",
      "name":  "[variables('networkSecurityGroupName')]",
      "location":  "[parameters('location')]",
      "properties": {
        "securityRules": [
            "name":  "default-allow-3389",
            "properties": {
              "priority":  1000,
              "access":  "Allow",
              "direction":  "Inbound",
              "destinationPortRange":  "3389",
              "protocol":  "Tcp",
              "sourcePortRange":  "*",
              "sourceAddressPrefix":  "*",
              "destinationAddressPrefix":  "*"
      "type": "Microsoft.Network/virtualNetworks",
      "apiVersion": "2018-11-01",
      "name": "[variables('virtualNetworkName')]",
      "location": "[parameters('location')]",
      "dependsOn": [
        "[resourceId('Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName'))]"
      "properties": {
        "addressSpace": {
          "addressPrefixes": [
        "subnets": [
            "name": "[variables('subnetName')]",
            "properties": {
              "addressPrefix": "[variables('subnetPrefix')]",
              "networkSecurityGroup": {
                "id": "[resourceId('Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName'))]"
      "type": "Microsoft.Network/networkInterfaces",
      "apiVersion": "2018-11-01",
      "name": "[variables('nicName')]",
      "location": "[parameters('location')]",
      "dependsOn": [
        "[resourceId('Microsoft.Network/publicIPAddresses/', variables('publicIPAddressName'))]",
        "[resourceId('Microsoft.Network/virtualNetworks/', variables('virtualNetworkName'))]"
      "properties": {
        "ipConfigurations": [
            "name": "ipconfig1",
            "properties": {
              "privateIPAllocationMethod": "Dynamic",
              "publicIPAddress": {
                "id": "[resourceId('Microsoft.Network/publicIPAddresses',variables('publicIPAddressName'))]"
              "subnet": {
                "id": "[variables('subnetRef')]"
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2018-10-01",
      "name": "[variables('vmName')]",
      "location": "[parameters('location')]",
      "dependsOn": [
        "[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
        "[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
      "properties": {
        "hardwareProfile": {
          "vmSize": "[parameters('vmSize')]"
        "osProfile": {
          "computerName": "[variables('vmName')]",
          "adminUsername": "[parameters('adminUsername')]",
          "adminPassword": "[parameters('adminPassword')]"
        "storageProfile": {
          "imageReference": {
            "publisher": "MicrosoftWindowsServer",
            "offer": "WindowsServer",
            "sku": "[parameters('windowsOSVersion')]",
            "version": "latest"
          "osDisk": {
            "createOption": "FromImage"
          "dataDisks": [
              "diskSizeGB": 1023,
              "lun": 0,
              "createOption": "Empty"
        "networkProfile": {
          "networkInterfaces": [
              "id": "[resourceId('Microsoft.Network/networkInterfaces',variables('nicName'))]"
        "diagnosticsProfile": {
          "bootDiagnostics": {
            "enabled": true,
            "storageUri": "[reference(resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))).primaryEndpoints.blob]"
  "outputs": {
    "hostname": {
      "type": "string",
      "value": "[reference(variables('publicIPAddressName')).dnsSettings.fqdn]"


  "$schema": "",
  "contentVersion": "",
  "parameters": {
    "adminUsername": {
      "value": "UserName"
    "adminPassword": {
      "value": "123Password"
    "dnsLabelPrefix": {
      "value": "dnsprefix123"

Master Deployment Script that uses Template and Parameter

$CurrentFolder = Split-Path $script:MyInvocation.MyCommand.Path

# Name of exisitng resource group you want to deploy in it
$ResourceGroup = "myResourceGroup"
$ArmTemplateFilePath = $CurrentFolder + "\azuredeploy.json"
$ParameterFilePath = $CurrentFolder + "\azuredeploy.parameters.json"

Test-AzResourceGroupDeployment -ResourceGroupName $ResourceGroup -TemplateFile $ArmTemplateFilePath -TemplateParameterFile $ParameterFilePath -Verbose 

New-AzResourceGroupDeployment -Name ("VM_" + (Get-Date -UFormat %Y%m%d)) -ResourceGroupName $ResourceGroup -TemplateFile $ArmTemplateFilePath -TemplateParameterFile $ParameterFilePath -Verbose

Disks in Azure

Sounds easy but the same as computing that has a huge demand, Disks are very important and the better disks have tremendous demand. Not only from their size but also for some other factors like Speed of disk! scaling out is not always the consequence of computing limitation and sometimes is the effect of storage limitation

We have options(base on region and VM SKU) for Standard HDD, Standard SSD, Premium SSD, Ultra Disk and Shared Disk!



IOPS, or Input/output Operations Per Second, is the number of requests that your application is sending to the storage disks in one second. An input/output operation could be read or write, sequential, or random. Online Transaction Processing (OLTP) applications like an online retail website need to process many concurrent user requests immediately. The user requests are insert and update intensive database transactions, which the application must process quickly. Therefore, OLTP applications require very high IOPS. Such applications handle millions of small and random IO requests.

IO requests

An IO request is a unit of input/output operation that your application will be performing. Identifying the nature of IO requests, random or sequential, read or write, small or large, will help you determine the performance requirements of your application.

If you are using an application, which does not allow you to change the IO size, use the guidelines in this article to optimize the performance KPI that is most relevant to your application. For example,

  • An OLTP application generates millions of small and random IO requests. To handle these types of IO requests, you must design your application infrastructure to get higher IOPS.
  • A data warehousing application generates large and sequential IO requests. To handle these types of IO requests, you must design your application infrastructure to get higher Bandwidth or Throughput.

If you are using an application, which allows you to change the IO size, use this rule of thumb for the IO size in addition to other performance guidelines,

  • Smaller IO size to get higher IOPS. For example, 8 KB for an OLTP application.
  • Larger IO size to get higher Bandwidth/Throughput. For example, 1024 KB for a data warehouse application.

Throughput = IOPS * IO Size

It is often stated by MB/s and it has a limit (maximum) on both disk and VM

Throughput, or bandwidth is the amount of data that your application is sending to the storage disks in a specified interval. If your application is performing input/output operations with large IO unit sizes, it requires high throughput. Data warehouse applications tend to issue scan intensive operations that access large portions of data at a time and commonly perform bulk operations.

Application Requirement I/O size IOPS Throughput/Bandwidth
Max IOPS 8 KB 5,000 40 MB per second


Latency is the time it takes an application to receive a single request, send it to the storage disks and send the response to the client.

Premium Disks are designed to provide single-digit millisecond latencies for most IO operations. If you enable ReadOnly host caching on premium storage disks, you can get much lower read latency

Performance factors: IOPS, throughput, and latency at a glance

  IOPS Throughput Latency
IO size Smaller IO size yields higher IOPS. Larger IO size to yields higher Throughput.  
VM size Use a VM size that offers IOPS greater than your application requirement. Use a VM size with throughput limit greater than your application requirement. Use a VM size that offers scale limits greater than your application requirement.
Disk size Use a disk size that offers IOPS greater than your application requirement. Use a disk size with Throughput limit greater than your application requirement. Use a disk size that offers scale limits greater than your application requirement.
VM and Disk Scale Limits IOPS limit of the VM size chosen should be greater than total IOPS driven by storage disks attached to it. Throughput limit of the VM size chosen should be greater than total Throughput driven by premium storage disks attached to it. Scale limits of the VM size chosen must be greater than total scale limits of attached premium storage disks.
Disk Caching Enable ReadOnly Cache on premium storage disks with Read heavy operations to get higher Read IOPS.   Enable ReadOnly Cache on premium storage disks with Ready heavy operations to get very low Read latencies.
Disk Striping Use multiple disks and stripe them together to get a combined higher IOPS and Throughput limit. The combined limit per VM should be higher than the combined limits of attached premium disks.    
Stripe Size Smaller stripe size for random small IO pattern seen in OLTP applications. For example, use stripe size of 64 KB for SQL Server OLTP application. Larger stripe size for sequential large IO pattern seen in Data Warehouse applications. For example, use 256 KB stripe size for SQL Server Data warehouse application.  
Multithreading Use multithreading to push higher number of requests to Premium Storage that will lead to higher IOPS and Throughput. For example, on SQL Server set a high MAXDOP value to allocate more CPUs to SQL Server.    
Queue Depth Larger Queue Depth yields higher IOPS. Larger Queue Depth yields higher Throughput. Smaller Queue Depth yields lower latencies.

Disk caching

Caching is available for the Premium Storage. Disk Caching is not supported for disks 4 TiB and larger.

By default, the cache setting is set to Read/Write for OS disks and ReadOnly for data disks hosted on Premium Storage.

recommended disk cache settings for data disks,

Disk caching setting recommendation on when to use this setting
None Configure host-cache as None for write-only and write-heavy disks.
ReadOnly Configure host-cache as ReadOnly for read-only and read-write disks.
ReadWrite Configure host-cache as ReadWrite only if your application properly handles writing cached data to persistent disks when needed.

ReadOnly, you can achieve low Read latency and get very high Read IOPS and Throughput for your application.

ReadWrite, Using ReadWrite cache with an application that does not handle persisting the required data can lead to data loss, if the VM crashes

None, Currently, None is only supported on data disks. It is not supported on OS disks. If you set None on an OS disk it will override this internally and set it to ReadOnly.

Queue depth = IOPS * Latency

The queue depth or queue length or queue size is the number of pending IO requests in the system. The value of queue depth determines how many IO operations your application can line up, which the storage disks will be processing. It affects all the three application performance indicators that we discussed in this article viz., IOPS, throughput, and latency.

Standard HDD

Standard Disk TypeS4S6S10S15S20S30S40S50S60S70S80
Disk size in GiB32641282565121,0242,0484,0968,19216,38432,767
IOPS per diskUp to 500Up to 500Up to 500Up to 500Up to 500Up to 500Up to 500Up to 500Up to 1,300Up to 2,000Up to 2,000
Throughput per diskUp to 60 MiB/secUp to 60 MiB/secUp to 60 MiB/secUp to 60 MiB/secUp to 60 MiB/secUp to 60 MiB/secUp to 60 MiB/secUp to 60 MiB/secUp to 300 MiB/secUp to 500 MiB/secUp to 500 MiB/sec

Standard SSD

Standard SSD sizesE1E2E3E4E6E10E15E20E30E40E50E60E70E80
Disk size in GiB481632641282565121,0242,0484,0968,19216,38432,767
IOPS per diskUp to 120Up to 120Up to 120Up to 120Up to 240Up to 500Up to 500Up to 500Up to 500Up to 500Up to 500Up to 2,000Up to 4,000Up to 6,000
Throughput per diskUp to 25 MiB/secUp to 25 MiB/secUp to 25 MiB/secUp to 25 MiB/secUp to 50 MiB/secUp to 60 MiB/secUp to 60 MiB/secUp to 60 MiB/secUp to 60 MiB/secUp to 60 MiB/secUp to 60 MiB/secUp to 400 MiB/secUp to 600 MiB/secUp to 750 MiB/sec

Azure Premium Storage Disk

Premium SSD sizes  P1 P2 P3 P4 P6 P10 P15 P20 P30 P40 P50 P60 P70 P80
Disk size in GiB 4 8 16 32 64 128 256 512 1,024 2,048 4,096 8,192 16,384 32,767
IOPS per disk 120 120 120 120 240 500 1,100 2,300 5,000 7,500 7,500 16,000 18,000 20,000
Throughput per disk 25 MiB/sec 25 MiB/sec 25 MiB/sec 25 MiB/sec 50 MiB/sec 100 MiB/sec 125 MiB/sec 150 MiB/sec 200 MiB/sec 250 MiB/sec 250 MiB/sec 500 MiB/sec 750 MiB/sec 900 MiB/sec
Max burst IOPS per disk** 3,500 3,500 3,500 3,500 3,500 3,500 3,500 3,500            
Max burst throughput per disk** 170 MiB/sec 170 MiB/sec 170 MiB/sec 170 MiB/sec 170 MiB/sec 170 MiB/sec 170 MiB/sec 170 MiB/sec            
Max burst duration** 30 min 30 min 30 min 30 min 30 min 30 min 30 min 30 min            
Eligible for reservation No No No No No No No No Yes, up to one year Yes, up to one year Yes, up to one year Yes, up to one year Yes, up to one year Yes, up to one year

Ultra Disk

The most recent type of disks with granular IOPS

Disk Size (GiB)IOPS CapThroughput Cap (MBps)
1,024-65,536 (sizes in this range increasing in increments of 1 TiB) Max 64 TiB160,0002,000

Bursting Disk

Premium SSD sizes smaller than P30 now offer disk bursting (preview) and can burst their IOPS per disk up to 3,500 and their bandwidth up to 170 Mbps. Bursting is automated and operates based on a credit system. Credits are automatically accumulated in a burst bucket when disk traffic is below the provisioned performance target and credits are automatically consumed when traffic bursts beyond the target, up to the max burst limit.

Disk Comparison

Ultra diskPremium SSDStandard SSDStandard HDD
ScenarioIO-intensive workloads such as SAP HANA, top tier databases (for example, SQL, Oracle), and other transaction-heavy workloads.Production and performance sensitive workloadsWeb servers, lightly used enterprise applications and dev/testBackup, non-critical, infrequent access
Max disk size65,536 gibibyte (GiB)32,767 GiB32,767 GiB32,767 GiB
Max throughput2,000 MiB/s900 MiB/s750 MiB/s500 MiB/s
Max IOPS160,00020,0006,0002,000

Reserve a disk!

Save on your premium solid-state drive (SSD) usage with reserved capacity, combined with Reserved Virtual Machine Instances you can decrease your total VM costs. The reservation discount is applied automatically to the matching disks in the selected reservation scope, you don’t need to assign a reservation to a Managed disk to get the discounts. Discounts are applied hourly on the disk usage and any unused reserved capacity does not carry over. Managed disk reservation discount does not apply to unmanaged disks, ultra disks, or page blob consumption.

Reservation discounts are not currently available for the following disks:

  • Unmanaged disks/page blobs
  • Standard SSD or standard HDD

Shared Disks

VMs in the cluster can read or write to your attached disk based on the reservation chosen by the clustered application using SCSI Persistent Reservations (SCSI PR). SCSI PR is a well-known industry standard leveraged by applications running on Storage Area Network (SAN) on-premises. Only available with premium SSDs. As of Feb 2020 only supported in the West Central US region. All virtual machines sharing a disk must be deployed in the same proximity placement groups. Can only be enabled on data disks, not OS disks

Two node cluster. An application running on the cluster is handling access to the disk

Sample workloads:

  • SQL Server Failover Cluster Instances (FCI)
  • Scale-out File Server (SoFS)
  • File Server for General Use (IW workload)
  • Remote Desktop Server User Profile Disk (RDS UPD)

Ephemeral Disk

Ephemeral OS disks are created on the local virtual machine (VM) storage and not saved to the remote Azure Storage. Ephemeral OS disks work well for stateless workloads, where applications are tolerant of individual VM failures, but are more affected by VM deployment time or reimaging the individual VM instances. With Ephemeral OS disk, you get lower read/write latency to the OS disk and faster VM reimage.

The key features of ephemeral disks are:

  • Ideal for stateless applications.
  • They can be used with both Marketplace and custom images.
  • Ability to fast reset or reimage VMs and scale set instances to the original boot state.
  • Lower latency, similar to a temporary disk.
  • Ephemeral OS disks are free, you incur no storage cost for OS disk.
  • They are available in all Azure regions.
  • Ephemeral OS Disk is supported by Shared Image Gallery.

Key differences between persistent and ephemeral OS disks:

Persistent OS DiskEphemeral OS Disk
Size limit for OS disk2 TiBCache size for the VM size or 2TiB, whichever is smaller. For the cache size in GiB, see DS, ES, M, FS, and GS
VM sizes supportedAllDSv1, DSv2, DSv3, Esv3, Fs, FsV2, GS, M
Disk type supportManaged and unmanaged OS diskManaged OS disk only
Region supportAll regionsAll regions
Data persistenceOS disk data written to OS disk are stored in Azure StorageData written to OS disk is stored to the local VM storage and is not persisted to Azure Storage.
Stop-deallocated stateVMs and scale set instances can be stop-deallocated and restarted from the stop-deallocated stateVMs and scale set instances cannot be stop-deallocated
Specialized OS disk supportYesNo
OS disk resizeSupported during VM creation and after VM is stop-deallocatedSupported during VM creation only
Resizing to a new VM sizeOS disk data is preservedData on the OS disk is deleted, OS is re-provisioned

Disk Disaster Recovery

ScenarioAutomatic replicationDR solution
Premium SSD disksLocal (locally redundant storage)Azure Backup
Managed disksLocal (locally redundant storage)Azure Backup
Unmanaged locally redundant storage disksLocal (locally redundant storage)Azure Backup
Unmanaged geo-redundant storage disksCross region (geo-redundant storage)Azure Backup
Consistent snapshots
Unmanaged read-access geo-redundant storage disksCross region (read-access geo-redundant storage)Azure Backup
Consistent snapshots

Disk Encryption

Azure Virtual Machine SKU(Size)

Challenging part of finding the best VM type and size for your workload. The good news is you can change it later! but it needs to turn off your VM for changing it.

Azure has various types of VM’s; keep in mind a 2 core VM is not necessarily comparable to another 2 core VM with same amount of memory.

General Purpose (Balanced CPU-to-memory ratio)
B, D, DS, A, DC

Compute Optimized (High CPU-to-memory ratio)

Memory Optimized  (High memory-to-CPU ratio)
E, M, DS, D, GS

Storage Optimized (High disk throughput and IO)

GPU Optimized (Graphic Rendering)

High Performance Compute (HPC) (Fast CPU with RDMA network)

Confidential Compute (Enabled Trusted Execution Environment)


Azure Compute Unit (ACU) provides a way of comparing compute (CPU) performance across Azure SKUs. ACU is currently standardized on a Small (Standard_A1) VM being 100 and all other SKUs then represent approximately how much faster that SKU can run a standard benchmark.

SKU Family ACU \ vCPU vCPU: Core
A0 50 1:1
A1 – A4 100 1:1
A5 – A7 100 1:1
A1_v2 – A8_v2 100 1:1
A2m_v2 – A8m_v2 100 1:1
A8 – A11 225 1:1
D1 – D14 160 – 250 1:1
D1_v2 – D15_v2 210 – 250 1:1
DS1 – DS14 160 – 250 1:1
DS1_v2 – DS15_v2 210 – 250 1:1
D_v3 160 – 190 2:1
Ds_v3 160 – 190 2:1
E_v3 160 – 190 2:1
Es_v3 160 – 190 2:1
F2s_v2 – F72s_v2 195 – 210 2:1
F1 – F16 210 – 250 1:1
F1s – F16s 210 – 250 1:1
G1 – G5 180 – 240 1:1
GS1 – GS5 180 – 240 1:1
H 290 – 300 1:1
HB 199 – 216 1:1
HC 297 – 315 1:1
L4s – L32s 180 – 240 1:1
L8s_v2 – L80s_v2 150 – 175 2:1
M 160 – 180 2:1


Azure VM lifecycle

Power State Description
Starting The virtual machine is being started.
Running The virtual machine is running.
Stopping The virtual machine is being stopped.
Stopped The VM is stopped. Virtual machines in the stopped state still incur compute charges.
Deallocating The VM is being deallocated.
Deallocated This indicates that the VM is removed from the hypervisor but is still available in the control plane. Virtual machines in the Deallocated state do not incur compute charges.
The power state of the VM is unknown.

The Deallocated state doesn’t incur a charge as well as a transitional state of starting and deallocating. Some Azure resources, such as Disks and Networking, incur charges. Software licenses on the instance do not incur charges

VM power state diagram

Azure Virtual Machine

What is Azure VM?

Computers’ main job is computing! The major load of computing in the Cloud is on IaaS other than PaaS. The core workers are Virtual Machines.

Int net 
: Name resolution 
Aue O W 
Virtual network 
Data 2 
Physical SSD 
on host 

Perquisites for Azure VM

For having a VM in Azure we need Resource Group, VNet, Subnet, and NSG for accessing the VM from Internet

In a greenfield environment, You can create all the above perquisites during VM creation a.k.a as deployment.

Questions to ask yourself before creating a VM

  • The primary decision for having a simple deployment would be which region?
  • Which SKU (Size) is best for us? What image (OS)?
  • Can you use your Windows License?
  • Do you need special availability like Availability Set and Availability Zone?
  • Can we use Azure Spot?
  • Which protocol and ports need to be initially published on the internet?
  • Do you need a fast SSD Disk or typical HDD is enough?
  • Do we need Data Disk?
  • Do we need Accelerated Networking?
  • Should we use a storage account to save boot diagnostic?
  • Should we keep OS guest diagnostic?
  • Do we need Backup?
  • Do we need a Dedicated host?
  • Do we need to use the proximity placement group?
  • Gen 1 or Gen 2?
  • For Linux VM, should we use a password or SSH key and how to generate one?
  • What extensions are available?
  • Should we start using Reserved Instances?

We will try to find answers to the mentioned questions. Sometimes it would be a matter of knowing the concept or maybe a practical conversation. Ther e is a chance we might deep dive into limitation or dependency between moving pieces.