The Definitive Guide - Networking Solutions on Azure

The definitive guide to networking solutions on Microsoft Azure. Every now and then the “Naive Junior” pops up with questions a lot of people have (they just don't ask). Use these interruptions to solidify your understanding.

Building intuition

Throughout this post, I'll draw analogies from the scenario below:

Picture a large condominium complex: each apartment is a resource (VM, pod, database), the hallways are the paths traffic takes, and the apartment number is the IP address. Each building has a numbering scheme for its apartments that says how many digits identify the “floor” (network) and how many identify the “apartment” (host). Let's call that scheme the Mask/CIDR (Classless Inter-Domain Routing); it's what defines how many floors each building has.

Now, if we have several buildings in the same complex, we need to make sure they can talk to each other, whether it's to visit a neighbor in another block, go to the management office, or just use the common areas. That's where routers come in: they work like the internal front desks that direct who goes to which building, making sure traffic leaves from the right place and reaches the right destination.

But moving around the complex isn't enough: you also need access control. In a real building, nobody wants strangers walking into the apartments, and in the digital world that's even more critical. That's why there are “digital doormen” like firewalls and NSGs, which decide who can and can't reach a resource. They're rules along the lines of: “only people on the list get in”.

On top of that, some buildings have exclusive access, like private garages or elevators that only open with a key card. On Azure, that's the equivalent of resources like Private Link, which let sensitive services be reached from inside the network without going over the public internet, as if there were a secret hallway leading straight to the apartment.

And what happens when the complex grows too big? When there are so many buildings that it's hard to keep everything organized? The answer is a Hub & Spoke model, where a central building (the Hub) concentrates shared services, such as security, monitoring and external connectivity, while the other buildings (Spokes) connect only to it, never directly to each other, which avoids a mess and reduces risk.

and if you don't define that scheme clearly, everything turns into chaos when you want to connect buildings (VNets) or open passageways (peering, VPN, ExpressRoute).

First solid concept: without a mask, an IP is ambiguous. 10.50.12.34 on its own doesn't tell you which block it belongs to, just like an apartment number when you don't know whether the first two digits are the floor or not. A /20 mask, for example, delimits the available space and prevents collisions when you expand.

Naive Junior

If I just grab a giant /16, doesn't that solve everything in one go?

You're just kicking the can down the road. Oversized blocks complicate peering, waste space and make security segmentation harder. Several well-defined blocks beat one confusing monolith.

Naive Junior

And changing it later is just editing a field, right?

Changing a range can mean recreating subnets, adjusting routes, updating NSGs and redoing Private Endpoints. In production, that costs time and adds risk. Plan early.

With that foundation in place, let's map where each component operates in the network layers so you can diagnose issues quickly.

OSI and TCP/IP models in Azure practice

You don't need to memorize every field of every header, but you do need to know “where you are” when I talk about a service:

The TCP/IP model simplifies things into 4 layers (Link, Internet, Transport, Application). In the cloud we work mostly at layers 3 through 7. When you pick a VNet, you're defining L3 boundaries; when you create an NSG, you're applying a policy that inspects mostly L3/L4 metadata; when you use an Application Gateway, you add L7 logic; and Front Door extends L7 out to the global edge.

Naive Junior

So that means if I mess up a route, I can't fix it in the WAF, right?

Correct. An L3 problem (routing) can't be fixed in an L7 component (WAF). Efficient troubleshooting starts by identifying the layer where the symptom shows up and checking the dependencies below it.

Quick mental map for troubleshooting:

1. Basic connectivity? (Ping/ICMP if enabled, or TCP SYN), L3/L4.
2. Port open / correct NSG rule?, L4 policy.
3. Load balancer distributing?, Health probe / L4.
4. Gateway/WAF routing the right path/host?, L7.
5. Global edge accelerating or blocking?, L7 + CDN/WAF policy.

Organizing your thinking by layer cuts down on random trial and error.

Guide Structure (Overview)

To make your journey easier, this guide is organized into progressive layers:

1. Networking Fundamentals

IP Addresses and CIDR Ranges

An IP address (Internet Protocol) is a logical identifier assigned to a network interface so packets can find their source and destination. Think of it as an apartment's full address, which the mail carrier needs to deliver a letter. It isn't physically burned into the cable; it's part of the packet header at the network layer (Layer 3 of the OSI model). There are two main versions in use: IPv4 (32 bits, dotted decimal format) and IPv6 (128 bits, hexadecimal format). IP works together with transport protocols (TCP/UDP), which use ports to tell applications apart. Without consistent IPs and range planning (CIDR), services can't find each other efficiently or scale securely.

IPv4 vs IPv6: Why are there two?

IPv4 (32 bits) was designed in the early days of the Internet, when nobody imagined billions of connected devices (smartphones, IoT sensors, vehicles, wearables). The total theoretical space (4.29 billion) gets eaten up quickly by reservations, private blocks and uneven distribution. To prevent an addressing collapse, conservation mechanisms emerged.

IPv6 (128 bits) expands the space to astronomical numbers (≈3.4×10^38 addresses). Beyond sheer quantity, it improves scope definition, autoconfiguration (SLAAC) and routing simplicity, and removes the need for NAT to scale. Adoption is slow, though, because of IPv4 legacy: tools, applications and infrastructure that still rely on the old standards.

IP Types (Public, Private, Static, Dynamic)

1. Private (RFC1918 / internal ranges): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Used inside local networks; not routable on the Internet.
2. Public: Visible on the Internet. On Azure, associated with resources (VM, Load Balancer, Front Door) for external exposure.
3. Static: Doesn't change. Required for allowlists, fixed DNS, certificates.
4. Dynamic: Assigned on demand. Good for temporary or test environments.
5. Ephemeral (Outbound): On Azure, the public IP used temporarily for outbound traffic (SNAT) when there's no dedicated NAT Gateway.

How the world dealt with IPv4 scarcity

To reduce consumption of public addresses:

• NAT (Network Address Translation): Translates internal private IPs to a single public IP (or a small set) on the way out. Lets hundreds of devices share a single external IP.
• PAT (Port Address Translation): Uses distinct ports to multiplex multiple connections over one IP.
• Carrier Grade NAT (CGNAT): ISPs aggregate multiple subscribers behind additional NAT layers, delaying the exhaustion of public blocks.
• CIDR: Allows flexible blocks (not locked into classes A/B/C) for better utilization and route aggregation.
• NAT Gateway (Cloud): On Azure, provides scale and consistency for outbound SNAT without consuming a public IP per VM.

Naive Junior

If NAT solves the problem, why waste time adopting IPv6?

NAT is a band-aid; it breaks the end-to-end principle, makes telemetry harder, complicates traffic troubleshooting and requires extra translation for protocols that embed addresses (e.g., SIP, FTP). IPv6 brings back the direct model: every device with a unique global address.

Reverse Proxy vs NAT

A Reverse Proxy (e.g., Nginx, Envoy, Azure Application Gateway) operates at the application layer (L7). It terminates HTTP(S) connections and can rewrite headers, load balance, authenticate and inspect. It's not the same thing as NAT: NAT changes addresses/ports at lower layers (network) without understanding the content.

Dual-Stack and Gradual Transition

Modern environments adopt dual-stack (IPv4 + IPv6) to ensure compatibility and prepare for future scale. On Azure you can enable IPv6 on:

• Specific subnets
• Dual-stack Load Balancer (Standard)
• Application Gateway (latest SKUs)

Recommended strategy:

1. Plan documented IPv6 ranges (don't generate them randomly with no traceability).
2. Enable it on external components first (global edge) while keeping the interior on IPv4.
3. Monitor metrics (percentage of IPv6 requests, comparative latency).

Architectural Implications on Azure

• Monitoring: Flow Logs and diagnostics need to include both protocols for a complete picture.
• Security: NSGs and Firewall must have explicit rules for IPv6 (don't assume implicit blocking).
• Cost: Reduce reliance on a public IP per VM by using NAT Gateway + Front Door/Application Gateway to centralize exposure.
• Scalability: IoT services or millions of clients benefit from direct IPv6 addressing.

Naive Junior

So first I should get my IPv4 nice and tidy so I don't get tangled up, and then turn on IPv6 wherever it makes sense?

Exactly. Start with rigorous IPv4 planning (CIDR with no overlap). Then evaluate where IPv6 pays off (edge, large-scale public APIs). Dual-stack avoids friction and paves the way for modernization.

An IPv4 address is made up of 32 bits, represented as A.B.C.D. The CIDR (/n) says how many bits make up the network portion. Example: 10.0.0.0/16 reserves 16 bits for the network and 16 for hosts.

Avoid picking /16 out of habit; it makes peering harder and fragments multi-region planning.

Mask and logical separation

The mask defines “how many apartments per floor”. Planning subnets that are too “tight” leads to IP exhaustion fast (e.g., AKS consuming IPs for pods). Plan for peaks, not for the current average.

RFC1918 (Private Ranges)

Azure uses the same standard private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Avoid overlap between on-premises and cloud to keep routing simple.

IPv6 on Azure

Support is gradually available for load balancers, Application Gateway and dual-stack VNets. Useful for future scale and compliance; still rarely essential in internal environments.

2. Azure Core Components

Virtual Network (VNet)

An isolated logical perimeter. You pick one or more ranges (e.g., 10.40.0.0/16) and subdivide them. Plan VNets by domain: vnet-core, vnet-analytics, vnet-edge.

Subnet

Segments that separate functions. Good practice: one subnet for the front end, another for data, another for integration/services (e.g., Private Endpoints), and another for security (Firewall/Azure Bastion). Each subnet takes a slice of the VNet's CIDR range.

Naive Junior

But can't I just put everything in the same subnet and move on with my life? Seems like less work...

Separate subnets reduce the blast radius. If a bad security rule or route hits the application subnet, the data subnet stays intact. It also makes it easier to apply targeted NSGs (e.g., the database only accepts traffic on port 1433 from the app subnet). In larger environments, purpose-built subnets save you from an endless list of rules full of exceptions.

NSG (Network Security Group)

An L4 filter (and partly L3). Each rule has: priority (lower number = evaluated first), direction (Inbound/Outbound), protocol (TCP/UDP/Any), source, destination, port and action (Allow/Deny).

Naive Junior

What if I just open everything (0.0.0.0/0) to test quickly and close it later? I promise I'll close it...

Opening everything “temporarily” becomes a forgotten rule. Apply the principle of least privilege from day one. For debugging, create a specific rule with a documented expiration. Automate the cleanup in your pipeline.

Simplified rule example (concept):

{
  "name": "Allow-Web-In",
  "priority": 200,
  "direction": "Inbound",
  "protocol": "Tcp",
  "sourcePortRange": "*",
  "destinationPortRange": "443",
  "sourceAddressPrefix": "Internet",
  "destinationAddressPrefix": "VirtualNetwork",
  "access": "Allow"
}

Route Table (UDR)

Changes the next hop for specific destinations. Useful for inspecting traffic in a firewall (Virtual Appliance) or steering routes to on-premises via VPN/ExpressRoute. Plan to avoid asymmetry: going out one path and coming back another causes dropped sessions.

Naive Junior

If I send everything through the firewall, it's more secure, right?

Not always. Routing irrelevant traffic (e.g., internal cache communication) adds latency and cost. Only define routes for traffic that needs inspection or controlled egress.

Public vs Private IP

Prefer exposing services through a delivery layer (Front Door, Application Gateway) and using Private Endpoints for PaaS. A public IP directly on a VM is rarely necessary.

Azure Bastion

Enables RDP/SSH to VMs without exposing public ports. Reduces the attack surface.

3. Private and Hybrid Connectivity

Site-to-Site VPN

An IPsec tunnel over the public Internet connecting a data center (or office) to Azure. Good for getting started quickly. Limitations: variable latency, jitter spikes, and throughput that depends on the gateway SKU and local bandwidth.

Naive Junior

How do I know when it's time to ditch the VPN and move to something more professional?

Migrate when you need: a strict SLA, consistently low latency, growing traffic (hundreds of Mbps), or compliance requirements (ExpressRoute offers additional isolation).

ExpressRoute

A private connection provisioned by a telecom partner. It offers stable latency and guaranteed bandwidth (SKUs vary). It supports two main peerings: Private (access to VNets) and Microsoft (access to public services like M365 without traversing the Internet). Plan for redundancy (circuit pairs) to get real high availability.

Naive Junior

And can I plug ExpressRoute straight into a service like Storage without going through a VNet?

For PaaS services you'll usually use Private Endpoints inside the VNet. ExpressRoute gives you the private path to the VNet; from there, the private endpoint completes the journey.

Virtual WAN

Orchestrates regional hubs and simplifies multi-site connections, SD-WAN and centralized policies.

Peering

Connects VNets without a gateway. Private traffic, low latency. Plan a hierarchy (Hub-Spoke) instead of a full mesh.

Private Link

Places a private interface for a PaaS service inside your VNet. Avoids public exposure and simplifies compliance.

4. Advanced Delivery Services

Application Gateway

Path/host-based routing, SSL offload to lighten the backend load, Web Application Firewall (OWASP) support, redirects and header rewriting. Plan for zones for regional high availability and size the SKU to your actual volume.

Naive Junior

Can I use it as a CDN for big files too?

No. For CDN and global acceleration, use Front Door or Azure CDN. Application Gateway is regional and focused on inspection/application routing.

Front Door

A global edge with distributed POPs, caching (dynamic and static acceleration), routing by geography, priority or latency, and protection against volumetric attacks. Pair it with WAF policies.

Naive Junior

If I use Front Door, do I still need Application Gateway?

It depends: Front Door for global distribution and acceleration; Application Gateway for detailed regional logic (complex internal paths, deep WAF). Some architectures chain both.

Load Balancer

High throughput for non-HTTP traffic. Essential for AKS (LoadBalancer-type Services) and replicated databases.

Traffic Manager

DNS-based; it pairs with Front Door (Front Door for HTTP, Traffic Manager for multi-protocol or fallback scenarios).

5. Network Security

Azure Firewall vs NVA

A managed firewall (Azure Firewall) reduces operational overhead (patching, autoscaling, policy integration). NVAs (Fortinet, Palo Alto) provide specialized features (e.g., advanced IPS, proprietary layer 7 filtering). Build a requirements matrix (TLS inspection, Threat Intel, cost, in-house skills) before deciding.

Naive Junior

If I just buy the most expensive one, does that solve everything without me having to think?

An expensive tool used wrong is just waste. Operational simplicity often delivers more real security than unmanaged complexity.

DDoS Protection

An extra layer of protection for critical public resources (Front Door + DDoS = strong defense).

Zero Trust

Segment subnets, limit East-West flows, centralize inspection, and require strong authentication for administration (Bastion + RBAC + PIM).

Defender for Cloud

Continuous posture management and anomaly alerts (e.g., unexpected traffic to unused ports).

6. Observability

Network Watcher

Practical tools: Topology (visual map), Packet Capture (deep debugging), Flow Logs (NSG traffic), Connection Monitor (latency and availability). Enable only what you need to balance cost and value.

Naive Junior

If I turn on every single log, I'll never have a doubt about anything ever again, right?

Too much data without analysis turns into noise. Start with the essential flow (NSG Flow Logs + key metrics) and evolve as real needs arise.

Logs and Metrics

Consolidate them in a Log Analytics workspace. Query traffic with Kusto to spot patterns.

7. Performance

Cut unnecessary round trips (hairpinning) with an efficient Hub-Spoke design. Use CDN/Front Door for static content. Tune BGP on ExpressRoute so routes are correct.

8. Architectural Patterns

Hub-Spoke

Hub = connectivity and security. Spokes = workloads. Makes governance, isolation and scalability easier.

Selective mesh

Restricted peering between a few spokes where low latency is critical.

Landing Zones

The recommended foundation (CAF) for enterprise growth, including identity, policy and standardized networking.

Multi-Cloud

Connect Azure to another cloud with ExpressRoute + a partner, or VPN. Plan your CIDR reservations.

9. Operations & Governance

IP inventory, IaC automation, rule reviews, cost analysis, and policy (Azure Policy) to prevent non-standard resources.

10. Final Checklist

Conclusion

Networking on Azure isn't just creating a VNet and moving on; it's about composing layers: isolation, delivery, security, observability and evolution. Planning CIDR and topology well saves you from expensive rework. Adopt hub-spoke, use Private Link for sensitive data, centralize logs and apply adaptive security.

Start small, record your decisions (design docs), automate early and review regularly. That's how you build a resilient, scalable foundation.