Connect Azure Resources via VNet

You've built a few Azure resources — maybe a VM here, a database there — but now you need them to talk to each other securely. Exposing everything to the public internet is a recipe for disaster, and that's where the Azure Virtual Network (VNet) comes in. This lesson shows you how to connect Azure resources via Virtual Network, the private, secure foundation for almost every real-world Azure deployment.

The problem this lesson solves

When you create a VM and a database, each gets a public IP by default. To connect them, you'd have to allow traffic through the public internet — slow, expensive, and a massive security risk. Attackers scan for open ports, and every public endpoint is a target. The solution is to place resources inside a private network where they can communicate using private IP addresses, invisible to the outside world. This is exactly what Azure Virtual Network provides.

Without a VNet, you're stuck with: - Latency — traffic takes a detour through the internet. - Security holes — open ports, exposed databases. - Egress costs — you pay for data leaving Azure. - Complex firewalls — you'd need to harden every resource individually.

A VNet solves all of this by creating a private address space — think of it as your own slice of the Azure cloud.

Core concept / mental model

Think of a Virtual Network as a gated community for your Azure resources. Inside the community, houses (VMs) can visit each other freely. The gate (firewall/NSG) controls who enters from outside, and the streets (subnets) organize the layout. Each resource gets a private IP address, like a house number, that only makes sense inside the community.

Key components:

• Address space — the range of private IPs, e.g., 10.0.0.0/16. This is the land your community sits on.
• Subnets — subdivisions within the VNet, e.g., 10.0.1.0/24 for web servers, 10.0.2.0/24 for databases. Each subnet is a district.
• Network Security Groups (NSGs) — rules that act like a bouncer at each subnet's entrance.
• Private IPs — dynamic or static addresses assigned to resources inside the VNet.

A resource is connected to a VNet when it's running with a network interface (NIC) attached to a subnet. That's the key — the attachment is what makes it private and reachable.

How it works step by step

1. Create a Virtual Network in a resource group. Define the address space, e.g., 10.0.0.0/16.
2. Split the VNet into subnets — one for each tier of your application (e.g., web, app, data).
3. Create resources — VMs, databases — and when you configure them, attach them to a VNet and subnet.
4. Configure NSGs to allow only the necessary traffic. By default, resources in the same VNet can talk to each other, but NSGs let you control that.
5. Use private IPs — resources can connect using private addresses (e.g., 10.0.1.4), which never leave the VNet.
6. Test the connection — from a VM, ping or connect to the database's private IP.

The cause → effect chain: VNet creation → subnet definition → resource attachment → private communication. Each step builds on the last, and you can't skip the subnet step if you want resources to be reachable.

Pro tip: Always plan your address space before creating resources. Changing the address space later is painful. Use ranges that won't conflict with on-premises networks if you'll ever connect via VPN or ExpressRoute.

Hands-on walkthrough

Let's connect two VMs inside a VNet. We'll use a bash script with the Azure CLI — the quickest way to see the magic.

Step 1: Create the VNet and subnets

# Create a resource group
export RG_NAME="rg-vnet-demo"
export LOCATION="eastus"
az group create --name $RG_NAME --location $LOCATION

# Create a VNet with two subnets
az network vnet create \
  --resource-group $RG_NAME \
  --name myVNet \
  --address-prefix 10.0.0.0/16 \
  --subnet-name webSubnet \
  --subnet-prefix 10.0.1.0/24

# Add a second subnet for the database
az network vnet subnet create \
  --resource-group $RG_NAME \
  --vnet-name myVNet \
  --name dbSubnet \
  --address-prefix 10.0.2.0/24

Expected output: JSON confirmation of the VNet and subnets. You can list them with:

az network vnet list -g $RG_NAME -o table

Step 2: Create a VM in the web subnet

az vm create \
  --resource-group $RG_NAME \
  --name webVM \
  --image UbuntuLTS \
  --vnet-name myVNet \
  --subnet webSubnet \
  --size Standard_B1s \
  --admin-username azureuser \
  --generate-ssh-keys

Note: By default, the VM gets a public IP for SSH access, but its private IP is what we care about. Find it later with:

az vm list-ip-addresses -g $RG_NAME -n webVM -o table

Step 3: Create a second VM in the database subnet — without a public IP

az vm create \
  --resource-group $RG_NAME \
  --name dbVM \
  --image UbuntuLTS \
  --vnet-name myVNet \
  --subnet dbSubnet \
  --size Standard_B1s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-address ""

The empty --public-ip-address means no public IP. This VM is only reachable from inside the VNet — perfectly secure.

Step 4: Test the private connection

SSH into webVM, then from webVM connect to dbVM using its private IP:

# On webVM
ssh azureuser@10.0.2.4   # private IP of dbVM

# You're now on dbVM — private-only communication works!

If you see the dbVM prompt, you've successfully connected two Azure resources via Virtual Network — no public internet involved.

Compare options / when to choose what

Not every connection needs the same approach. Here's how to decide:

VNet peering is the go-to for connecting separate VNets. It's low latency, no gateways, and traffic stays on Microsoft's network. VPN Gateway is for site-to-site or point-to-site VPNs — slower, but great for hybrid. Private Endpoints are the modern way to lock down PaaS like Azure SQL or Storage — they give the service a private IP inside your VNet.

Pro tip: Start with the simplest option — just put everything in one VNet with subnets. Add peering or private endpoints only when you need to cross VNets or reach PaaS services.

Troubleshooting & edge cases

• "Cannot reach the private IP" — Check that both resources are in the same VNet. You can't use VNet private IPs across different VNets without peering.
• SSH timeout to dbVM — The VM may not have a public IP, so you must connect from another VM inside the VNet. Verify the NIC's subnet is correct.
• NSG blocking traffic — By default, subnets have an NSG that allows all internal traffic. If you customized it, check that you're allowing ICMP or the port you need (e.g., 22 for SSH, 3306 for MySQL).
• Address space overlap — If you peer two VNets that share the same address range (e.g., both use 10.0.0.0/16), peering will fail. Use distinct ranges.
• Deleted VNet, orphaned resources — You can't delete a VNet that has resources attached. Delete the VMs (and NICs) first.

What you learned & what's next

You now understand the core idea — Azure Virtual Network gives you a private, isolated network for your resources. You can create a VNet, subnets, and VMs, and connect resources using private IPs. You also know when to use peering, private endpoints, or a VPN gateway, and how to troubleshoot common connectivity issues.

As a next step, dive into Network Security Groups to lock down traffic, or explore VNet peering to connect multiple VNets across regions. You'll see these tools everywhere in real Azure deployments — this is the foundation.

Go practice: create a VNet with two subnets, add a VM to each, and make them talk. Once you've done that, try adding a Network Security Group to block all SSH traffic from the internet — you'll be ready for the next lesson.