The Azure Software Defined Network Environment Overview

It is incredibly common for training courses to dive straight into the "how-to" clicking steps without explaining the "why" or the actual mechanics of what is happening under the hood. When you are just told to click A to create B, it makes troubleshooting feel like total guesswork when things don't work.

Since your notes are focused exactly on this layer right now, let’s look at the big picture of Software-Defined Networking (SDN) vs. traditional networking so you have that solid baseline for everything else you build.

The Big Shift: Traditional vs. Cloud SDN

In a traditional physical datacentre, networking is tied to physical hardware. If you wanted to route traffic or change an IP address, data had to pass through physical switches, routers, and firewalls.

In the cloud, everything is software. When you deploy a Virtual Network (VNet), you aren't partitioning a physical switch in a server room. Instead, you are writing a piece of configuration data into Microsoft's software controller.

To understand how Azure handles your traffic statefully behind the scenes, engineers break SDN down into three distinct operational layers (or "planes"):

[ Management Plane ] --> Azure Portal / Azure CLI (Your instructions)

[ Control Plane ] --> Azure Resource Manager (The brain/orchestrator)

[ Data Plane ] --> The Host Hypervisor / Invisible Virtual Switch

(Where your actual Port 80 packets flow)

1. The Management Plane (The Interface)

This is where you sit. When you log into the Azure Portal, run a command in WSL2 using az cli, or use the "Purpose-Driven" dropdown for Bastion, you are interacting with the Management Plane. You are simply defining what you want your network to look like.

2. The Control Plane (The Brain)

When you hit "Save" or "Create," your request goes to the Azure Resource Manager (ARM). The Control Plane takes your design and figures out how to make it a reality. It tells the physical datacentres: "We need a private space for this user, and it needs to map these specific public IPs to these private internal locations."

3. The Data Plane (The Muscle)

This is where the actual work happens, and it is exactly what handled your Port 80 web response.

Your Virtual Machines run on massive physical server hardware called Hypervisors.

The primary hardware powering the hypervisor is the CPU (Central Processing Unit) and System RAM, not the GPU.

To bridge this back to foundational hardware architecture and how it maps to Azure's Software-Defined Networking (SDN), let’s look at the distinct roles these components play inside the datacenter.

1. The Host CPU: The Real Engine of the Hypervisor

The hypervisor is an operating system layer (Microsoft uses a deeply customized version of Hyper-V) running directly on the bare-metal blade servers in the datacenter.

Management and Virtualization: The host CPU is what handles the complex calculations required to slice up physical hardware into multiple isolated virtual machines.
The Software Switch (Data Plane): That "invisible virtual switch" processing your network traffic is a software program running execution threads. The host CPU processes those network packets, reads the SDN software rules, and alters the packet headers (like changing your private 10.x.x.x address to your Public IP on the way out).

2. What about the GPUs?

Graphics Processing Units (GPUs) are specialized hardware clusters. In a cloud datacenter, they are not used to run the background network fabric, the hypervisor, or general VM management.

Instead, GPUs are treated as add-on accelerators. They excel at mathematical parallel processing—handling thousands of tiny tasks simultaneously. Microsoft installs massive arrays of high-end GPUs inside specific server racks strictly to handle workloads like:

Artificial Intelligence (AI) and Large Language Model (LLM) training.
Complex 3D rendering and CAD applications.
Heavy data analytics and scientific simulations.

If you deploy a standard virtual machine for learning, networking labs, or hosting a standard web server, that VM is running entirely on traditional host CPUs. The hypervisor doesn't utilize or need a GPU to manage your VNets, Bastion, or NAT Gateway.

Connecting to Your Notes: Accelerated Networking

There is one important hardware exception regarding networking that ties directly into your study strategy of using a larger VM size (like the Standard_D2s_v3) to study Accelerated Networking.

Normally, as your traffic leaves the VM, the host CPU has to do all the heavy lifting to process the virtual switch rules. This adds latency and uses up CPU cycles.

When you turn on Accelerated Networking, Azure bypasses the host CPU's software switch entirely. Instead, it offloads the network routing rules directly into a specialized physical network card called an ASIC (Application-Specific Integrated Circuit) or a SmartNIC (Smart Network Interface Card) installed on the server blade.

So, while GPUs accelerate graphics and AI, it is SmartNICs (specialized network chips) and CPUs that handle the heavy lifting for Azure's Software-Defined Networking!

Where the record lives: It lives inside the central Azure SDN database (Control Plane), which programs the mapping directly into the host hypervisor's virtual switch software (Data Plane).

Why DHCP/DNS aren't needed: Traditional hardware networks use DHCP dynamic polling to find out "who is where." In an SDN cloud, Azure is the network, the switch, and the layout designer all at once. It dictates the placements from the top down, so it never has to guess or search for where a resource is located.

Inside every single hypervisor is an incredibly advanced, invisible virtual switch software managed natively by Azure.

When a packet comes into the datacenter for your web server, the Control Plane has already programmed the virtual switch to know exactly who owns that Public IP.
The virtual switch translates the packet on the fly and drops it into your VM's private NIC.
When the VM replies, the virtual switch catches it, checks its "state table" to see if it belongs to an open conversation, translates the address back to your Public IP, and sends it out.

Why this makes the NAT Gateway vs. Inbound traffic clear

Now that you see the SDN layer, you can look at your devices as software instructions given to that invisible virtual switch:

Attaching a Public IP to a VM: This is an instruction that tells the virtual switch: "If traffic comes in on this specific public identity, translate it to this VM's 10.x.x.x private address, and track the reply statefully."
Attaching a NAT Gateway to a Subnet: This is a completely separate instruction that tells the virtual switch: "If any VM on this subnet tries to start a new conversation out to the internet, intercept it and mask it with the NAT Gateway's IP instead."

Because it is all software-defined, these two rules sit side-by-side without crashing into each other. The virtual switch simply looks at who started the conversation and applies the correct software rule!

Let’s break this down strictly using the concepts you have already covered in your notes—specifically focusing on the Resource Group, the NAT Gateway, and your virtual machine—so we can demystify how that IP address changes.

To answer your question directly: No, the Resource Group (RG) is not part of the network fabric, and it does not handle any SNAT or network translation. Here is exactly what the Resource Group is, what the "fabric" actually means in your labs, and how the VM changes that address.

1. What the Resource Group (RG) Actually Is

In Azure, a Resource Group is strictly a logical folder used for management, billing, and grouping resources together so you can delete them all at once (like running your az group delete --name WinVM_RG command).

The Resource Group does not have any network intelligence, routing capabilities, or data-plane awareness. It has absolutely nothing to do with processing packets, routing data, or translating IP addresses. It is just an organizational container.

2. What is the "Fabric"? (The Hidden Virtual Switch)

When you build a Virtual Machine in Azure, your VM’s network interface card (NIC) is plugged into a virtual network. But what is hosting that virtual network?

Behind the scenes in the Microsoft datacenter, your VM is running on a massive physical server (a hypervisor). The underlying software architecture that manages these physical servers, the hypervisors, and the invisible virtual switches connecting them is what engineers call the Azure SDN (Software-Defined Networking) Fabric.

For your notes, you can think of the "fabric" simply as Azure’s invisible, built-in network infrastructure. It is the native environment that hosts your VNet.

3. How the Address Changes on the Way Out (Without an RG or NAT Gateway)

Because you haven't covered Load Balancers yet, let's look strictly at the setup you did configure in your "Azure DNS" notes: a single Virtual Machine that has an Internal Private IP (10.x.x.x) and an attached Public IP (PIP) resource instance.

When that external customer hits your web server on Port 80, the packet comes into the Azure infrastructure, gets directed to your VM, your VM processes it, and now your VM needs to reply.

Here is how that reply packet goes out to the internet:

The VM Sends the Packet: Your Windows/Ubuntu VM creates a reply packet. The VM only knows about its own internal private identity, so the packet says:
- Source: 10.x.x.x (Private IP)
- Destination: Your home workstation's public IP.
The Packet Hits the Virtual Switch: The packet leaves the VM's OS and hits Azure's invisible infrastructure (the fabric/virtual switch) that your VM is plugged into.
The Stateful Translation Step: Because this reply is part of a session that originally came in through your Public IP, Azure's built-in network infrastructure automatically catches the packet. It says: "I remember this conversation. This belongs to the Public IP attached to this VM."
The Address is Rewritten: Right there at the virtual network boundary, Azure’s infrastructure rewrites the packet's source header, changing it from 10.x.x.x to your explicit public IP identity (20.107.172.166).

This translation is a built-in, native characteristic of attaching a Public IP resource directly to a VM's network interface. It happens entirely in the background network layer, completely bypassing your NAT Gateway, and has nothing to do with the Resource Group folder.

ONLY TRAFFIC ORIGINATING FROM THE HOST GOES VIA THE GATEWAY!!

TRAFFIC BEING ANSWERED FROM OUTSIDE DOES NOT GO VIA THE GATEWAY, BUT VIA THE Azure fabric virtual switch SDN layer!!

The NAT Gateway stays completely asleep during this whole process because it only activates when the VM itself starts a brand-new conversation outward.

“Perfect. It's difficult to stop an older tech from thinking in isolation about solo "hardware" elements, which are just abstractions in SDN really. They serve as an identifier of function more so, I suppose, so humans who learned on real hardware can visual "equipment function"

You have hit the absolute nail on the head. That is a profound insight, and it is exactly how modern cloud architecture is designed.

In Software-Defined Networking (SDN), a "NAT Gateway" or a "Bastion Host" isn't a metal chassis sliding into a server rack. It is an abstraction layer—a software microservice running on an underlying compute cluster.

Microsoft explicitly names and designs these services around legacy hardware concepts for two vital reasons:

Human Mental Models: It allows engineers who spent decades working with physical Cisco routers, ASA firewalls, and hardware KVM switches to instantly understand the functional purpose of the resource without needing a degree in distributed systems software design.
Separation of Concerns: It lets you treat network functions as modular, Lego-like building blocks in your architecture.

Since you are mapping out how these abstractions interact, here is a quick conceptual diagram of how your notes on VNet Architecture, Bastion, and NAT Gateway look when visualized as functional "zones" rather than physical boxes:

The 3 Big "Equipment Functions" in Your Notes

To help bridge the gap between old-school hardware and cloud abstractions for your study guide, you can map them out like this:

1. The Virtual Network (VNet)

The Hardware Legacy: A physical enterprise network switchboard, patch panels, and copper cabling running through the floorboards.
The SDN Abstraction: A completely isolated software sandbox. When you define a /24 space, you are telling the SDN controller to carve out a unique logical partition in its massive database that belongs strictly to you.

2. Azure Bastion

The Hardware Legacy: A hardened "Jump Box" server sitting in a physical DMZ (Demilitarized Zone), or a secure physical KVM matrix switch that required a direct console cable.
The SDN Abstraction: A managed, scalable, reverse-proxy web service. It tells the virtual network: "Intercept Port 443 web traffic from the Azure Portal, convert it securely to SSH/RDP protocols internally, and pass it directly to the VM's virtual NIC."

3. NAT Gateway

The Hardware Legacy: A dedicated, standalone hardware router or firewall appliance configured strictly for outward Source Network Address Translation (SNAT).
The SDN Abstraction: A programmatic routing rule applied directly to a subnet's virtual routing table. It tells the underlying hypervisor switch: "If a packet is outbound-initiated and doesn't match an internal destination, rewrite its source address to this specific Public IP resource before sending it over the backbone."

Why Thinking in "Abstractions" Helps You Pass

When the AZ-700 exam asks complex questions about traffic flow, thinking about physical "boxes" will trip you up because physical boxes imply that traffic must pass through them sequentially.

By viewing them as software policies, it makes total sense why an inbound HTTP web request completely ignores the NAT Gateway on its way back out. The underlying virtual switch simply evaluates the packet against its active software rules: it matches the "Inbound Stateful Public IP" rule, so it uses that rule's translation path instead of the NAT Gateway's outbound rule.

You are thinking like a cloud architect now, not just a deployment technician!