Azure Networking for Data Engineers: VNets, Subnets, NSGs, Private Endpoints, and Everything In Between
Every pipeline you build, every database you connect to, every storage account you write to — all of it travels over a network. Yet networking is the topic most data engineers skip. “I just need my pipeline to work” — until it does not, and the error says “Connection timed out” or “Forbidden” or “No route to host.”
Understanding Azure networking is like understanding the road system in a city. You do not need to be a civil engineer to drive, but you need to know how traffic lights (NSGs), highways (VNets), exits (subnets), toll booths (firewalls), and private tunnels (private endpoints) work — especially when your delivery truck (data pipeline) gets stuck.
This post covers every networking concept a data engineer needs, using a city and building analogy that makes the abstract concrete.
Table of Contents
- The City Analogy: How Azure Networking Maps to a City
- Virtual Network (VNet): Your Private City
- Subnets: Neighborhoods in Your City
- IP Addresses: House Addresses
- Network Security Groups (NSGs): Security Guards
- Inbound vs Outbound Rules
- NSG Rule Priority and Evaluation
- Azure Firewall: The City’s Central Security Checkpoint
- Service Endpoints: VIP Express Lanes
- Private Endpoints: Private Tunnels
- Private Endpoints for Data Engineers
- VNet Peering: Connecting Two Cities
- VPN Gateway: The Encrypted Highway to On-Premises
- ExpressRoute: The Dedicated Private Highway
- DNS: The City’s Phone Book
- Network Architecture for a Data Platform
- How Azure Data Services Use Networking
- Managed VNet in Synapse and ADF
- Common Networking Errors and Fixes
- Real-World Scenarios
- Interview Questions
- Wrapping Up
The City Analogy: How Azure Networking Maps to a City
| Azure Concept | City Equivalent | What It Does |
|---|---|---|
| VNet | A gated city | Your private network — isolated from everyone else |
| Subnet | Neighborhoods within the city | Segments for different purposes (databases, apps, pipelines) |
| IP Address | House address | Unique identifier for each resource |
| NSG | Security guards at each neighborhood entrance | Rules for who can enter (inbound) and leave (outbound) |
| Inbound Rule | “Who can come IN to this neighborhood?” | Controls incoming traffic |
| Outbound Rule | “Who can LEAVE this neighborhood?” | Controls outgoing traffic |
| Azure Firewall | Central city security checkpoint | Inspects and filters all traffic entering/leaving the city |
| Service Endpoint | VIP express lane to a specific destination | Direct, fast route to Azure services without going through the internet |
| Private Endpoint | Private underground tunnel to a building | Brings an Azure service INTO your city with a private address |
| VNet Peering | Highway connecting two cities | Connects two VNets so resources can communicate |
| VPN Gateway | Encrypted highway to another country | Connects Azure to your on-premises data center over the internet |
| ExpressRoute | Dedicated private highway (not public road) | Private connection to Azure — does not use the internet at all |
| DNS | The city’s phone book | Translates names (sql-server.database.windows.net) to IP addresses |
Virtual Network (VNet): Your Private City
What It Is
A Virtual Network (VNet) is your isolated private network in Azure. It is a logically separated section of the Azure cloud dedicated to your resources. Nothing gets in or out unless you explicitly allow it.
Azure Cloud (the country)
|
|-- VNet: vnet-dataplatform-dev (10.0.0.0/16) <-- Your private city
| |-- Subnet: snet-databases (10.0.1.0/24) <-- Database neighborhood
| |-- Subnet: snet-apps (10.0.2.0/24) <-- Application neighborhood
| |-- Subnet: snet-pipelines (10.0.3.0/24) <-- Pipeline neighborhood
|
|-- VNet: vnet-dataplatform-prod (10.1.0.0/16) <-- Another city (prod)Key Characteristics
- Region-specific — a VNet exists in one Azure region (e.g., Canada Central)
- Address space — you define the IP range (e.g., 10.0.0.0/16 gives you 65,536 addresses)
- Isolated by default — two VNets cannot communicate unless you connect them (peering)
- Free — VNets themselves cost nothing. You pay for gateways, firewalls, and data transfer.
Creating a VNet
- Azure Portal > Create a resource > Virtual Network
- Name:
vnet-dataplatform-dev - Region: Canada Central
- Address space:
10.0.0.0/16 - Add subnets (next section)
- Click Review + Create
Real-life analogy: Creating a VNet is like building a gated community. You define the boundary (address space), create neighborhoods (subnets), and set up security (NSGs). Nobody from outside can enter unless you open the gate.
Subnets: Neighborhoods in Your City
What They Are
Subnets divide your VNet into smaller segments. Each subnet has its own IP range and can have its own security rules (NSG).
VNet: 10.0.0.0/16 (65,536 addresses)
|
|-- snet-databases: 10.0.1.0/24 (256 addresses) — SQL databases, Cosmos DB
|-- snet-apps: 10.0.2.0/24 (256 addresses) — App Services, Functions
|-- snet-pipelines: 10.0.3.0/24 (256 addresses) — ADF/Synapse managed VNet endpoints
|-- snet-vms: 10.0.4.0/24 (256 addresses) — Virtual Machines, SHIRWhy Subnet
- Security isolation — different NSG rules per subnet. Databases get strict rules, web apps get different rules.
- Organization — group related resources together
- Compliance — some resources MUST be in their own subnet (e.g., Azure Firewall, VPN Gateway)
- Delegation — some Azure services require a dedicated subnet (e.g., Azure SQL Managed Instance)
CIDR Notation Explained
/16 = 65,536 addresses (VNet level — the whole city)
/24 = 256 addresses (Subnet level — one neighborhood)
/28 = 16 addresses (Small subnet — a cul-de-sac)
/32 = 1 address (Single resource — one house)Real-life analogy: If a VNet is a city, subnets are neighborhoods. The financial district (databases) has different security than the residential area (VMs). You would not let random visitors walk into the bank vault, even if they are allowed in the city.
IP Addresses: House Addresses
Private IP Address
Every resource in a VNet gets a private IP from its subnet’s range. Only visible within the VNet.
SQL Server VM: 10.0.1.5 (private — only accessible within the VNet)
App Service: 10.0.2.10 (private)
SHIR VM: 10.0.4.20 (private)Public IP Address
A separate resource you attach to make something accessible from the internet.
SHIR VM: 10.0.4.20 (private) + 20.100.50.25 (public — accessible from internet)When to Use Public vs Private
| Scenario | Use |
|---|---|
| Resources talking to each other within VNet | Private IP only |
| Need to access from your laptop (RDP, SSH) | Public IP (with NSG restrictions) |
| Production databases | Private IP only (NEVER public) |
| Development VM for testing | Public IP (restrict to your IP in NSG) |
Real-life analogy: Private IP is your apartment number (only people inside the building know it). Public IP is the building’s street address (anyone in the city can find it). For security, you want databases to have apartment numbers only — no street address.
Network Security Groups (NSGs): Security Guards
What They Are
An NSG is a set of security rules that control inbound and outbound network traffic. Think of NSGs as security guards at the entrance of each neighborhood (subnet) or building (NIC — network interface card).
How NSGs Work
Internet NSG (Security Guard) Subnet
+---------+ +-------------------+ +----------+
| | --- Request ---> Check rules: | | |
| User | | Port 443? ✓ Allow | --------> | SQL DB |
| | | Port 1433? ✓ Allow| | |
| | | Port 22? ✗ Deny | | |
+---------+ +-------------------+ +----------+NSG Rules Structure
Each rule has:
| Property | What It Means | Example |
|---|---|---|
| Priority | Lower number = evaluated first (100-4096) | 100 |
| Name | Descriptive name | Allow_SQL_1433 |
| Direction | Inbound or Outbound | Inbound |
| Source | Where traffic comes from | 10.0.2.0/24 (apps subnet) |
| Destination | Where traffic goes to | 10.0.1.0/24 (databases subnet) |
| Port | Which port | 1433 |
| Protocol | TCP, UDP, or Any | TCP |
| Action | Allow or Deny | Allow |
Example NSG for a Database Subnet
Inbound Rules:
Priority 100: Allow TCP 1433 from 10.0.2.0/24 (apps can reach SQL)
Priority 110: Allow TCP 1433 from 10.0.3.0/24 (pipelines can reach SQL)
Priority 200: Allow TCP 3389 from MY_IP/32 (RDP from my laptop only)
Priority 4096: Deny All (default — block everything else)
Outbound Rules:
Priority 100: Allow TCP 443 to Internet (HTTPS for updates)
Priority 4096: Deny All (default)Real-life analogy: NSG rules are like a guest list at a club. Priority 100 says “VIP members can enter through the main door (port 1433).” Priority 200 says “The manager can enter through the back door (port 3389).” Everyone else? Denied at the door (default deny).
Inbound vs Outbound Rules
Inbound (Who Can Come IN?)
Controls traffic entering the subnet or resource.
Example: Allow ADF to connect to SQL Database
Direction: Inbound
Source: ADF's IP or subnet
Destination: SQL Database subnet
Port: 1433 (SQL Server port)
Action: AllowReal-life analogy: Inbound rules are like the front door policy of a building. “Delivery drivers (ADF) can enter through the loading dock (port 1433). Residents (apps) can enter through the lobby (port 443). Everyone else — access denied.”
Outbound (Who Can LEAVE?)
Controls traffic leaving the subnet or resource.
Example: Allow SQL Database VM to reach Azure Storage for backups
Direction: Outbound
Source: SQL Database subnet
Destination: Storage account
Port: 443 (HTTPS)
Action: AllowReal-life analogy: Outbound rules are like office policies on what employees can access. “Employees can send mail to clients (port 443 to storage). Employees cannot access social media (deny port 80 to certain IPs).”
Common Port Numbers Data Engineers Should Know
| Port | Service | When You Use It |
|---|---|---|
| 443 | HTTPS | Everything — APIs, storage, Key Vault, management |
| 1433 | SQL Server / Azure SQL | Database connections |
| 3389 | RDP (Remote Desktop) | Connecting to Windows VMs |
| 22 | SSH | Connecting to Linux VMs |
| 5432 | PostgreSQL | Azure Database for PostgreSQL |
| 3306 | MySQL | Azure Database for MySQL |
| 1521 | Oracle | Oracle Database connections |
| 80 | HTTP | Unencrypted web traffic (avoid in production) |
NSG Rule Priority and Evaluation
Rules are evaluated from lowest priority number to highest. The FIRST matching rule wins.
Priority 100: Allow TCP 1433 from 10.0.2.0/24 → MATCH → Allow (stops here)
Priority 200: Deny TCP 1433 from Any → Never reached for 10.0.2.0/24
Priority 4096: Deny All → Catches everything elseKey point: If you have a rule that allows AND a rule that denies the same traffic, the one with the LOWER priority number wins.
Real-life analogy: It is like a bouncer with a list. First they check the VIP list (priority 100). If your name is there, you are in. Then they check the general admission list (priority 200). If you are on neither, the default is “no entry” (priority 4096).
Default Rules (Cannot Be Deleted)
Every NSG comes with these default rules:
| Priority | Name | Direction | Action | Description |
|---|---|---|---|---|
| 65000 | AllowVnetInBound | Inbound | Allow | Traffic within the VNet |
| 65001 | AllowAzureLoadBalancerInBound | Inbound | Allow | Azure health probes |
| 65500 | DenyAllInBound | Inbound | Deny | Block everything else |
| 65000 | AllowVnetOutBound | Outbound | Allow | Traffic within the VNet |
| 65001 | AllowInternetOutBound | Outbound | Allow | Outbound internet access |
| 65500 | DenyAllOutBound | Outbound | Deny | Block everything else |
These are the “baseline security” — VNet-internal traffic is allowed, internet outbound is allowed, everything else is denied.
Service Endpoints: VIP Express Lanes
What They Are
A Service Endpoint creates a direct, optimized route from your VNet to an Azure service (Storage, SQL, Key Vault) over the Azure backbone network — bypassing the public internet.
Without Service Endpoint:
VM (10.0.1.5) → Internet → Azure Storage (public endpoint)
Route: Through public internet, slower, less secure
With Service Endpoint:
VM (10.0.1.5) → Azure backbone → Azure Storage (optimized route)
Route: Never leaves Azure's network, faster, more secureHow to Enable
- Go to your Subnet > Service endpoints
- Add:
Microsoft.Storage,Microsoft.Sql,Microsoft.KeyVault - Save
Now traffic from this subnet to Storage/SQL/KeyVault stays on Azure’s private backbone.
Real-life analogy: Without a service endpoint, your delivery truck drives through the city streets (public internet) to reach the warehouse (Azure Storage). With a service endpoint, you get access to a private express highway (Azure backbone) — faster, no traffic lights, and no risk of road accidents (packet interception).
Limitation
Service Endpoints secure the ROUTE but the Azure service still has a public endpoint. The storage account is still accessible from the internet (unless you add a firewall rule). For full privacy, use Private Endpoints.
Private Endpoints: Private Tunnels
What They Are
A Private Endpoint brings an Azure service inside your VNet by giving it a private IP address. The service is no longer accessible from the public internet — only from within your VNet.
Without Private Endpoint:
Storage account: accessible at https://mystorageaccount.blob.core.windows.net
Anyone on the internet can try to connect (blocked by firewall rules, but still public)
With Private Endpoint:
Storage account: accessible at 10.0.1.10 (private IP inside YOUR VNet)
Only resources in your VNet can reach it. No public access at all.How It Works
Your VNet (10.0.0.0/16)
|
|-- snet-privateendpoints (10.0.5.0/24)
| |
| |-- pe-storage (10.0.5.10) ──────► Azure Storage Account
| |-- pe-sqldb (10.0.5.11) ──────► Azure SQL Database
| |-- pe-keyvault (10.0.5.12) ─────► Azure Key Vault
|
|-- snet-vms (10.0.4.0/24)
|
|-- VM can access storage at 10.0.5.10 (private)
|-- VM can access SQL at 10.0.5.11 (private)Creating a Private Endpoint
- Go to the target resource (e.g., Storage Account) > Networking > Private endpoint connections
- Click + Private endpoint
- Name:
pe-storage-dev - Region: Canada Central
- Target sub-resource:
blob(for Blob Storage) ordfs(for ADLS Gen2) - Virtual network:
vnet-dataplatform-dev - Subnet:
snet-privateendpoints - Integrate with private DNS zone: Yes
- Click Create
After creation, the storage account gets a private IP (e.g., 10.0.5.10) inside your VNet. Disable public access on the storage account to ensure ALL traffic goes through the private endpoint.
Real-life analogy: Without a private endpoint, the bank (storage) is on a public street. Anyone can walk up to the front door (firewall determines who gets in). With a private endpoint, the bank builds a private tunnel from YOUR building directly to their vault. No public entrance exists — only your tunnel.
Private Endpoints for Data Engineers
Why Data Engineers Care
In production, every data service should use private endpoints:
| Service | Private Endpoint Sub-Resource | Port |
|---|---|---|
| ADLS Gen2 | dfs |
443 |
| Azure SQL Database | sqlServer |
1433 |
| Azure Key Vault | vault |
443 |
| Azure Synapse | Sql, SqlOnDemand, Dev |
1433, 443 |
| Azure Cosmos DB | Sql |
443 |
| Azure Event Hubs | namespace |
5671 |
ADF/Synapse with Private Endpoints
When ADF/Synapse has Managed VNet enabled:
- ADF creates Managed Private Endpoints to your data sources
- All pipeline traffic stays on private network
- No data travels over the public internet
- You approve each managed private endpoint on the target resource
ADF (Managed VNet)
|
|-- Managed Private Endpoint → ADLS Gen2 (10.0.5.10)
|-- Managed Private Endpoint → Azure SQL (10.0.5.11)
|-- Managed Private Endpoint → Key Vault (10.0.5.12)
|
All traffic is private. No public internet involved.VNet Peering: Connecting Two Cities
What It Is
VNet Peering connects two VNets so resources in both can communicate using private IP addresses. Traffic stays on the Azure backbone — never touches the internet.
VNet A: vnet-dev (10.0.0.0/16) ←── Peering ──→ VNet B: vnet-prod (10.1.0.0/16)
| |
|-- VM-A (10.0.1.5) can reach VM-B (10.1.1.5) |-- VM-B can reach VM-AWhen to Use
- Dev/Prod connectivity — dev pipeline needs to read from prod database (controlled access)
- Hub-and-spoke architecture — central hub VNet connects to multiple spoke VNets
- Cross-region — global peering connects VNets in different Azure regions
Real-life analogy: VNet Peering is like building a bridge between two islands. Before the bridge, the only way to travel was by boat (public internet). After the bridge, traffic flows directly — faster, safer, and private.
VPN Gateway: The Encrypted Highway to On-Premises
What It Is
A VPN Gateway creates an encrypted tunnel over the public internet between your Azure VNet and your on-premises network.
On-Premises Network Internet (encrypted) Azure VNet
+------------------+ +---+---+---+---+ +------------------+
| SQL Server |──────────────| VPN Tunnel |──────────────| ADF + ADLS |
| 192.168.1.0/24 | | (IPsec/IKE) | | 10.0.0.0/16 |
+------------------+ +---+---+---+---+ +------------------+When to Use
- Connecting your corporate office to Azure
- Hybrid cloud scenarios (our SHIR pipeline used public IP, but production would use VPN)
- Extending on-premises Active Directory to Azure
Real-life analogy: A VPN is like an armored truck traveling on public roads. The road (internet) is public, but the contents (your data) are locked in an armored vault (encryption). Nobody can see what is inside even if they see the truck.
ExpressRoute: The Dedicated Private Highway
What It Is
ExpressRoute provides a private, dedicated connection from your data center to Azure. Unlike VPN (which goes over the internet), ExpressRoute uses a private circuit provided by a telecom carrier.
On-Premises ──── Private Circuit (NOT internet) ──── Azure
(provided by Bell, Telus, AT&T, etc.)ExpressRoute vs VPN
| Feature | VPN Gateway | ExpressRoute |
|---|---|---|
| Connection | Over public internet (encrypted) | Private dedicated circuit |
| Bandwidth | Up to ~1.25 Gbps | Up to 100 Gbps |
| Latency | Variable (depends on internet) | Consistent, low latency |
| Cost | ~$140-350/month | ~$250-10,000/month |
| Setup | Hours (software config) | Weeks (physical circuit provisioning) |
| Best for | Small offices, dev/test | Enterprise production, large data transfers |
Real-life analogy: VPN is like taking a highway toll road — faster than regular roads but still shared. ExpressRoute is like having your own private road built just for you — nobody else uses it, guaranteed speed, but very expensive to build.
Network Architecture for a Data Platform
Development Architecture (Simple)
VNet: vnet-dev (10.0.0.0/16)
|
|-- snet-default (10.0.1.0/24)
| |-- SQL Database (public with firewall rules)
| |-- Storage Account (public with firewall rules)
| |-- ADF (public, no managed VNet)
|
NSG: Allow your IP for RDP/SQL, allow Azure servicesProduction Architecture (Secure)
VNet: vnet-prod (10.1.0.0/16)
|
|-- snet-privateendpoints (10.1.1.0/24)
| |-- pe-sql (10.1.1.10) → Azure SQL Database
| |-- pe-storage (10.1.1.11) → ADLS Gen2
| |-- pe-keyvault (10.1.1.12) → Key Vault
|
|-- snet-compute (10.1.2.0/24)
| |-- SHIR VM (10.1.2.20)
|
|-- snet-synapse (10.1.3.0/24)
| |-- Synapse Managed VNet endpoints
|
NSG on each subnet:
snet-privateendpoints: Allow 443/1433 from snet-compute and snet-synapse only
snet-compute: Allow 3389 from VPN/bastion only, allow 443 outbound
snet-synapse: Allow 443 outbound to private endpoints only
All public access DISABLED on SQL, Storage, Key Vault
ExpressRoute or VPN for on-premises connectivityCommon Networking Errors and Fixes
| Error | Cause | Fix |
|---|---|---|
| “Connection timed out” | NSG blocking the port, or no route exists | Check NSG rules, verify port is allowed, check if private endpoint exists |
| “No route to host” | Resource is in a different VNet with no peering | Set up VNet peering or use a public endpoint |
| “403 Forbidden” on Storage | Storage firewall blocking the request | Add VNet/subnet to storage firewall, or use private endpoint |
| “Cannot connect to SQL” | SQL firewall does not allow your IP or Azure services | Add client IP or enable “Allow Azure services” in SQL firewall |
| ADF pipeline “connection refused” | ADF not in managed VNet, private endpoint required | Enable managed VNet on ADF, create managed private endpoint |
| SHIR “offline” | VM NSG blocking outbound 443 | Allow outbound HTTPS (443) to Azure Service Bus |
| “DNS resolution failed” | Private endpoint created but DNS not configured | Enable private DNS zone integration |
Real-World Scenarios
Scenario 1: Data Pipeline with Full Network Security
On-Premises SQL Server
|
|── ExpressRoute ──→ VNet (snet-compute)
| |── SHIR VM (reads from on-prem SQL)
| |
| |── Private Endpoint → ADLS Gen2 (writes Parquet)
| |── Private Endpoint → Azure SQL (writes audit logs)
| |── Private Endpoint → Key Vault (reads passwords)
|
Synapse (Managed VNet)
|── Managed PE → ADLS Gen2
|── Managed PE → Azure SQL
NO public access anywhere. All traffic is private.Scenario 2: Multi-Environment with Peering
VNet-Hub (10.0.0.0/16) — Shared services
|── Azure Firewall
|── VPN Gateway → On-premises
|
|── Peering → VNet-Dev (10.1.0.0/16)
|── Peering → VNet-UAT (10.2.0.0/16)
|── Peering → VNet-Prod (10.3.0.0/16)
All traffic flows through Hub → Firewall → SpokeInterview Questions
Q: What is a VNet and why do you need it? A: A Virtual Network is an isolated private network in Azure. Resources inside a VNet can communicate with each other using private IPs. Without a VNet, resources use public endpoints, exposing them to the internet. VNets provide network isolation, security through NSGs, and private connectivity to Azure services.
Q: What is the difference between a Service Endpoint and a Private Endpoint? A: A Service Endpoint optimizes the route from your VNet to an Azure service (traffic stays on Azure backbone instead of public internet), but the service still has a public endpoint. A Private Endpoint gives the Azure service a private IP address inside your VNet, completely removing public access. Private Endpoint is more secure.
Q: What is an NSG and how do rules work? A: A Network Security Group is a set of rules that control inbound and outbound traffic. Each rule has a priority (lower number = higher priority), direction, source, destination, port, protocol, and action (allow/deny). Rules are evaluated in priority order, and the first matching rule wins. Default rules allow VNet-internal and outbound internet traffic.
Q: How does ADF/Synapse connect to resources privately? A: Enable Managed VNet on the ADF/Synapse workspace. Create Managed Private Endpoints to each data source (ADLS Gen2, Azure SQL, Key Vault). Approve the private endpoint connections on each target resource. All pipeline traffic then flows through private connections without touching the public internet.
Q: What is the difference between VPN Gateway and ExpressRoute? A: VPN Gateway creates an encrypted tunnel over the public internet — cheaper, easier to set up, but variable performance. ExpressRoute uses a dedicated private circuit from a telecom provider — more expensive, but offers consistent low latency and higher bandwidth. Use VPN for dev/small workloads, ExpressRoute for enterprise production.
Wrapping Up
Azure networking is the foundation that everything else sits on. Your perfectly designed pipeline means nothing if the network blocks the connection. Understanding VNets, subnets, NSGs, and private endpoints is not optional for production data engineering — it is essential.
The progression is clear: start with public access and firewall rules for development. Move to service endpoints for better routing. Graduate to private endpoints for production. Every step adds security without changing your pipeline code — only the network configuration changes.
And remember: the most secure network is one where nothing has public access. Private endpoints for everything. NSGs on every subnet. No shortcuts.
Related posts: – Azure Fundamentals (IAM, Subscriptions) – On-Premises Pipeline with SHIR – Cloud Computing Concepts – Azure Synapse Workspace Setup Guide – Integration Runtime Types
Naveen Vuppula is a Senior Data Engineering Consultant and app developer based in Ontario, Canada. He writes about Python, SQL, AWS, Azure, and everything data engineering at DriveDataScience.com.