Creating a virtual machine in Azure involves configuring several key settings for performance and security. This process begins in the Azure portal where you select a resource group, name the VM, and choose a deployment region. You then pick an operating system image and set up a local administrator account with a secure username and password.
Create a Virtual Machine
To start, you provide basic details like the VM name and region, such as East US. You select an OS image, like Windows Server, and create credentials for the local administrator account. The password must be secure and meet complexity requirements to protect the VM from unauthorized access.
By default, a new VM is accessible from the internet using Remote Desktop Protocol (RDP). This can be a security risk, so it's best to limit RDP access to specific authorized IP addresses or use an Azure Bastion host for a more secure connection. During creation, you should set Public inbound ports to None to disable direct public access.
Storage and Disk Configuration
In the Disks section, you choose the type of OS disk, like Standard SSD, which affects the VM's performance and cost. You also configure the VM to connect to a specific virtual network subnet. It is recommended to place the VM in a subnet separate from other critical resources, like a managed domain, to avoid conflicts.
Networking Setup
The VM connects to a network via a subnet. You can either create a new subnet or select an existing one within the same virtual network as your other resources. For more complex setups, you can use Azure virtual network peering to connect the VM to a subnet in a completely different virtual network. The chosen subnet must have network connectivity to other necessary services, like a domain controller, for operations such as domain join.
Security Measures
Additional security layers are applied after the VM is created. You can use Network Security Groups (NSGs) to create rules that allow or deny traffic based on IP address, port, and protocol. For broader protection, Azure Firewall provides centralized, stateful inspection and threat intelligence filtering. To defend against large-scale attacks, enable DDoS Protection Standard. Using Private Endpoints via Azure Private Link allows the VM to access Azure services (like storage or a database) over a private network connection, removing the need for public internet exposure.
Integrate Initial Network Connectivity and Storage
A virtual machine's network identity is defined by its connection to a Virtual Network (VNET) and a specific Subnet within it. The Network Interface Card (NIC) is the virtual component that enables this network communication for the VM. Each NIC must be in the same Azure region and subscription as the VM it is attached to.
Network Components and Security
The primary networking building blocks are the VNET and its subnets. You assign IP addresses to the VM's NIC: a Private IP address is required for internal communication, while a Public IP address is optional and enables direct inbound access from the internet. To control traffic flow, you apply Network Security Groups (NSGs) with rules that permit or deny traffic. For secure remote access without a public IP, you can use the Azure Bastion service.
Storage Configuration with Managed Disks
Azure Managed Disks handle the underlying storage accounts, simplifying management. You configure two main types of disks: an OS Disk for the operating system and separate Data Disks for applications and data. Keeping data separate from the OS improves durability and simplifies recovery. For performance, you select disk types like Premium SSD for production or Standard HDD for cost-effective backup storage, and you can enable Caching on disks to speed up frequent data access.
For specialized roles, like a firewall or router, you can enable IP Forwarding on a NIC, allowing the VM to act as a Network Virtual Appliance (NVA). For outbound internet access when a VM doesn't have a public IP, Azure provides Source Network Address Translation (SNAT). You can also deploy a NAT Gateway for scalable, subnet-level outbound connectivity. To maximize network performance, enable Accelerated Networking, which reduces latency by bypassing the host's virtual switch.
For Generation 2 VMs, you can enable Trusted Launch, which uses a Virtual Trusted Platform Module (vTPM) and Secure Boot to protect the startup process from malware. The chosen VM size dictates the maximum network bandwidth and disk throughput. Other important considerations include using Availability Zones for high availability, enabling Disk Encryption for data-at-rest security, and consulting Azure Advisor for optimization recommendations.
Determine Essential Virtual Machine Specifications
Selecting the right Virtual Machine Size requires analyzing the workload's needs for CPU, memory, and storage. Azure offers families for different purposes: the B-series for burstable workloads with intermittent CPU needs, GPU-optimized series for graphics and simulation, and General Purpose series for balanced testing and development. Using multiple smaller VMs instead of one large VM can improve resilience and simplify automated scaling.
Storage Configuration
Meeting performance Service Level Agreements (SLAs) for production workloads requires using Premium SSDs. Managed Disks are the standard, as they handle storage account management automatically. A key best practice is separating data disks from the OS disk, which safeguards application data if the operating system fails and makes recovery easier.
High Availability
To achieve High Availability, deploy VMs across Availability Zones, which are physically separate datacenters within an Azure region. For workloads with variable demand, use Virtual Machine Scale Sets, which automatically manage a group of identical VMs and can guarantee 99.99% connectivity when instances are distributed across zones. Simulating your workload helps verify that your chosen availability strategy will meet real-world demands.
Secure Authentication
During VM creation, you must implement secure authentication. For Linux VMs, this typically means using SSH keys instead of passwords. For Windows VMs, you configure a strong password for the local administrator account. The chosen method must balance security with the operational needs for accessing and managing the VM.