Think of Microsoft Azure as a massive digital city. It's filled with powerful computers, storage, and services. When you use Azure, you don't just throw your applications out into the open city square. Instead, you get to build your own private, fenced-off neighborhood. In Azure, this neighborhood is called a Virtual Network, or VNet.

A VNet is an isolated section of the Azure cloud dedicated to your account. It's your own private network, just like the one you might have at home or in an office, but it exists entirely in software. Inside this VNet, your cloud resources, like virtual machines (servers) and databases, can communicate with each other securely and privately. They are shielded from the public internet unless you decide to open a path.

Every VNet has a range of private IP addresses. Think of these like the street addresses in your private neighborhood. They are not visible from the outside world. You define this address range when you create the VNet, using a notation called Classless Inter-Domain Routing (CIDR).

This CIDR block tells Azure that your VNet can use all IP addresses from 10.0.0.0 to 10.0.255.255. That's 65,536 addresses, which is plenty for our neighborhood.

A big neighborhood with thousands of houses would be chaotic without streets. In your VNet, these streets are called subnets. You divide your VNet's large address range into smaller, manageable chunks, each assigned to a subnet.

Why bother? Subnets let you organize and secure your resources more effectively. A common practice is to create separate subnets for different tiers of an application. For example, you could have one subnet for your web servers that might need to talk to the internet, and a completely separate subnet for your databases, which should never be exposed publicly.

Each subnet gets its own piece of the VNet's IP address range. For our 10.0.0.0/16 VNet, we could create:

• A WebSubnet with the range 10.0.1.0/24 (256 addresses)
• A DatabaseSubnet with the range 10.0.2.0/24 (another 256 addresses)

When you place a virtual machine in a subnet, Azure automatically assigns it a private IP address from that subnet's range. It's important to know that Azure reserves the first four and the last IP address in each subnet for its own networking purposes. So, in a /24 subnet with 256 addresses, 251 are available for you to use.

Just having fences and streets isn't enough; you also need a security guard. In Azure, this guard is called a Network Security Group (NSG). An NSG is a basic firewall that contains a list of rules to allow or deny network traffic to your resources.

You can attach an NSG to a subnet or directly to a specific virtual machine's network interface. Attaching it to a subnet is usually more efficient, as all resources in that subnet will automatically inherit the same rules.

Each rule in an NSG specifies:

• Source: Who is the traffic coming from? (e.g., any IP address, a specific IP, another subnet)
• Destination: Who is the traffic going to?
• Port: Which communication channel? (e.g., port 80 for web traffic)
• Protocol: What language is it speaking? (TCP, UDP)
• Action: Allow or Deny?
• Priority: A number to decide which rule to apply first if there's a conflict. Lower numbers are processed first.

For example, to allow anyone on the internet to view a website hosted on a server in your WebSubnet, you would create an inbound NSG rule like this:

This simple rule is powerful. It acts as the gatekeeper, ensuring only the traffic you want can get in, while everything else is blocked by default. It's a critical first line of defense for securing your applications in Azure.

Understanding these core components—VNets for isolation, subnets for organization, and NSGs for security—is the first step to building robust and secure solutions in the cloud.