VMs, Networking, and Boundaries

Virtual machines give you direct control over the operating system, runtime, and network stack. In Azure, VMs are the escape hatch for workloads that cannot run on managed compute. Azure networking provides the isolation, connectivity, and security boundaries that control how resources communicate with each other and with external systems.

Virtual Machines: When You Need Direct Machine Control

VMs are justified when one of these is true:

• The workload requires OS-level software, custom drivers, or kernel configuration
• Legacy applications depend on specific OS versions or runtimes that managed services do not support
• Regulatory or compliance requirements mandate full control over the compute environment
• Specialized software (databases, middleware, agents) needs direct installation

VM as the Exception, Not the Default

For most new workloads, prefer managed compute:

VMs carry operational overhead: OS patching, disk management, scaling configuration, monitoring agents, and availability set/zone planning. Managed services absorb most of this. Choose VMs deliberately, not by default.

VM Basics

• VM sizes: grouped by workload type. General-purpose (D-series), compute-optimized (F-series), memory-optimized (E-series), storage-optimized (L-series), GPU (N-series).
• Disks: OS disk + optional data disks, all backed by Managed Disks. Choose Standard HDD, Standard SSD, Premium SSD, or Ultra Disk based on IOPS and throughput needs.
• Availability: deploy across availability zones (separate datacenters in a region) for resilience. Use Virtual Machine Scale Sets for auto-scaling groups.

Azure Networking Fundamentals

Virtual Networks (VNets)

A VNet is a private, isolated network in Azure. All Azure VMs and many other resources deploy into a VNet. VNets provide:

• Address space isolation: you define the CIDR range (e.g., 10.0.0.0/16)
• Subnet segmentation: divide the VNet into subnets for different workload tiers
• DNS resolution: Azure-provided DNS or custom DNS servers
• Peering: connect VNets to each other (same region or cross-region)

graph TB
    subgraph VNet["Virtual Network (10.0.0.0/16)"]
        subgraph Sub1["Frontend Subnet (10.0.1.0/24)"]
            VM1["Web Server VM"]
            VM2["Web Server VM"]
        end
        subgraph Sub2["Backend Subnet (10.0.2.0/24)"]
            VM3["App Server VM"]
        end
        subgraph Sub3["Data Subnet (10.0.3.0/24)"]
            PE1["Private Endpoint<br/>Storage"]
            PE2["Private Endpoint<br/>SQL Database"]
        end
    end

    NSG1["NSG: Allow 443 inbound"] --> Sub1
    NSG2["NSG: Allow from Frontend only"] --> Sub2
    NSG3["NSG: Allow from Backend only"] --> Sub3

    subgraph Hybrid["On-Premises Network"]
        ONPREM["Datacenter"]
    end

    VPN["VPN Gateway /<br/>ExpressRoute"] --- VNet
    VPN --- Hybrid

Network Security Groups (NSGs)

NSGs are stateful firewalls applied to subnets or individual network interfaces. Each NSG contains inbound and outbound rules that allow or deny traffic based on:

• Source and destination IP ranges
• Port numbers
• Protocol (TCP, UDP, ICMP)
• Priority (lower number = higher priority)

Best practice: apply NSGs at the subnet level for baseline rules, then add NIC-level NSGs only when a specific VM needs different treatment.

Private Endpoints

Private endpoints bring Azure PaaS services into your VNet. Instead of accessing a service like Storage or SQL Database over its public endpoint, you access it through a private IP address on your VNet.

This means:

• Traffic stays on the Microsoft backbone network, never traversing the public internet
• You can block public access entirely on the PaaS service
• NSG rules and VNet routing apply to PaaS traffic just like VM traffic
• DNS resolution maps the service’s public hostname to the private IP

Private endpoints are available for most Azure PaaS services: Storage, SQL Database, Cosmos DB, Key Vault, Event Hubs, Service Bus, App Service, and many others.

Hybrid Connectivity

When Azure-hosted workloads need to reach on-premises systems (or vice versa), two options handle the network link:

VPN Gateway: encrypted tunnel over the public internet. Suitable for:

• Dev/test environments
• Moderate bandwidth requirements (up to ~10 Gbps with VPN Gateway Gen2)
• Workloads tolerant of internet latency variability

ExpressRoute: dedicated private connection through a connectivity provider. Suitable for:

• Production workloads with strict latency or bandwidth requirements
• Large data transfers
• Regulatory requirements prohibiting internet-routed traffic
• Consistent, predictable network performance

Both options connect an on-premises network to an Azure VNet, making resources in both environments addressable as if on the same network.

Common Use Cases

• Legacy application hosting: lift-and-shift applications that depend on specific OS configurations, middleware, or runtime versions that managed services do not support.
• Hybrid connectivity: connect cloud workloads to on-premises databases, file shares, or APIs using VPN Gateway or ExpressRoute.
• Private network requirements: use VNets, NSGs, and private endpoints when security policy requires that PaaS services are not exposed to the public internet.
• Specialized software: databases, monitoring agents, build servers, or third-party software that requires direct OS installation.
• Network virtual appliances: firewalls, load balancers, or WAN optimizers deployed as VMs that inspect and route traffic within a VNet.

In Entra-Adjacent Systems

VMs and private networking appear at specific points in identity-integrated architectures:

• Hybrid sync agents: Entra Connect Sync runs on a Windows Server VM joined to the on-premises Active Directory domain. It needs network line-of-sight to domain controllers and outbound connectivity to Entra ID.
• Application Proxy connectors: lightweight agents installed on VMs (or servers) in the on-premises network that relay traffic for published applications without requiring inbound firewall ports.
• Private Link for identity services: Private endpoints can secure access to identity-adjacent PaaS services (Key Vault for secrets, Storage for audit logs, SQL for application databases) so that workloads never traverse the public internet.
• Provisioning to on-premises targets: when Entra provisions users to on-premises LDAP directories or SQL databases, an agent on a VM inside the network boundary handles the connection.

Practical Guidance

Start with managed compute. When a workload genuinely requires OS-level control, a VM is the right choice, but carry the operational cost consciously. Design the network boundary early: define VNets and subnets before deploying resources, not after. Use NSGs to enforce least-privilege traffic rules. Add private endpoints for any PaaS service that does not need public exposure. If the architecture crosses into on-premises, choose between VPN Gateway (simpler, cheaper) and ExpressRoute (faster, more predictable) based on production requirements, not aspiration.