Azure Networking Fundamentals

Building a secure, performant, and reliable application in the cloud begins with its network. Azure networking provides the connective tissue that binds your compute, data, and user access into a coherent system. Mastering these fundamentals is not just about passing a certification; it's about designing resilient architectures, controlling costs, and ensuring your services are both accessible and protected in a global landscape.

1. Virtual Networks: The Foundation of Your Private Cloud

Every Azure resource that needs to communicate privately—be it a virtual machine, a Kubernetes cluster, or an App Service environment—resides within a Virtual Network (VNet). Think of a VNet as a logically isolated section of the Azure cloud dedicated entirely to your organization. It is the fundamental building block for your private network, allowing resources to communicate securely with each other, the internet, and your on-premises networks.

A VNet is defined by an address space, which is a range of private IP addresses. You use Classless Inter-Domain Routing (CIDR) notation to define this space, such as 10.0.0.0/16. Within this address space, you create subnets to segment your network. A subnet is a subdivision of your VNet's IP range, like 10.0.1.0/24. Subnets allow you to organize resources by function or security requirement—for example, placing web servers in one subnet and database servers in another. This segmentation is a critical first step in applying security controls and routing policies, enabling a zero-trust network model where communication between segments is explicitly allowed rather than implicitly trusted.

2. Controlling Traffic Flow and Security

Once your network is segmented into subnets, you must control the traffic that flows in, out, and between these segments. This is achieved through two primary services: Network Security Groups (NSGs) and Azure Firewall.

An NSG is a basic, stateful firewall that operates at the subnet or individual network interface level. It contains security rules that allow or deny traffic based on source and destination IP address, port, and protocol. For instance, you could create an NSG rule for your web server subnet that allows inbound TCP traffic on port 443 (HTTPS) from the internet but denies all other inbound traffic from the public internet. NSGs are simple and effective for basic layer 3 and 4 (network and transport layer) filtering.

Azure Firewall is a fully stateful, network-level firewall-as-a-service. It provides more advanced capabilities than an NSG, including threat intelligence-based filtering, FQDN (Fully Qualified Domain Name) filtering for network rules, and support for outbound SNAT (Source Network Address Translation) and inbound DNAT (Destination Network Address Translation). A key architectural decision point is using Azure Firewall to govern traffic between subnets (east-west) and to/from the internet (north-south) from a central, managed service, rather than managing dozens of individual NSGs. It is your centralized policy enforcement point for a hub-and-spoke network topology.

3. Connecting to the Outside World: VPNs and Dedicated Links

Most enterprise environments require a secure bridge between Azure and on-premises data centers or branch offices. Azure offers two principal solutions for this hybrid connectivity.

VPN Gateway is a service that enables you to send encrypted traffic across the public internet. You deploy a VPN Gateway into a dedicated subnet (often named 'GatewaySubnet') within your Azure VNet. It can establish two types of connections: a Site-to-Site (S2S) VPN to connect your entire on-premises network to Azure, and a Point-to-Site (P2S) VPN to allow individual client devices to connect securely. While cost-effective and quick to set up, a VPN Gateway's throughput, latency, and availability are dependent on the public internet.

For mission-critical, high-performance requirements, ExpressRoute is the solution. It lets you create private connections between your on-premises infrastructure and Azure datacenters through a connectivity provider. This connection does not go over the public internet, offering more reliability, faster speeds (up to 100 Gbps), lower and consistent latencies, and higher security. ExpressRoute is ideal for scenarios like data migration, hybrid applications with tight coupling, or meeting strict regulatory compliance. You can choose from ExpressRoute tiers like Local, Standard, or Premium, which offer different geographic reach and feature sets.

4. Distributing Traffic for Scale and Reliability

To ensure your applications are scalable and highly available, you need to distribute incoming network traffic across multiple backend resources. Azure provides layered load balancing services.

Azure Load Balancer operates at layer 4 (transport layer—TCP/UDP). It distributes inbound and outbound flows to backend pool instances based on configured rules and health probes. It comes in two SKUs: Basic, which is free but limited in features and scope, and Standard, which is the recommended, feature-rich version for production workloads. A Public Load Balancer can provide outbound connections for VMs inside your VNet and balance internet traffic to your VMs. An Internal (or Private) Load Balancer balances traffic inside a VNet, such as between your web tier and business logic tier in a multi-tier application.

For more intelligent, application-aware traffic distribution, you use Azure Application Gateway. This is a web traffic load balancer that operates at layer 7 (application layer). Its most powerful feature is path-based routing, which can direct traffic to different backend server pools based on the URL of the request (e.g., sending /api/* to an API server pool and /images/* to a static content pool). It also includes a Web Application Firewall (WAF) SKU, which provides centralized protection for your web applications from common exploits like SQL injection and cross-site scripting (XSS).

5. Enabling Discovery and Private Connectivity

The final core components involve making your services discoverable and connecting VNets seamlessly.

Azure DNS is a hosting service for DNS domains. You can use it to manage your public DNS records with the same credentials, APIs, and billing as your other Azure services, benefiting from Azure's global network of name servers for fast resolution and high availability. For private name resolution within your virtual networks, you configure Private DNS zones. This allows you to use custom domain names (like db01.internal.contoso.com) for your Azure resources without exposing those names to the public internet, simplifying application configuration.

Virtual Network Peering allows you to connect two Azure VNets seamlessly. Once peered, the VNets appear as one for connectivity purposes. Resources in either VNet can communicate directly with each other using private IP addresses, with traffic routed through the Microsoft backbone infrastructure—never over the public internet. This is a fundamental technique for creating hub-and-spoke networks, where a central "hub" VNet contains shared services (like Azure Firewall or a VPN Gateway), and multiple "spoke" VNets, each hosting different workloads, are peered to it. Peering is non-transitive; if VNet A is peered to VNet B, and VNet B is peered to VNet C, VNet A cannot talk to VNet C unless they are directly peered.

Common Pitfalls

1. Overlooking Subnet Sizing: Allocating a /24 subnet (251 usable addresses) might seem sufficient initially, but certain Azure services (like Virtual Network Gateways, Azure Bastion, or App Service Environments) require dedicated subnets of specific, often large, sizes. Failing to plan for growth and service requirements can lead to a painful and complex network re-addressing project later. Always plan subnets with future expansion and service integration in mind.

1. Misconfiguring NSG Rules and Priorities: NSG rules are evaluated in order of priority, and the first rule that matches is applied. A common mistake is creating a broad "Deny All" rule at a high priority (e.g., priority 100) that blocks all traffic, then placing specific "Allow" rules at a lower priority (e.g., 200) that are never evaluated. Always structure your rules with lower priority numbers (higher priority) for specific allows/denies and the highest number for the implicit "Deny All" that exists at the bottom of every NSG.

1. Confusing Load Balancer Types: Using a Basic Load Balancer for a production application because it's "free" can lead to feature limitations, such as no support for Availability Zones or backend pools that span virtual networks. For any serious workload, start with the Standard SKU for Load Balancer and Application Gateway to access the full suite of availability, scaling, and security features.

1. Ignoring Asymmetric Routing with NVA/Gateways: When you introduce a network virtual appliance (NVA) or an Azure Firewall into a subnet's route table to direct traffic (User-Defined Routes), you must ensure that return traffic flows back through the same appliance. If traffic flows out through the firewall but the response returns via a default route directly to the source, the connection will fail. This is a fundamental routing principle that must be validated in any design using forced tunneling or NVAs.

Summary

• An Azure Virtual Network (VNet) and its subnets form the foundational private address space where your resources reside and communicate, with segmentation being key to security and management.
• Network Security Groups (NSGs) provide essential layer 3/4 filtering, while Azure Firewall serves as a centralized, managed service for advanced network and application-level policy enforcement across your entire estate.
• VPN Gateway offers cost-effective internet-based hybrid connectivity, while ExpressRoute provides private, high-performance, and reliable dedicated circuits for mission-critical connections to on-premises networks.
• Traffic distribution is layered: use Azure Load Balancer (Standard SKU) for high-performance layer 4 scenarios, and Azure Application Gateway for layer 7, application-aware routing and integrated web application firewall (WAF) protection.
• Use Azure DNS for public domain management and Private DNS zones for internal name resolution, and connect VNets directly and securely using Virtual Network Peering to build scalable hub-and-spoke architectures.