Azure Managed Disks simplify storage management by handling the backend storage accounts for Azure Virtual Machines (VMs). You only specify the required disk size and performance tier, and Azure automatically provisions and manages the underlying resources. This abstraction prevents single storage account limits from impacting multiple virtual disks, improving overall resiliency.
Selecting the right disk tier is critical for balancing performance and cost. Standard HDD works best for backup workloads and non-critical applications where low cost matters more than speed. Standard SSD provides consistent entry-level performance for web servers and light application workloads. Premium SSD delivers high throughput and low latency, making it the preferred choice for mission-critical production workloads. Ultra Disk offers highly scalable performance with sub-millisecond latencies, designed specifically for data-intensive systems like databases.
Configuring disk caching is a key decision for maximizing application performance on Premium SSDs. By default, the operating system disk uses Read-Write caching to speed up system boot and daily operations. For data disks, you must match the cache setting to the specific storage workload.
Choose Read-Only caching for data disks with read-heavy workloads to offload read operations to the VM's local cache. For write-heavy data disks, such as those hosting database transaction logs, select None to disable caching. Disabling caching ensures that write operations go directly to persistent storage, reducing write latency and preventing potential data loss.
To ensure optimal storage performance, you must match the disk size with the throughput requirements of the workload. When designing for high availability, deploy VMs within availability sets to spread virtual disks across different physical storage units. This architecture minimizes the risk of a single hardware failure bringing down the entire storage cluster.
Migrating existing workloads to managed disks involves uploading virtual hard disks or converting existing unmanaged virtual machines. A virtual hard disk (VHD) can be migrated from on-premises environments or other cloud providers. Before uploading, you must decide whether the VHD is generalized or specialized.
A generalized VHD has been stripped of unique security identifiers and user account information, making it suitable as a reusable template to deploy multiple VMs. A specialized VHD retains its original system settings and user accounts, allowing you to boot the system directly into its original state.
When a workload needs more CPU, memory, or storage, you can resize an Azure virtual machine to a different size. This process scales the VM up to a larger size or down to a smaller, less expensive one. The key tradeoff is disruption: if the new size is not available on the same physical hardware cluster that hosts the VM, the VM must be deallocated (stopped and released from its host) before the change. Deallocation causes a restart and a brief outage, so it matters for stateful applications that cannot easily stop. When you deallocate a VM, the operating system and data disks are preserved, but any dynamic public or private IP address assigned to the VM is released.
You can resize a VM through several tools, each following the same basic lifecycle. In the Azure Portal, you navigate to the virtual machine, select a new size, and apply the change; the portal handles deallocation automatically if needed. With PowerShell, you first run Get-AzVMSize to list the sizes available on the VM's current hardware, then use Update-AzVM to apply the new size. If the desired size is not listed, you must deallocate the VM with Stop-AzVM before resizing. Using the Azure CLI, you check available sizes with az vm list-vm-resize-options, deallocate with az vm deallocate, resize, and then restart the VM. Across all methods, the critical decision point is whether the new size requires a different hardware cluster: if yes, the VM goes through the stopped (deallocated) state and loses its dynamic IP, but keeps its disks and any static IP you assigned.
VM scale sets are groups of identical VMs that work together to handle changes in demand. They keep the application available and cost-efficient by automatically adding or removing instances. Three components make this work:
A scale set depends on the load balancer to distribute requests and on the health probe to detect failure. When demand rises, autoscale adds a new VM. The VM starts in a provisioning state while it is created, then moves to a running state. The load balancer only directs traffic to the VM after the health probe confirms it is healthy. When demand falls, autoscale removes the running instances that have the fewest active connections, following an orderly scale-in policy.
When multiple VMs are grouped in an availability set to protect against hardware failure, you must coordinate the resize operation. First, check if the new size is available on the current hardware using Get-AzVMSize. If it is not available, you must deallocate all VMs in the set at the same time using Stop-AzVM because the entire availability set lives on the same hardware cluster. After they are deallocated, apply the new size to every VM with Update-AzVM, then restart them all with Start-AzVM. This approach prevents a situation where one VM has been resized to a new hardware cluster while another is still on the old cluster, breaking the availability guarantees of the set.
Availability sets are logical groupings of virtual machines (VMs) that help reduce the chances of correlated failures. By distributing VMs across different fault domains, availability sets enhance reliability and are especially useful in Azure regions that do not support availability zones. Placing at least two VMs in an availability set can achieve a 99.95% Azure SLA without additional costs, making this a cost-effective way to meet uptime requirements.
Within an availability set, Azure separates VMs across different domains to protect against different types of failures. Fault domains group VMs that share common power sources and network switches, and Azure can separate VMs across up to 3 fault domains to limit the impact of physical hardware failures like a power outage or switch failure. Update domains contain VMs and physical hardware that can be restarted together during planned maintenance, and Azure services one update domain at a time so that some VMs stay running while others are updated. This two-domain approach ensures that maintenance or hardware failures do not take all your VMs offline at once.
Availability zones provide a higher level of reliability by allowing VMs to be deployed across multiple datacenters within the same Azure region. Each zone operates independently with its own power, cooling, and networking, protecting your VMs from localized datacenter failures like a building-wide power outage or network outage. Because the zones are geographically separated within the region, this setup offers stronger resilience compared to availability sets, though it requires support from the specific Azure region you are using.
When deploying VMs, you must choose whether to place them in an availability set or across availability zones based on your resiliency needs. For availability sets, you configure the number of fault domains and update domains using Azure CLI or PowerShell to define how Azure spreads your VMs across physical hardware. For availability zone deployments, you specify which zone each VM belongs to, and Azure automatically distributes them across separate datacenters. The choice between these options depends on your SLA requirements, your budget, and whether the Azure region supports availability zones.
Just-in-Time (JIT) VM Access is a security feature from Microsoft Defender for Cloud that reduces the attack surface of your virtual machines. It works by keeping management ports, like RDP (3389) and SSH (22), closed by default. An administrator must request access, which opens these ports only for a specific IP address and for a limited time window. You configure JIT by selecting target VMs and defining rules that specify which ports can be opened, which source IP ranges are allowed to request access, and the maximum time access can be granted.
After JIT is enabled, you can manage its rules. You can add new ports to the policy, modify the list of approved source IP addresses, or adjust the maximum request duration. When a user needs access, they submit a request through the Defender for Cloud portal, selecting the VM, port, their source IP, and a time period within the policy's limits. The port opens only if the request matches all the configured rules, providing precise, temporary access.
Azure Bastion is a fully managed PaaS service that provides secure RDP and SSH connectivity to your VMs without exposing them to the public internet. You connect to a VM through your web browser via the Azure portal, and the traffic flows securely over TLS on port 443. To deploy Bastion, you must first create a dedicated subnet in your virtual network with the specific name AzureBastionSubnet. You then deploy the Bastion resource into this subnet using the Azure portal, CLI, or PowerShell.
Because Azure Bastion provides the secure tunnel, your VMs do not need public IP addresses. However, you must configure Network Security Group (NSG) rules to ensure only traffic from the Bastion service can reach your VMs' management ports. This typically involves allowing inbound traffic on ports 3389 (RDP) or 22 (SSH) from the IP range of the AzureBastionSubnet or from the Azure Bastion service tag. This setup creates a clear trust boundary: all administrative traffic must flow through the managed Bastion service, which sits in its own dedicated subnet.
Using JIT and Azure Bastion together creates a layered security model. You can configure your JIT policy to only allow access requests originating from the IP range used by your Azure Bastion service. This means an administrator must first get JIT approval, which temporarily opens the port, and then they must connect through the Bastion host. This combination enforces that access is both time-limited and channeled through a secure, managed service, validating connectivity without any public IP exposure on the VMs themselves.
A system architecture diagram showing how an administrator requests Just-in-Time access via Microsoft Defender for Cloud, which temporarily opens an NSG port for Azure Bastion to securely connect to a target VM over RDP or SSH without a public IP.
A virtual machine (VM) connects to an Azure virtual network using one or more virtual network interfaces. Each network interface receives an IP address configuration to handle communication with other resources. You must choose between a dynamic IP, which Azure automatically assigns from the subnet's available range, or a static IP, which you manually assign to keep the address from changing. When configuring static IPs, it is best practice to place them in isolated subnets to avoid address conflicts with dynamically assigned resources. If you need to add or remove a network interface, the VM must first be changed to the Stopped (deallocated) state.
To control the flow of traffic, a Network Security Group (NSG) acts as a firewall by filtering inbound and outbound network traffic. You can apply an NSG to an entire subnet or directly to an individual network interface, allowing you to secure traffic at different boundaries. Each NSG contains security rules defined by properties like protocol, port ranges, source and destination IP addresses, direction, and priority. Traffic is evaluated in order of priority, where lower numbers take precedence and stop further rule evaluation once a match is found. Default rules are automatically included in every NSG to provide baseline security; these rules cannot be deleted, but they can be overridden by creating custom rules with higher priority.
An Azure Load Balancer provides high availability by distributing incoming traffic across a group of virtual machines. The load balancer receives external or internal traffic through a frontend IP configuration, which serves as the single point of contact for clients. It then forwards this traffic to a backend address pool, which contains the IP addresses of the target VMs. To ensure traffic only goes to healthy VMs, a health probe continuously monitors the status of each machine in the backend pool. Finally, load-balancing rules define exactly how the traffic arriving at the frontend is mapped and sent to the backend VMs.
Virtual machines in an Azure network must resolve names to communicate properly with other resources. By default, VMs use Azure's built-in DNS server for name resolution, but you can also configure a custom DNS server to match your organization's active directory environment. For secure communication that extends beyond the cloud, you can connect your on-premises network to Azure. Choose a site-to-site VPN for an encrypted connection over the public internet, or choose Azure ExpressRoute when you need a private, high-speed connection that bypasses the internet entirely.
Administrators must validate network connections and troubleshoot performance issues to maintain a reliable hybrid network. Azure Network Watcher provides diagnostic tools to monitor and analyze the health of your network resources. One of its key features, the connection monitor, allows you to check connectivity and track performance metrics between VMs and other endpoints. These diagnostics help you quickly identify network bottlenecks, latency issues, or misconfigured security rules that block traffic.
Eager to master hybrid server management? Discover how to administer Windows Server Hybrid Core Infrastructure on Azure, setting your path towards the Microsoft Certified: Azure Hybrid Infrastructure Administrator Associate certification!
Prepare and test your skills
Prepare and test your skills
Azure Managed Disks simplify storage management by handling the backend storage accounts for Azure Virtual Machines (VMs), preventing single storage account limits from impacting multiple virtual disks and improving resiliency. With unmanaged disks, you must manage the storage accounts yourself.
Premium SSD disks deliver high throughput and low latency, making them the preferred choice for mission-critical production workloads. Standard SSD disks provide consistent entry-level performance suitable for web servers and light application workloads where lower cost is acceptable.
Configuring disk caching is a key decision for maximizing application performance on Premium SSDs. For write-heavy data disks, such as those hosting database transaction logs, you should select None to disable caching, which ensures write operations go directly to persistent storage and reduces write latency.
An availability set is a logical grouping of virtual machines that helps reduce the chances of correlated failures by distributing VMs across different fault domains and update domains. This architecture minimizes the risk of a single hardware failure or maintenance event bringing down all your VMs, and placing at least two VMs in an availability set can achieve a 99.95% Azure SLA.
StudyCerts
StudyCerts