Azure Networking — Complete Beginner-Friendly Explanation

Topics: Virtual Network (VNet), CIDR, Subnets, Network Security Groups (NSG), Public and Private VMs, Jump Box, and NAT Gateway

I'll explain your attached content in the same order as the original article (Parts 1–6), using simple English, practical examples, ASCII diagrams, and Azure Portal steps.

The objective is to understand not only what each Azure networking service does, but also why and when we use it.

What You'll Learn

1. What is an Azure Virtual Network (VNet)?

2. What is CIDR, and how do we choose an IP address range?

3. Why does Azure reserve five IP addresses in every subnet?

4. What is a subnet, and why do we need public and private subnets?

5. How to create a VNet with two subnets.

6. What is a Network Security Group (NSG), and how do its firewall rules work?

7. How to create and configure NSG rules.

8. How to deploy Windows and Linux VMs in public and private subnets.

9. How to connect to a private VM through a public VM.

10. What is a Jump Box or Bastion Host?

11. What is NAT Gateway, and why do we need it?

12. How to configure and test NAT Gateway.

Part 1 — What Is an Azure Virtual Network (VNet)?

1.1 What is a Virtual Network?

An Azure Virtual Network (VNet) is your own private network inside Microsoft Azure.

It allows Azure resources, such as Virtual Machines, to communicate securely with each other.

Simple real-world example

Imagine you own an office building.

Inside the building, you have:

• Reception

• Employee workstations

• Application servers

• Database servers

All these systems are connected through your company's private network.

Employees can communicate with internal servers without using the public internet.

An Azure VNet works in a similar way.

Azure example

                  INTERNET
                     |
                     |
              Public IP Address
                     |
                     v
+------------------------------------------------+
|             Azure Virtual Network              |
|                 10.0.0.0/16                    |
|                                                |
|   +----------------------+                     |
|   |    Public Subnet     |                     |
|   |     10.0.1.0/24      |                     |
|   |                      |                     |
|   |    Web Server VM     |                     |
|   +----------+-----------+                     |
|              |                                 |
|              | Private Communication           |
|              v                                 |
|   +----------------------+                     |
|   |    Private Subnet    |                     |
|   |     10.0.2.0/24      |                     |
|   |                      |                     |
|   |    Database Server   |                     |
|   +----------------------+                     |
|                                                |
+------------------------------------------------+

Explanation:

The web server can receive internet traffic when public connectivity and security rules are configured.

The database server has only a private IP address, so ordinary internet users cannot connect to it directly.

However, the web server can communicate with the database server using private IP addresses.

Key points

• VNet is a logically isolated private network in Azure.

• Resources inside a VNet can communicate using private IP addresses.

• VNets support subnets, routing, and security controls.

• Public internet access requires appropriate connectivity and security configuration.

• Not every Azure resource must be deployed inside your VNet; some Azure PaaS services use other networking models.

Part 2 — Choosing Your VNet's Address Space

2.1 What is an address space?

An address space is the range of IP addresses available inside your VNet.

For example:

VNet Address Space: 10.0.0.0/16

This means your VNet has a pool of 65,536 IPv4 addresses.

You can divide this address space into multiple smaller networks called subnets.

2.2 Understanding CIDR

CIDR stands for Classless Inter-Domain Routing.

It tells us how large an IP network is.

Consider:

10.0.0.0/16

• 10.0.0.0 is the network address.

• /16 means the first 16 bits identify the network.

• The remaining 16 bits are available for addressing within the network.

Formula:

For /16:

Common CIDR sizes

For this demonstration, we use:

VNet: 10.0.0.0/16

Why choose /16 instead of /24?

Suppose you start with a small office having only 10 employees.

Later, your company grows to 500 employees.

You will need more network capacity.

Similarly, choosing a sufficiently large VNet address space allows you to create more subnets later.

A larger private IP address space does not itself increase VNet charges. However, in production, you should avoid overlapping address ranges with networks you may connect through VPN or peering.

2.3 Private IP address ranges

Azure VNets commonly use the following private IPv4 ranges.

These are RFC 1918 private address ranges.

For our demonstration, we choose 10.0.0.0/16.

2.4 Why does Azure reserve five IP addresses?

This is an important Azure networking concept.

Azure reserves five IP addresses in every IPv4 subnet.

For example:

Subnet: 10.0.1.0/24

Total IP Addresses = 256
Reserved by Azure = 5
Usable IP Addresses = 251

Reserved addresses

Therefore:

Important: For any Azure IPv4 subnet, subtract five addresses from the total to calculate the usable IP addresses.

For example:

Part 3 — Subnets: Dividing Your Network

3.1 What is a subnet?

A subnet is a smaller network created inside a VNet.

Consider an office building.

You have separate departments:

• HR Department

• Finance Department

• IT Department

Although all departments belong to the same company, each department has different responsibilities and security requirements.

Similarly, we divide a VNet into subnets.

Example

                  Azure VNet
                 10.0.0.0/16
                       |
           +-----------+-----------+
           |                       |
           v                       v
    Public Subnet             Private Subnet
    10.0.1.0/24               10.0.2.0/24
           |                       |
           v                       v
      Web Servers             DB Servers
      Load Balancers          Backend Services

3.2 Why do we need subnets?

Reason 1: Security

Your web application should be accessible to users.

However, your database should not be directly accessible from the internet.

By placing these resources in different subnets, you can apply separate security policies.

Reason 2: Organization

You can organize resources according to their responsibilities.

For example:

Azure VNet: 10.0.0.0/16
         |
         +-- Web Subnet
         |      10.0.1.0/24
         |
         +-- Application Subnet
         |      10.0.2.0/24
         |
         +-- Database Subnet
                10.0.3.0/24

This is commonly used in three-tier application architecture.

3.3 Public subnet vs. private subnet

Important: Azure does not have a special subnet type called public subnet or private subnet.

These are naming conventions.

A subnet's name does not control its connectivity.

Public accessibility depends on public IP configuration, routing, and security rules.

3.4 Hands-on: Create a VNet with two subnets

Step 1 — Create a Virtual Network

Open the Azure Portal.

Search for Virtual networks → Create.

On the Basics tab, enter:

Step 2 — Create the public subnet

Go to IP Addresses and add:

Step 3 — Create the private subnet

Add another subnet:

Remove the default subnet if necessary, then select Review + create → Create.

Your network structure will be:

Resource Group: rg-networking-demo
          |
          v
     VNet: vnet-demo
       10.0.0.0/16
          |
    +-----+-----+
    |           |
    v           v
public-subnet  private-subnet
10.0.1.0/24    10.0.2.0/24
251 usable     251 usable

You now have a VNet with two subnets.

Part 4 — Network Security Groups (NSGs)

4.1 What is an NSG?

A Network Security Group (NSG) is a firewall-like security feature in Azure.

It controls which network traffic is allowed or denied.

Think of an NSG as a security guard standing at an office entrance.

The security guard checks:

• Who is trying to enter?

• Where are they coming from?

• Which door or service do they want to access?

• Should access be allowed or denied?

An NSG performs similar checks using network security rules.

Example

                   INTERNET
                      |
                      v
                +-----------+
                |    NSG    |
                | Firewall  |
                +-----------+
                      |
           +----------+----------+
           |          |          |
           v          v          v
        Port 22    Port 80    Port 3389
          SSH        HTTP        RDP
           |          |          |
         Allow      Allow      Allow

Other inbound internet traffic is denied by the default NSG rule unless another rule permits it.

4.2 Important ports

For example, to host an ASP.NET Core website using HTTP, you may allow inbound TCP port 80 to your web server.

For production websites, HTTPS on port 443 is preferred.

4.3 How NSG rules work

Every NSG rule includes properties such as:

Understanding priority

Azure evaluates NSG rules based on priority.

Lower priority number means higher precedence.

Example:

Suppose a user attempts to connect using SSH.

Incoming Request: TCP Port 22
             |
             v
      Check Priority 100
             |
      Is Port 22? YES
             |
             v
           ALLOW

Azure stops evaluating further rules when it finds the first matching rule.

Custom NSG rule priorities range from 100 to 4096.

4.4 Default NSG rules

Azure automatically provides default NSG rules.

Default inbound rules

Default outbound rules

These rules cannot be deleted, but custom rules can override their behavior by taking precedence.

Simple explanation: By default, NSGs allow communication within the VNet and permit outbound internet traffic. Unsolicited inbound internet traffic is denied.

Actual connectivity also depends on routes, IP configuration, and other controls.

4.5 Where can we attach an NSG?

There are two common options.

Option 1 — Subnet-level NSG

An NSG attached to a subnet applies to network traffic for resources within that subnet.

             public-subnet
                   |
                   v
            NSG: nsg-public
                   |
           +-------+-------+
           |               |
           v               v
        Linux VM        Windows VM

Both VMs are subject to the subnet's NSG rules.

Option 2 — NIC-level NSG

You can attach an NSG directly to a VM's Network Interface Card (NIC).

              Azure VM
                 |
                 v
          Network Interface
                 |
                 v
               NSG

This provides security rules specific to that network interface.

If both subnet and NIC NSGs are configured, both must allow the traffic.

For inbound traffic, subnet-level rules are evaluated before NIC-level rules. For outbound traffic, NIC-level rules are evaluated first.

4.6 Hands-on: Create an NSG

Step 1 — Create an NSG

Azure Portal → Search Network security groups → Create.

Select Review + create → Create.

Step 2 — Allow SSH

Open the NSG → Inbound security rules → Add.

For this lab, the source is Any. In production, restrict SSH to a trusted IP address or use a secure management service.

Step 3 — Allow HTTP

Add another inbound rule:

Step 4 — Associate the NSG with the public subnet

Open nsg-public-subnet → Subnets → Associate.

Select:

Virtual Network: vnet-demo
Subnet: public-subnet

Select OK.

Your setup becomes:

               INTERNET
                  |
                  v
           nsg-public-subnet
           +--------------+
           | SSH 22 Allow |
           | HTTP 80 Allow|
           +--------------+
                  |
                  v
             public-subnet
              10.0.1.0/24
                  |
                  v
               Web VM

The private subnet has no NSG configured in this demonstration. That does not mean it is fully secured; production backend subnets should have appropriate restrictive security policies.

Part 5 — Public and Private Virtual Machines

This section demonstrates the practical difference between public and private networking.

We will create four VMs.

5.1 Add an RDP rule

Before creating Windows VMs, add an RDP rule to nsg-public-subnet.

Azure Portal → NSG → Inbound security rules → Add.

For a real environment, do not expose RDP to every internet address. Restrict it to your trusted IP or use Azure Bastion.

5.2 Deploy the public Linux VM

Azure Portal → Virtual machines → Create.

Under Networking:

Virtual Network: vnet-demo
Subnet: public-subnet
Public IP: Create new
NIC NSG: None

The subnet NSG already applies to this VM.

Download the SSH private key when Azure provides it.

5.3 Deploy the public Windows VM

Create another VM.

Networking:

Virtual Network: vnet-demo
Subnet: public-subnet
Public IP: Create new
NIC NSG: None

5.4 Deploy the private Linux VM

Create a third VM.

Networking:

Virtual Network: vnet-demo
Subnet: private-subnet
Public IP: None
NIC NSG: None

The most important setting is Public IP: None.

The VM receives a private IP address but has no directly assigned public IP.

5.5 Deploy the private Windows VM

Create the fourth VM.

Networking:

Virtual Network: vnet-demo
Subnet: private-subnet
Public IP: None
NIC NSG: None

Final architecture

                     YOUR LAPTOP
                          |
                          v
                       INTERNET
                          |
                          v
                  Public IP Addresses
                          |
                          v
+------------------------------------------------+
|             VNet: 10.0.0.0/16                  |
|                                                |
|   public-subnet: 10.0.1.0/24                   |
|   NSG: Allow SSH, HTTP, RDP                    |
|                                                |
|   +----------------+  +----------------+      |
|   | Public Linux   |  | Public Windows |      |
|   | 10.0.1.4       |  | 10.0.1.5       |      |
|   | Has Public IP  |  | Has Public IP  |      |
|   +-------+--------+  +-------+--------+      |
|           |                   |                |
|           | Private Network   |                |
|           v                   v                |
|   +----------------+  +----------------+      |
|   | Private Linux  |  | Private Windows|      |
|   | 10.0.2.4       |  | 10.0.2.5       |      |
|   | No Public IP   |  | No Public IP   |      |
|   +----------------+  +----------------+      |
|                                                |
|   private-subnet: 10.0.2.0/24                  |
+------------------------------------------------+

The private IP addresses shown are examples. Azure may assign different addresses.

Cost note: Although the original article labels these demonstrations as free-tier eligible, creating four VMs does not automatically make all four free. Free allowances are limited and depend on your subscription and resource eligibility. Windows licensing, disks, and public IPv4 addresses can also incur charges.

5.6 Connect to the public Linux VM

From your Windows laptop, open PowerShell or Terminal.

Example:

ssh -i "mykey.pem" azureuser@20.x.x.x

Replace 20.x.x.x with the public IP address of your Linux VM.

The connection succeeds when:

1. The VM has a public IP address.

2. The NSG allows TCP port 22.

3. SSH is running and the credentials/key are valid.

5.7 Connect to the public Windows VM

On your Windows laptop:

Press Windows + R, type:

mstsc

Enter the Windows VM's public IP address.

Provide the username and password.

You should see the Windows Server desktop if RDP is enabled and permitted.

5.8 Try connecting directly to a private VM

Now attempt to connect to the private Linux VM from your laptop.

ssh azureuser@10.0.2.4

This normally fails because 10.0.2.4 is a private IP address.

The public internet does not route traffic directly to RFC 1918 private addresses.

Similarly, trying to connect to 10.0.2.5 using Remote Desktop from an ordinary internet connection will fail.

A private connection such as a VPN or ExpressRoute could provide a route, but this demonstration has not configured one.

5.9 Connect to a private VM through a public VM

Now comes the important part.

First, connect to your public Linux VM.

ssh -i "mykey.pem" azureuser@20.x.x.x

After logging in, connect to the private Linux VM:

ssh azureuser@10.0.2.4

You must also have valid SSH authentication for the private VM. This could use a separate key securely configured for that VM.

The connection path is:

                  YOUR LAPTOP
                       |
                       | SSH
                       v
                  Public Linux VM
                     10.0.1.4
                       |
                       | SSH over VNet
                       v
                  Private Linux VM
                     10.0.2.4

This works because both VMs are inside the same VNet, and the required internal network traffic is permitted.

Windows example

The same principle applies to Windows VMs.

Your Windows Laptop
         |
         | RDP
         v
Public Windows VM
     10.0.1.5
         |
         | RDP
         v
Private Windows VM
     10.0.2.5

You connect to the public Windows VM first.

Then, from inside that VM, open Remote Desktop and connect to the private Windows VM using its private IP.

5.10 What is a Jump Box?

A Jump Box, also called a jump server or bastion host, is a server used as an intermediate access point to reach private servers.

For example:

             Administrator
                  |
                  v
               Jump Box
                  |
          +-------+-------+
          |               |
          v               v
     Private VM 1    Private VM 2

Instead of exposing every server directly to the internet, administrators connect through a controlled access point.

This pattern is commonly used in enterprise environments.

The article also introduces Azure Bastion, which provides managed RDP and SSH connectivity to VMs through private IP addresses without assigning public IPs to those target VMs.

Part 6 — Azure NAT Gateway

6.1 What problem does NAT Gateway solve?

Imagine you have a private Linux VM.

It does not have a public IP address.

However, it still needs to:

• Download Ubuntu updates.

• Install software packages.

• Call an external API.

• Access third-party services.

These are outbound internet connections.

The important question is:

How can a private VM connect to the internet without having its own public IP?

This is where outbound Network Address Translation (NAT) is useful.

6.2 Understanding default outbound access

The original article explains that Azure historically provided a default outbound internet connection for some VMs.

However, this approach has limitations.

• The outbound public IP address is not guaranteed to remain stable.

• Outbound connections can be constrained by SNAT port availability.

• Default outbound access is not recommended for production workloads.

• Azure is moving toward explicitly configured outbound connectivity.

For example, suppose your backend application calls a payment provider.

The payment provider allows requests only from an approved public IP address.

If your application's outbound public IP changes, the payment provider may reject the connection.

You need a stable public IP.

6.3 What is NAT Gateway?

Azure NAT Gateway is a managed networking service that provides outbound internet connectivity to resources in an associated subnet.

It uses one or more public IP addresses for outbound traffic.

Simple example

+------------------------------------------------+
|              Azure Virtual Network             |
|                                                |
|              private-subnet                    |
|               10.0.2.0/24                      |
|                                                |
|       +----------------------------+           |
|       | Private Linux VM           |           |
|       | 10.0.2.4                   |           |
|       | No Public IP               |           |
|       +-------------+--------------+           |
|                     |                          |
|                     | Outbound Request         |
|                     v                          |
|               NAT Gateway                      |
|                     |                          |
+---------------------|--------------------------+
                      |
                      v
               Static Public IP
                  20.x.x.x
                      |
                      v
                   INTERNET

How it works

Suppose the private Linux VM sends an API request.

Private VM: 10.0.2.4
          |
          v
      NAT Gateway
          |
          | Translates source IP
          v
Public IP: 20.x.x.x
          |
          v
    External API

The external API sees the NAT Gateway's public IP, not the VM's private IP.

The response is translated back and delivered to the originating VM.

6.4 Important NAT Gateway characteristics

NAT Gateway can provide up to 64,512 SNAT ports per attached public IP address.

The key point is that NAT Gateway supports outbound connections and their return traffic, but does not provide a way for arbitrary internet clients to initiate inbound connections to private VMs.

6.5 NAT Gateway vs. public IP on a VM

6.6 Hands-on: Create a NAT Gateway

This section uses paid Azure resources.

The original article estimates approximately $0.045/hour plus data processing. Treat that as an illustrative estimate, not a current price quotation. Public IP charges may be additional.

Step 1 — Create a public IP

Azure Portal → Public IP addresses → Create.

Select Review + create → Create.

Step 2 — Create NAT Gateway

Azure Portal → NAT gateways → Create.

Select Review + create → Create.

Now NAT Gateway is associated with your private subnet.

Step 3 — Verify outbound connectivity

First, SSH into the public Linux VM.

Then connect to the private Linux VM.

From inside the private VM, execute:

curl ifconfig.me

This command contacts an external service that reports the public IP address used for the request.

Expected result:

20.x.x.x

The IP address should match the public IP assigned to pip-natgw-demo.

This confirms that outbound traffic is using NAT Gateway.

Step 4 — Understand what changed

Before NAT Gateway, the VM might have used another configured outbound mechanism, or it might not have had outbound connectivity.

After NAT Gateway:

Private VM
    |
    | Outbound Request
    v
NAT Gateway
    |
    | Fixed Public IP
    v
Internet

But inbound connectivity remains unchanged:

Internet
    |
    | Unsolicited Inbound Request
    v
NAT Gateway
    |
    X  Not Allowed
    |
Private VM

NAT Gateway does not expose the private VM to unsolicited inbound internet connections.

Step 5 — Delete the paid resources

After testing, delete:

1. natgw-demo

2. pip-natgw-demo

This avoids continuing NAT Gateway and public IP charges.

The original course asks you to retain the four VMs for the next lesson about Application Security Groups.

If you keep them, deallocate the VMs when not in use. Remember that attached disks and some networking resources can continue generating charges even when VM compute is deallocated.

Final Summary — How Everything Works Together

Consider a real-world application consisting of an ASP.NET Core web server and a SQL Server database.

You want users to access the website, but you do not want them to connect directly to SQL Server.

The networking design could look like this:

                      INTERNET
                         |
                         | HTTPS 443
                         v
                   Public IP
                         |
                         v
                 +---------------+
                 | Public Subnet |
                 |  10.0.1.0/24  |
                 |               |
                 |  Web Server   |
                 | ASP.NET Core  |
                 +-------+-------+
                         |
                         | SQL Connection
                         | TCP 1433
                         v
                 +---------------+
                 | Private Subnet|
                 |  10.0.2.0/24  |
                 |               |
                 |  SQL Server   |
                 |  Private IP   |
                 +-------+-------+
                         |
                         | Outbound only
                         v
                   NAT Gateway
                         |
                         v
                      INTERNET

In this design, the web server receives HTTPS requests from users, and it communicates with SQL Server using a private IP address.

The database has no direct public IP. Its NSG can be configured to allow SQL traffic only from the application subnet.

When the database VM needs outbound connectivity, NAT Gateway can provide it through a stable public IP.

Important concepts to remember

Important AZ-104 exam points

The most important concepts from your attached article are:

• Azure reserves five IPv4 addresses in each subnet.

• A /24 subnet contains 256 total addresses and 251 usable addresses.

• NSG rules are evaluated by priority; lower numbers take precedence.

• NSGs can be associated with subnets or network interfaces.

• Subnets are not automatically public or private because of their names.

• VMs without public IPs can communicate privately with other VMs when networking permits.

• A Jump Box provides an intermediate route for administrative access.

• NAT Gateway provides outbound connectivity, not unsolicited inbound access.

• NAT Gateway uses static public IP resources.

• Deallocating VMs stops compute charges, but disks and certain other resources remain billable.

The central concept: A VNet provides the private network, subnets organize workloads, NSGs control traffic, public/private IP configuration determines addressability, and NAT Gateway provides controlled outbound internet connectivity.

Subnet: 10.0.1.0/24

Total IPs    = 256
Reserved IPs = 5
Usable IPs   = 251

Your Laptop
     |
     | SSH / RDP
     v
Public VM (Jump Box)
     |
     | Private IP
     v
Private VM

Private VM: 10.0.2.4
        |
        v
    NAT Gateway
        |
        v
Public IP: 20.x.x.x
        |
        v
     Internet

curl ifconfig.me

             Internet
                |
                v
           Web Server
          Public Subnet
                |
                | SQL Port 1433
                v
          Database Server
          Private Subnet

Tags: Azure Networking, Azure Virtual Network, Azure VNet, Azure Subnets, Azure CIDR, Network Security Group, Azure NSG, Azure Public IP, Azure Private IP, Azure Virtual Machines, Azure NAT Gateway, Azure Bastion, Jump Box, Azure Network Security, AZ-104, Azure Administrator, Azure Interview Questions