Azure VM SKU Architecture

What is Azure VM SKU?

An Azure VM SKU is a Predefined Virtual Hardware Configuration that specifies the VM’s Compute Resources and Capability Limits, including vCPUs, Memory, Storage, Networking, and Supported Platform Features.

Customers cannot alter the resources defined by a SKU; they can select a different SKU that meets their resource and workload requirements.

Azure does not expose a Virtual Server as Individually Configurable CPU, Memory, Networking, and Host-Hardware Components. Instead, Microsoft exposes predefined VM Sizes (SKUs) built within VM families and Size Series.

Azure VM Sizing is not the same as On-Premises VM Sizing

With traditional On-Premises Virtualization, Administrators commonly think of Virtual Hardware as Independently Configurable Resources.

For Example, an Administrator might create a VM with: 4 vCPUs + 8 GiB RAM

Later, if the Application requires Additional Memory, the Administrator may change the VM Configuration to 4 vCPUs + 16 GiB RAM

The Hypervisor allows the Administrator to modify the amount of Memory Assigned to that VM, assuming sufficient Host Resources and applicable Platform/Guest OS requirements.

Azure Virtual Machines work differently.

Azure does not allow you to independently select arbitrary amounts of vCPU and Memory for a VM. Instead, Microsoft provides predefined VM sizes/SKUs, and each SKU defines a particular Resource Configuration and Capability Envelope.

For Example:

Example: You Cannot Simply “Add Another 8 GiB”

Suppose you deploy an Azure VM using a SKU providing: 2 vCPUs + 8 GiB RAM

Six months later, the application needs 16 GiB RAM.

The Azure design decision is not: “Edit the VM and add another 8 GiB of RAM.”

Instead, it is:

Find another Azure VM SKU that provides the required Memory, CPU, Storage, Networking, and Feature Capabilities, and Resize the VM to that SKU. The Resize requires a VM Restart. If the target SKU is not available on the VM’s current Hardware Cluster, the VM must be Stopped and Deallocated before it can be resized.

That distinction becomes especially important because moving to another SKU can change more than Memory. Depending on the Source and Destination Sizes, the new SKU can have different vCPU Counts, Temporary Storage, Maximum Data-Disk Counts, Network Bandwidth, NIC Limits, Premium Storage Support, Accelerated Networking Capabilities, Processor Architecture/Generation, and other Characteristics.

Treating Azure VM CPU and Memory like On-Premises Hypervisor CPU and Memory can turn a simple Capacity Requirement into an Unplanned Production Outage. Additional Memory requires selecting another VM SKU and Resizing the VM, which introduces VM Interruption and may require Deallocation, Change-Management approval, and a maintenance window.

The Key Design Principle

On-Premises:
Physical Host Capacity → Hypervisor → Administrator Allocates Resources → VM

Azure:
Microsoft Datacenter Capacity → Azure Region → Available VM Families/Series/SKUs → Administrator selects SKU → VM

In Azure, you do not build a VM by independently assembling CPU and RAM resources. You select a predefined VM SKU whose Resource Configuration and Capabilities Satisfy the Workload Requirements.

Therefore, Azure architects should size for both current requirements and expected growth.

If you know an application has 8 GiB today but is likely to require 16 GiB soon, the question shouldn't simply be “Can I add another 8 GiB later?”

The Planning Question Becomes:

“What SKU will I resize to when the workload outgrows this SKU, and is that target SKU available and compatible with my deployment?”

How Azure VM SKU Architecture Works

The hierarchy can be thought of as:

Physical Azure Host Hardware
↓
VM Family — Workload/Hardware Class
↓
VM Size Series — Hardware Generation and Capability Set
↓
VM Size / SKU — Predefined Resource Configuration
↓
Your Azure VM

Microsoft's terminology matters here. A VM Family is the Broad Workload Category. A Size Series represents a particular Hardware/Capability Generation within that Family. The VM Size (SKU) is the Actual Selectable Configuration that determines resources such as Processing Power, Memory, Storage Capabilities, and Network Bandwidth.

For Example, the current DADSV7 Series provides Predefined Sizes:

Dadsv7 is a structured Azure VM-Series Name. You can break it down like this:

 So:

Dadsv7 = D-family + AMD CPU + Local Temporary Disk + Premium Storage Support + Generation 7

For an individual VM SKU, Microsoft then inserts the size/vCPU designation.

For Example: Standard_D8ads_v7

Can be read as:

Standard → Azure VM SKU prefix
D → General Purpose Family
8 → 8 vCPUs
a → AMD Processor
d → Local Temporary Disk
s → Premium Storage Capable
v7 → Seventh-Generation Series

So, there is an Important Distinction:

 Dadsv7 = VM Size Series

Standard_D8ads_v7 = specific VM Size/SKU within that Series

Those aren't merely convenient Microsoft Pricing Packages. They are defined as Virtual Hardware Profiles. The DADSV7 Series, for Example, specifies not only CPU and Memory but Local-Storage Limits, Remote-Disk Limits and throughput, NIC Limits, Network Bandwidth, supported Disk Types, and Network-Interface Technology.

Why you cannot simply add 8 GiB of RAM to an existing Azure VM SKU

Suppose you have:

Standard_D4ADS_v7 - 4 vCPU + 16 GiB RAM and you decide that the Server needs another 8 GiB.

In a Physical Server you might think: 16 GiB + 8 GiB = 24 GiB

Azure doesn't expose that Model to you.

You aren't managing DIMM slots on Microsoft's Physical Server. Your VM has been allocated the resources defined by Standard_D4ads_v7.

So, there isn't an Azure Operation equivalent to: Add 8 GiB RAM to this VM.

You instead select another available VM Size whose Predefined Resource Profile satisfies the requirement.

For Example:

D4ads_v7 → 4 vCPU / 16 GiB
↓ Resize
D8ads_v7 → 8 vCPU / 32 GiB

Notice an Important Consequence: you may want Only More Memory, but changing Size can simultaneously change CPU Count and other Limits because those Resources are Packaged Into predefined VM Sizes.

If you need a different CPU-to-Memory Ratio, you can instead select a Memory-Optimized Family/Series. For Example, Microsoft's E-Series offers substantially more Memory per vCPU; an E4s_v4 provides 4 vCPUs and 32 GiB RAM.

The Design goes far beyond CPU and RAM

A VM SKU can determine or constrain much more than these two resources:

This is why “VM Size” means considerably more than CPU + RAM. Microsoft's Naming Convention Itself Encodes Family, vCPU Count, additive capabilities, accelerator type in Applicable Specialized SKUs, Memory Capacity in applicable M-Series Sizes, and Generation/Version.

Why Microsoft Designed Azure this way

The Architecture provides Microsoft with a Standardized Abstraction between your VM and Microsoft's Physical Datacenter Hardware.

Your request:

Standard_D8ads_v7 rather than:

Give me eight CPU threads from this Exact Processor, Four Particular DIMMs, these Physical NIC Queues, and these Pcie Devices.

Azure's fabric/platform handles placement onto compatible physical infrastructure.

This abstraction is important because a series can sometimes run across more than one underlying Processor Generation or Hardware Implementation. Microsoft's A-Series Documentation, for Example, explicitly lists several possible Intel Xeon Processor Generations and says the Size is Controlled to provide consistent Processor Performance regardless of the underlying Hardware on which that instance is deployed.

So, distinction is:

The SKU defines the Resource and Capability contract presented to the Customer; it does not necessarily Identify one unique Physical Server Configuration underneath it. This is the most Important Architectural Concept.

What Happens When You Resize

When you request a different VM Size, Azure has to determine whether the Physical Cluster currently Hosting the VM can satisfy that new SKU.

Microsoft Documents Two Important Cases.

If the requested VM Size is available on the Current Hardware Cluster, Azure can Resize the Powered-On VM, although the VM is Restarted During the Operation.

If that Size isn't available on the Current Cluster, Azure requires the VM to be Deallocated before Resizing. That allows Azure to place the VM onto Infrastructure capable of providing the requested Size.

Conceptually:

Current Host/Cluster Supports Target SKU

Action:  VM → Resize → Restart → New SKU (In this case no deallocation is required)

                            versus:

Current Host/Cluster cannot Provide Target SKU

Action: VM → Deallocate → Azure Placement → Compatible Capacity → New SKU → Start

Deallocation always means the Azure VM is stopped. A running VM cannot be in the Deallocated State.

Azure Virtual Machines use a predefined VM Size (SKU) Architecture in which Compute, Memory, Storage, Networking, and Hardware-Dependent Capabilities are delivered through Standardized Virtual Hardware Profiles. VM Families and Size Series Group these Profiles according to Workload Characteristics, Hardware Architecture, Capabilities, and Generation. Administrators therefore do not independently add Physical-Style Resources such as RAM Modules or CPU Sockets to an Azure VM. When additional or different resources are required, the VM is Resized to a compatible SKU whose Predefined Resource and Capability Profile Satisfies the Workload Requirements. If the target SKU cannot be provided by the VM's current Hardware Cluster, Azure requires Deallocation (Deallocation means the VM is Turned Off) so the VM can be placed on compatible Infrastructure.

Azure VM SKU Families

Microsoft's documentation also distinguishes Previous-Generation Series from Current Generations; for example, older D/Ds/Dv2/Dv3, F/Fs/Fsv2, Ev3/Ev4, G/Gs, and Lsv1 Families are now listed separately as Previous-Generation Sizes.

How to Read an Azure VM SKU

Microsoft documents the naming structure as Family + Subfamily + vCPU Count + Optional Capabilities + Version.

An Azure VM SKU is not simply a Pricing Label. It identifies a predefined Virtual Hardware Configuration and Capability Envelope. Changing RAM, vCPU capacity, GPU capabilities, local storage characteristics, or certain networking capabilities therefore requires selecting a VM SKU that provides the required configuration.

One important distinction is: “available Azure VM SKUs” is Region-Specific. There isn't one Static List of individual Standard_* SKUs that is deployable everywhere. Series Availability varies by Region, Zone, Subscription Restrictions, and Capacity. Microsoft Specifically recommends Confirming the Target Size in the Intended Region.

Microsoft's newer Azure VM Series Generations, such as v6 and v7, are comparable to an Organization Refreshing Physical Servers in its own Datacenter. In an On-Premises Environment, the Organization Purchases, Installs, Configures, Maintains, and Eventually Replaces the Physical Server Hardware. In Azure, Microsoft performs that infrastructure Lifecycle Management. Customers consume the Newer Hardware and Platform Capabilities through newer Azure VM SKUs and pay Microsoft for the Compute Resources they use.

Summary: Azure VM Sizing vs. On-Premises Hypervisor Sizing

One of the most important differences to understand when moving from an On-Premises Hypervisor to Azure Virtual Machines is how Virtual Hardware Resources are managed.

With an On-Premises Hypervisor, Administrators control the Virtual Hardware Configuration. If a VM has 8 GiB of RAM and later requires 16 GiB, the Administrator can modify the VM configuration and allocate additional Memory. The same principle applies to Virtual CPUs, subject to the capabilities and Available Resources of the Hypervisor and Physical Host.

Azure uses a Different Design.

Azure does not allow Administrators to independently add RAM or vCPUs to an existing VM Size. Instead, Microsoft provides predefined VM Sizes (SKUs). Each SKU defines a Specific Combination of Resources and Capabilities, including vCPUs, Memory, Disk Limits, Storage Performance, Network Performance, NIC Limits, and supported Hardware-Dependent Features.

Therefore, the Azure approach is not:

8 GiB RAM → Add another 8 GiB RAM → 16 GiB RAM

Instead, it is:

Current VM SKU → Identify a SKU with the required resources → Resize the VM to the new SKU

Administrators manage the selection of the Virtual Hardware Profile, not the Individual Underlying Hardware Components.

The Fundamental Differences are:

On-Premises Virtualization allows Administrators to modify individual Virtual Hardware Resources such as RAM and CPU. Azure abstracts those Resources into predefined VM SKUs. When an Azure VM requires additional CPU or Memory, the Administrator selects and Resizes the VM to another SKU that provides the required resource configuration rather than adding CPU or RAM individually.

If the VM is part of a Virtual Machine Scale Set (VMSS), additional capacity does not necessarily require resizing the existing VM to a larger SKU. The workload can instead Scale Horizontally by adding additional VM instances using the configured VM size.

This distinction should be clearly understood before designing and sizing Azure VMs. Administrators coming from VMware, Hyper-V, or other On-Premises Hypervisors should not expect an “Add Hardware” model where CPU and Memory can be independently increased. In Azure, Compute Resources are defined by the selected VM SKU; when additional CPU or Memory is required, the VM must be Resized to a supported SKU that provides the required Resource Configuration.

Found this Article Useful? 😊
If this Article saved you an hour of Troubleshooting, a few minutes of searching, or one Microsoft documentation Rabbit Hole, consider turning some of that saved time into a Coffee. ☕ Your support helps keep new Technical Guides coming.