Day 5: Azure Virtual Network (VNet) Explained

Mastering Azure networking fundamentals is a crucial milestone for any cloud or DevOps engineer. Concepts like Virtual Networks, Subnets, Routing Tables, Network Security Groups (NSGs), and Application Security Groups (ASGs) form the architectural backbone of secure, scalable cloud infrastructure. This chapter breaks down these core networking primitives using real-world enterprise analogies and step-by-step architectural models.

1. Why Do We Need Virtual Networks? (The Multi-Tenant Security Problem)

To truly understand why cloud providers invented Virtual Networks (VNets)—known as Virtual Private Clouds (VPCs) in AWS—we must examine what happens in a shared public cloud infrastructure if this logical isolation layer does not exist.

The Shared Infrastructure Dilemma

Imagine two major enterprise corporations, Nike and Puma, employing DevOps engineers who independently provision virtual machines in the same public cloud region and availability zone (e.g., East US, Availability Zone 1).

Without logical network isolation:

1. Azure's Resource Manager processes both provisioning requests.
2. Because both requests target the same physical data center and availability zone, the underlying cloud fabric might place Nike's VM and Puma's VM on the exact same physical server hardware (e.g., Physical Server X).
3. Critical Security Risk: If Puma's virtual machine suffers a security compromise or is hacked, the attacker gains a foothold directly inside that physical machine. From there, pivoting across the shared hypervisor or adjacent local memory space to attack Nike's virtual machine becomes dangerously straightforward.

The Cloud Provider Solution: Logical Isolation (VNets)

To eliminate this risk, cloud providers introduced Virtual Networks (VNets). A VNet is a secure, isolated private network dedicated exclusively to your subscription within the public cloud.

• Nike's VNet: Azure carves out a strictly bounded logical network perimeter for Nike.
• Puma's VNet: Azure assigns a completely separate logical network perimeter for Puma.
• Guarantee: Even if Nike and Puma VMs reside in the same physical data center, their network traffic and hypervisor communication paths are strictly separated by software-defined networking (SDN) boundaries.

2. Core Mental Model: The Enterprise Building Analogy

Think of an Azure Virtual Network (VNet) as a secure corporate campus or a massive multi-story office building purchased by an enterprise (e.g., Nike's XYZ Project).

• The VNet: The entire office building with a specific total property size (measured by IP addresses via CIDR).
• Subnets: Individual departments or floors inside the building (e.g., Floor 1 for Web Reception, Floor 2 for Business Logic, Floor 3 for Secure Vault / Databases).
• Network Security Groups (NSGs): Security guards stationed at department doorways checking employee badges and enforcing rules (e.g., "No internet traffic allowed into the database vault").
• Application Security Groups (ASGs): Special employee tags or role badges (e.g., "Web Developer badge" vs. "Database Admin badge") that let security guards apply fine-grained access rules to specific groups of servers rather than raw IP addresses.

3. Defining VNet Size and IP Architecture (CIDR)

Once you decide to create a VNet for an organization project (such as Nike's XYZ Project), you must define its size. The size of a VNet is measured by the number of IP addresses it contains, which directly dictates how many resources (VMs, databases, container instances) you can deploy.

• CIDR Standard: Azure uses Classless Inter-Domain Routing (CIDR) notation to define network size.
• Common Enterprise Size: A very standard production VNet allocation is a /16 CIDR block.
  • /16 VNet = 65,536 total available IP addresses.

Note: Cloud providers like Azure and AWS provide default VNets and subnets when you spin up quick test resources (like a standalone Jenkins server), but enterprise production environments always require custom-designed VNets and subnets tailored to organizational compliance.

4. Subnetting: Breaking Down the VNet

Having one massive VNet containing 65,536 IP addresses without internal divisions is inefficient and insecure. Different applications have vastly different exposure requirements:

• Web Applications: Must be accessible from the public internet (HTTP/HTTPS traffic).
• Business Logic / App Servers: Handle backend processing; should communicate with web servers and databases, but remain shielded from direct public internet access.
• Databases: Highly sensitive data stores; must never be accessible directly from the public internet.

To achieve this, we split the VNet into logical subdivisions called Subnets.

Advantages of Subnetting

1. Traffic Segregation: Isolate public-facing workloads from sensitive backend datastores.
2. Granular Security Controls: Apply tailored firewall rules and security policies to individual subnets rather than managing every instance individually.

5. Network Security Groups (NSGs)

How do we enforce who can talk to what across these subnets? Enter Network Security Groups (NSGs).

An NSG acts as a virtual firewall containing a list of security rules that allow or deny inbound and outbound network traffic to resources connected to Azure VNets.

Best Practice Placement

• While you can attach an NSG to an individual virtual machine instance (such as a standalone Jenkins server), enterprise best practice is to apply NSGs at the Subnet level.
• When applied to a subnet containing 100 database instances, every single database instantly inherits those security rules without individual configuration overhead.

Example NSG Rule Logic

• Web Subnet NSG: Allow inbound traffic on ports 80 and 443 from Any (Internet).
• DB Subnet NSG:
  • Deny all inbound traffic from Internet (0.0.0.0/0).
  • Allow inbound traffic only from the CIDR range of the App Subnet (10.0.3.0/24).

6. Enhancing Security with Application Security Groups (ASGs)

While NSGs operate using raw IP addresses or CIDR blocks, managing large fleets of dynamic virtual machines via CIDR ranges can become complex. This is where Application Security Groups (ASGs) come in.

ASGs allow you to group virtual machines logically by application profile or workload role, regardless of their IP addresses or subnet placement.

NSG vs. ASG Comparison

Real-World Workflow with NSG + ASG

Suppose your App Subnet contains both web application servers and backend business logic servers. You want only the business logic servers to communicate with the DB Subnet, blocking regular web servers from touching the database.

1. Create an ASG named BusinessLogic-ASG and assign your 5 business logic VMs to it.
2. In your database subnet's NSG rule, instead of specifying a broad subnet CIDR block, define the source directly as BusinessLogic-ASG.
3. Result: Even within a shared subnet or multi-tier environment, precise workload-level isolation is achieved effortlessly.

7. Summary of Azure Networking Components

8. Summary and Key Takeaways

• Isolation is Paramount: Public clouds achieve multi-tenant security by isolating customer workloads into dedicated Virtual Networks (VNets), preventing cross-tenant data exposure on shared physical server hardware.
• Size via CIDR: VNet and subnet capacities are measured using IP address blocks defined via CIDR notation (e.g., /16 for large VNets, /24 for subnets).
• Default vs. Production: While Azure provisions default VNets for quick onboarding, enterprise environments require custom VNet architectures tailored to security compliance.
• Subnet Architecture: Splitting VNets into specialized subnets (Web, App, DB) creates logical boundaries that prevent direct internet exposure for backend data stores.
• Subnet-Level NSGs: Always prefer applying Network Security Groups (NSGs) at the subnet level to streamline security policy enforcement across large resource fleets.
• ASGs Simplify Rules: Application Security Groups (ASGs) elevate NSGs from rigid IP/CIDR rules to intelligent, role-based workload tagging.
• Combined Power: Enterprise cloud security relies on combining VNets, Subnets, NSGs, and ASGs into a defense-in-depth architecture.
• Traffic Flow Control: Route tables and User Defined Routes (UDRs) dictate the precise path network packets travel between subnets and network appliances.