Azure VM sizes and storage.
Now, before the days of virtualization,
it could be quite a pain to upgrade hardware on your hardware hosts.
And frankly, I know even in 2022 that can be a pain,
but virtualization helps because we can go through the pains of
hardware upgrade once on our Hyper‑V host,
and then adjust the CPU storage, network,
and memory on those VMs pretty dynamically.
Well, we can do the same thing in Azure, but it operates a bit differently.
The Azure VM image library is actually sized,
that is,
we have different balances between CPU memory and then other
properties that come into Azure VM sizes are the maximum
number of data disks you can have, the input‑output operations per second,
whether you can do premium storage, what kind of temp storage you have,
how much solid‑state temp storage you get,
whether or not the Azure VM can support features like nested virtualization.
These are all rolled into Azure VM sizes.
And there's also a relative performance metric that Microsoft uses
for VMs in Azure called the Azure Compute Unit.
You can check the exercise files if you want to read more details on it,
but, of course,
we're never going to get within miles or kilometers of an Azure data center,
and you're not going to know exactly from VM to VM,
what the host's hardware configuration is.
So to counteract that, Microsoft has a series of standardized measurement units.
And again, the one that's used with VMs is ACU.
The more ACUs, the more expensive per minute it will cost to run that Azure VM,
but you'll get more performance.
The Azure VM sizes are divided into types,
and these all represent different balancings between vCPU,
RAM, and so on.
General‑purpose is truly balanced between CPU and memory,
compute is skewed towards processor, memory is skewed towards memory,
there's storage optimized for data‑intensive workloads,
graphical processor unit weighted sizes for if you're doing
video rendering and that kind of stuff,
and there's a high‑performance compute for super high speed,
high priority processing.
You'll also see that these Azure VM sizes are versioned.
For instance, they're denoted in a special syntax like DSv2,
DSv3, and as you can expect, the higher the version number,
the more features.
V3 is a pretty good cut‑off to indicate nested virtualization support,
but as always, you'll want to consult the docs.
The B series are burstable, the 2 means 2 processor cores,
m means memory‑optimized.
So there is a logic or a rubric behind how Microsoft chooses these VM names.
Basically, it's family, sub‑family, the number of vCPUs,
special features, and then version.
Microsoft has an entire Docs article on describing
how they name their Azure VMs.
I would suggest that you look at the exercise files,
not necessarily for exam purposes,
because you don't have to memorize these details for your exam, but you do definitely need to understand how to change and Azure VM size.