Azure Virtual Machines: Fix Setup & Config Errors

The single biggest mistake people make with Azure virtual machines is clicking straight into the creation wizard without thinking through the decisions that are hard to change later. Microsoft's own documentation is explicit about this: before you create a VM, you need to settle on the resource names, the location, the size, the operating system, and all the related resources it will need.

Resource names matter more than they seem. Your VM name feeds into the DNS name, the OS hostname, and the names of all supporting resources Azure creates. Names can't be changed after deployment without redeployment. Use a consistent naming convention from day one, something like vm-prod-eastus-web-01 beats MyTestVM every time.

Location selection is about more than geography. Azure stores your virtual hard disks in the region you pick. If your on-premises datacenter or user base is in Europe but you deploy to West US, you're adding latency to every single operation. Check regional availability for your specific VM size before committing to a location. Use the Azure portal's virtual machine selector tool or run:

az vm list-skus --location westeurope --resource-type virtualMachines --output table

VM size determines processing power, memory, storage capacity, and network bandwidth, all of it flows from this one choice. The Dsv6 series is good for general-purpose workloads with balanced CPU and memory. The Fasv7 series is compute-optimized for workloads that are CPU-intensive. The Dasv7 series handles general-purpose workloads with high memory-to-CPU ratios. Pick based on workload, not habit.

If you've done this planning and the deployment still fails, check the VM's Activity Log in the portal (left sidebar → Activity log). The log shows the exact error code and timestamp for every failed operation, far more useful than the generic error banner on the overview page.

You deployed your Azure virtual machine successfully, you have the IP address, you open your SSH client, and nothing. The connection just times out. Before you assume the VM is broken, check the NSG. Nine times out of ten, this is an NSG rule issue.

In the Azure portal, open your VM, then click Networking in the left sidebar. You'll see two sections: Inbound port rules and Outbound port rules. Azure creates a default NSG that blocks most inbound traffic. For SSH access to Linux VMs, you need TCP port 22 open. For RDP on Windows, you need TCP port 3389. For web servers, you'll need port 80 (HTTP) and 443 (HTTPS).

Click Add inbound port rule and fill in these fields exactly:

Source: My IP address (or IP Addresses for a specific range)
Source port ranges: *
Destination: Any
Destination port ranges: 22
Protocol: TCP
Action: Allow
Priority: 300
Name: Allow-SSH

Lower priority numbers win when rules conflict, 300 is a safe priority that won't clash with Azure's default rules (which start at 65000+). Hit Add and wait about 30 seconds for the rule to propagate.

If you're managing this at scale across multiple VMs, use Azure CLI to apply NSG rules programmatically:

az network nsg rule create \
  --resource-group MyResourceGroup \
  --nsg-name MyNSG \
  --name Allow-SSH \
  --protocol tcp \
  --priority 300 \
  --destination-port-range 22 \
  --access allow

After adding the rule, try connecting again. If you still can't reach the VM, verify that the NIC is actually associated with the NSG, in the Networking tab, the NIC name is shown alongside the NSG name. A NIC without an NSG association, or a NIC associated with the wrong NSG, is a frequent misconfiguration in cloned or manually built environments.

The AllocationFailed error is one of the most common Azure virtual machine errors, and it's also one of the most misunderstood. It does not always mean you've hit a billing limit. It often means Azure doesn't have enough capacity of your requested VM size in your selected region at that moment, or you've hit a vCPU quota.

First, check your regional vCPU quota. In the portal, go to Subscriptions → [your subscription] → Usage + quotas. Filter by your region. Look for entries like "Total Regional vCPUs" and specific quota lines for the VM family you're trying to deploy (e.g., "Standard Dasv7 Family vCPUs"). If your current usage is at or near the limit, you'll need to either request a quota increase or choose a VM family with remaining quota.

To request a quota increase, click Request Increase on the Usage + quotas page. Fill in your justification, Microsoft approves most reasonable requests within 1–3 business days for standard VM families.

If quota isn't the issue, the capacity shortage in your region might be temporary. Try these alternatives in order:

# Option 1: Try a different zone in the same region
az vm create --resource-group MyRG --name MyVM \
  --image Ubuntu2204 --size Standard_D4s_v6 \
  --zone 2 --location eastus

# Option 2: Try a different region entirely
az vm create --resource-group MyRG --name MyVM \
  --image Ubuntu2204 --size Standard_D4s_v6 \
  --location eastus2

# Option 3: Check available sizes in your target region
az vm list-skus --location eastus \
  --resource-type virtualMachines \
  --query "[?restrictions[?reasonCode=='NotAvailableForSubscription']]" \
  --output table

The last command is particularly useful, it shows you which VM sizes are explicitly restricted in your subscription for your chosen region, so you can stop guessing and pick something that will actually work.

If you're running production workloads on Azure virtual machines, single-instance deployments are a reliability gamble you shouldn't take. Azure's availability zones are physically separated data centers within a single region, separate power, cooling, and networking. Microsoft guarantees VM connectivity to at least one instance 99.99% of the time when you deploy two or more instances across two or more availability zones in the same region. That's the SLA you want for anything business-critical.

Here's what many people get wrong: availability zones are not the same as availability sets. Availability sets protect against hardware failures within a single datacenter. Availability zones protect against entire datacenter failures. For most production workloads in 2026, you want zones, not sets.

To enable availability zones during VM creation in the portal, on the Basics tab look for the Availability options dropdown. Select Availability zone, then choose zones 1, 2, or 3 for your primary VM. Deploy your secondary VM in a different zone. That's it.

Via Azure CLI:

# Primary VM in zone 1
az vm create --resource-group ProdRG --name WebVM-01 \
  --image Win2022Datacenter --size Standard_D4s_v6 \
  --zone 1 --location eastus

# Secondary VM in zone 2
az vm create --resource-group ProdRG --name WebVM-02 \
  --image Win2022Datacenter --size Standard_D4s_v6 \
  --zone 2 --location eastus

If you need auto-scaling on top of high availability, Virtual Machine Scale Sets are the right tool. Scale sets let you define a minimum and maximum instance count, and Azure adds or removes VMs automatically based on CPU load, memory pressure, or a custom schedule. Scale set VMs can also span multiple availability zones for maximum resilience. The tradeoff is complexity, scale sets work best when your application is stateless or uses external session management.

After deploying across zones, validate the configuration by going to each VM's Overview page and checking the Availability zone field. If it shows "–" or "Not applicable," the zone assignment didn't take and you'll need to redeploy.

Azure virtual machine billing regularly surprises people because the VM's hourly compute cost and the storage cost are completely separate line items. The compute charge is based on VM size and OS, billed per minute for partial hours. But the OS disk, typically 127 GiB unless you're using a smaller image, is billed at managed disk rates even when the VM is deallocated (stopped). That's a common source of unexpected charges: people stop their VM thinking costs stopped too, but the disk keeps accruing charges.

The architecture recommendation from Microsoft is to keep OS and data on separate disks. If a VM fails, you can detach the data disk and attach it to a new VM without losing your data. This is not just theory, I've seen it save teams hours of data recovery work after a failed OS update.

To add a data disk to an existing VM, go to your VM in the portal, click Disks in the left sidebar, then Add data disk. Choose between Premium SSD (for I/O-intensive workloads), Standard SSD (balanced cost and performance), and Standard HDD (archive or low-priority data). Premium SSDs have higher per-GB costs but dramatically lower latency, for databases or active application data, always use Premium.

Via Azure CLI, attaching a new managed data disk looks like this:

az vm disk attach \
  --resource-group MyRG \
  --vm-name MyVM \
  --name MyDataDisk \
  --new \
  --size-gb 256 \
  --sku Premium_LRS

For the Trusted Launch feature now available in preview, where new Generation 2 VMs default to Trusted Launch with secure boot and vTPM enabled, this changes the disk and boot configuration. If you're working with existing automation scripts that create VMs without specifying --security-type, those scripts may behave differently once TLaD (Trusted Launch as Default) rolls out of preview. Test your deployment scripts against Gen2 images now to avoid surprises. You can explicitly set the security type during creation:

az vm create --resource-group MyRG --name SecureVM \
  --image Ubuntu2204 --generation 2 \
  --security-type TrustedLaunch \
  --enable-secure-boot true \
  --enable-vtpm true

Check your Azure Cost Management dashboard monthly, filter by resource type "Microsoft.Compute/disks" to see exactly what your disk storage is costing across all VMs. Unattached disks from deleted VMs are a silent cost driver that many teams don't notice until the bill arrives.