Academmia

Describe the Resources Required for Virtual Machines

az-900•mixed•

Azure architecture and services

Describe the Resources Required for Virtual Machines

Short Summary

When I create an Azure Virtual Machine (VM), I’m really creating a small set of connected resources, not one “all-in-one” object. This lesson explains the core building blocks—compute, storage, and networking—and what’s optional based on connectivity needs. I’ll also clarify why a VM is only reachable from the internet if I explicitly configure a public endpoint and allow inbound traffic.

Learning Objectives

By the end of this lesson, you will be able to:

  • Identify the core resource types that a VM depends on (compute, disks, and networking).
  • Explain why a VM is not a single self-contained resource in Azure.
  • Describe the minimum networking pieces required for private connectivity.
  • Decide when a public IP address and a Network Security Group (NSG) are needed.
  • Distinguish persistent disk storage from temporary (ephemeral) storage in the VM context.

Core Concepts

Creating a VM in Azure usually creates (or relies on) multiple resources that work together. Even if the Azure portal creates them in one flow, they still exist as separate resources you can manage independently.

Compute: the VM resource

An Azure Virtual Machine (VM) is the compute component. This is where I choose the “size” (how much compute capacity I want):

  • virtual CPU (vCPU): how many CPU cores are allocated to the VM
  • Random Access Memory (RAM): how much memory the VM has

The VM resource represents the machine, but it needs storage to boot and networking to communicate.

Storage: disks (persistent) and temporary storage (not durable)

A working VM needs storage, typically:

  • operating system (OS) disk: the disk used to boot the VM
  • data disks (optional): additional disks for application/data storage

In many setups, these are managed disks (Azure-managed persistent disks).

Some VM sizes also provide temporary (ephemeral) storage on the host. It’s useful for cache or scratch space, but it isn’t designed for important data. If losing the data would hurt, it should not live on temporary storage.

Networking: private connectivity first

To communicate inside Azure (or over private connectivity), a VM typically needs:

  • a Virtual Network (VNet)
  • a subnet inside that VNet
  • a Network Interface (NIC) attached to the VM

The NIC is the “attachment point” that gives the VM a private IP address inside the subnet so it can talk to other private resources.

Optional pieces: public endpoints and traffic filtering

A VM is only reachable from the public internet if I set up a public endpoint and allow inbound traffic. Common optional pieces are:

  • Public IP address: gives the VM (or its front end) a public address. Without a public endpoint, the VM can still work privately, but it won’t be directly internet-reachable.
  • Network Security Group (NSG): a set of inbound/outbound rules that filters traffic. NSGs can be associated with a subnet and/or a NIC.

Important: “connected to a VNet” and “allowed from the internet” are separate ideas. A VM can be on a VNet and still be private-only.

Where these resources live

All of these resources live inside the same organizational boundaries:

  • Subscription
  • Resource group
  • Region

Those choices affect management, access control, cost tracking, and physical location.

Practical Understanding

Practical Situation 1: When you create a VM and see “extra resources,” that’s normal

You deploy a VM and notice related resources appear alongside it (disks, a NIC, maybe a public IP). It feels like Azure created “a bunch of stuff” instead of one thing.

How to think about it: That’s the standard model: VM = compute, and it depends on separate storage and networking resources. A single wizard can create them, but they still exist independently.

Common misunderstanding: “A VM is one object that contains everything.” In Azure, the VM is the compute resource; disks and networking are separate resources linked to it.

Practical Situation 2: “Private-only VM” still means “networking exists”

You want a VM reachable only inside Azure (or from your private network). You assume this means “no networking setup.”

How to think about it: “No public internet” usually means no public endpoint, not “no network.” You still need a VNet, subnet, and NIC for private traffic (VM-to-VM or via Virtual Private Network (VPN) / Azure ExpressRoute).

Common misunderstanding: “If there is no public IP, networking is optional.” Private networking is still networking, and it still needs the core building blocks.

Practical Situation 3: The VM runs, but you can’t connect from the internet

A VM exists and is healthy, but Remote Desktop Protocol (RDP) or Secure Shell (SSH) from the internet doesn’t work. You already have a VNet/subnet/NIC.

How to think about it: VNet/subnet/NIC gives private IP connectivity. For internet access, I need a public endpoint (often a public IP) and inbound traffic must be allowed by rules (commonly an NSG). Without those, the VM won’t be internet-reachable.

Common misunderstanding: “VM exists” implies “VM is reachable.” Public reachability is an explicit configuration choice.

Practical Situation 4: “I stored it on the VM” — which storage did you mean?

You plan to store important files “on the VM,” and you see both managed disks and “temporary” storage.

How to think about it: Use managed disks (OS disk and data disks) for data you must keep. Use temporary storage only for disposable work data (cache, scratch, intermediate files) that you can recreate.

Common misunderstanding: “All storage attached to the VM is persistent.” Temporary (ephemeral) storage can be lost during certain VM lifecycle events, so it’s not the place for important data.

Common Pitfalls

  • Mistake: Assuming a VM is a single self-contained resource. Correction: A VM depends on separate resources (compute + disks + NIC/VNet), even if created in one portal flow.

  • Mistake: Forgetting that a VM needs both compute and storage to boot. Correction: A VM needs an OS disk (and optionally data disks); compute alone is not enough.

  • Mistake: Treating all VM storage as persistent. Correction: Use managed disks for persistence; treat temporary (ephemeral) storage as non-durable.

  • Mistake: Believing a VM is reachable from the public internet by default. Correction: Internet reachability requires a public endpoint (for example, a public IP) and allowed inbound rules (commonly via an NSG).

  • Mistake: Overlooking placement boundaries (subscription, resource group, region). Correction: Every VM and related resource must be placed in a subscription, a resource group, and a region—those choices affect management and governance.

Check Your Understanding

  1. List the minimum set of resource types you expect to exist for a private-only VM (no public internet exposure), and explain why each one is needed.
  2. Explain the difference between a VM having private connectivity inside a VNet and being reachable from the public internet.
  3. Write a simple rule you would follow to decide whether data belongs on a managed disk or temporary storage.
  4. Imagine you delete a VM. Which related resources might still exist if you didn’t delete them, and why?
  5. Pick a workload you know (web app, database, batch job). Which VM building blocks are mandatory, and which are optional based on connectivity needs?

Further Reading