Part 1: Build an Azure Virtual Network

Create an Azure VNet with a reusable CIDR subnet plan.

Introduction

30 Second Summary

Online services become harder to grow when every part shares the same pool of addresses. A clear network plan gives each part its own space while saving room for what comes next.

In this project, you will use the Azure portal to build an Azure Virtual Network for a fictional company. A deliberate overlap attempt shows you why every subnet needs a unique range.

What You'll Build

You'll open vnet-nextwork-lab to see snet-web at 10.0.0.0/24 alongside snet-app at 10.0.1.0/24.

By the end of this project, you'll have:

A live network view where you can open vnet-nextwork-lab to confirm its 10.0.0.0/16 address space.
A segmented subnet table showing separate ranges for the web tier plus the application tier.
A documented CIDR plan you can explain using Azure's rejected duplicate-range test.
Secret Mission: Add snet-data at 10.0.2.0/24 without overlapping either existing subnet.

Are there any prerequisites?

You need an active Azure subscription with resource-creation access. You will complete the project in Microsoft Edge with no local installation.

Before We Start

Before any Azure resources are created, this checkpoint locks in the network you are about to build. It also captures why your VNet address plan must leave room for later parts of the series.

Open Your Azure Networking Workspace

Your first Azure Virtual Network deployment depends on the portal reaching the right subscription. An inaccessible account or missing permission would interrupt that deployment.

This step confirms your Azure portal session. It also checks that your intended subscription is available for resource creation.

In this step, get ready to:

Sign in to the Azure portal with the account tied to your active subscription.
Confirm that the intended subscription appears on the Resource groups creation page.
Return to the Resource groups page without creating a resource.

Sign in to the Azure portal

Microsoft Edge is your browser for this project. The account tied to your active subscription gives you access to the Azure environment used throughout the series.

Press Cmd+Space on macOS or the Windows key on Windows to open the system search bar.
Type Microsoft Edge in the search bar.
Press Enter to open Microsoft Edge.
Select the address bar at the top of Microsoft Edge.
Enter Azure portal as your search query.
Select the official Microsoft result for the Azure portal.
Choose the account tied to your active Azure subscription when the sign-in flow asks.
Complete any account verification shown during sign-in.

You should see the Azure portal home page. This confirms that your browser session is signed in.

Confirm your subscription access

A resource group is a container for Azure resources that share a lifecycle. Its creation page reveals whether your intended subscription is available before any project resource exists.

Select the search bar at the top of the Azure portal.
Enter Resource groups in the search bar.
Select Resource groups from the search results.
Select + Create at the top of the Resource groups page.
Open the Subscription list on the creation page.
Select the subscription tied to this project.
Leave the remaining creation fields unchanged.

The Subscription field should show your intended subscription. The available creation page confirms your resource-creation access.

Can't see your subscription?

Switch to the directory tied to your intended subscription from the account menu in the top right corner.
Request resource-creation access from your subscription administrator if + Create is unavailable.
Repeat the subscription check after your directory or access changes.

Help me diagnose my Azure subscription access. If an administrator needs to change your access, share the issue in the NextWork community.

Return to Resource groups

The empty creation form has confirmed your access. Returning now keeps the workspace clean for the first resource deployment.

Before you return, do you expect the Resource groups page to keep showing the same creation option?

Select the search bar at the top of the Azure portal.
Enter Resource groups in the search bar.
Select Resource groups from the search results.
Confirm that + Create is visible at the top of the page.

You'll see the Resource groups page with + Create available. No project resource has been created.

You cleared the access check before it could interrupt your build. Next up, you'll create the network foundation in the confirmed subscription.

Build Your Virtual Network

The access check confirmed that your intended subscription is ready in the Azure portal. Your network still exists only as a plan.

Now you'll turn that plan into an Azure Virtual Network with the address space 10.0.0.0/16. Its first subnet becomes the foundation for later security work.

In this step, get ready to:

Create a resource group for the networking resources.
Define the VNet address space and its first subnet.
Verify that Azure deployed the planned network ranges.

Create the resource group

A resource group is a container for Azure resources that share a lifecycle. Keeping this network in rg-nextwork-networking gives the rest of the series one reusable foundation.

On the Resource groups page from earlier, select + Create.

You'll see the resource group creation form for the subscription you checked earlier.

Choose the intended subscription from the Subscription list.
Enter rg-nextwork-networking in the Resource group field.

The form now ties rg-nextwork-networking to the intended subscription.

Choose East US 2 from the Region list.
Select Review + Create.

The review page checks the subscription, name, and region before Azure creates anything.

Select Create after the validation completes.

That first resource is in place. rg-nextwork-networking now provides the lifecycle boundary for your network.

Can't create the resource group?

Confirm that the Subscription field shows the subscription you verified earlier.
Request resource-creation access if the portal prevents you from selecting Create.
Help me troubleshoot Azure resource group creation.

Configure the virtual network

A VNet address space defines the private range available to every subnet inside it. CIDR notation uses a suffix such as /16 to describe the size of that range.

Search for Virtual networks using the Azure portal search bar.
Select Virtual networks from the search results.

You'll see the page where Azure lists the virtual networks available in your subscription.

Select + Create.

The VNet creation workflow opens on the Basics tab.

Choose the intended subscription from the Subscription list.
Choose rg-nextwork-networking from the Resource group list.

The VNet is now associated with the resource group you just created.

Enter vnet-nextwork-lab in the Name field.
Choose East US 2 from the Region list.

The Basics tab now places vnet-nextwork-lab in the same region as its resource group.

Select the IP Addresses tab.

Define the address plan and deploy

The VNet uses 10.0.0.0/16 as its parent address space. The web subnet takes the smaller 10.0.0.0/24 block inside that range.

Set the IPv4 address space to 10.0.0.0/16.
Select the default subnet to edit it.

The subnet editor lets you define one child range inside the VNet address space.

Enter snet-web as the subnet name.
Set the starting address to 10.0.0.0.

The subnet now has its workload name and starting address.

Set the subnet size to /24.

The editor now shows the complete subnet range as 10.0.0.0/24.

Leave the optional subnet integrations and settings at their defaults.
Select Add.

You'll return to the IP Addresses tab with snet-web listed beneath the VNet address space.

How Do These Ranges Fit Together?

The 10.0.0.0/16 address space is the full private range available to this VNet. The 10.0.0.0/24 subnet uses one smaller section of that range.

This layout preserves unused addresses for more workload subnets later in the series.

Select Review + create.
Select Create after the validation completes.

A short wait here is normal while Azure provisions the virtual network.

Before you inspect the resource, predict which parent address space and child subnet range Azure will show.

Open the deployed vnet-nextwork-lab resource from the deployment confirmation.
Read the IPv4 address space on the Overview page.

You'll see 10.0.0.0/16 as the VNet address space.

Select Subnets from the VNet menu.
Read the range listed for snet-web.

You'll see snet-web using 10.0.0.0/24. Strong start. Your first Azure network segment is deployed with room for future subnets.

Missing the VNet or Subnet?

Confirm that the rg-nextwork-networking deployment used East US 2.
Return to the VNet creation workflow if deployment validation did not complete.
Confirm that you selected Add after editing the default subnet if snet-web is missing.
Help me find my Azure VNet or subnet.

Your network foundation is live. Next, you'll pressure-test its address plan against Azure's subnet rules.

Test an Overlapping Subnet

Your Azure Virtual Network is live in the Azure portal with the 10.0.0.0/16 address space. The first subnet, snet-web, occupies 10.0.0.0/24.

A CIDR address plan depends on each subnet owning a unique range. This step deliberately reuses an occupied block to expose the boundary Azure enforces.

In this step, get ready to:

Confirm the range assigned to snet-web.
Trigger overlap validation for snet-overlap with the duplicate range 10.0.0.0/24.
Verify the original network remains unchanged.

Confirm the occupied range

The saved subnet table gives you a baseline for the collision test. It shows which address blocks already belong to existing subnets.

In vnet-nextwork-lab from earlier, select Subnets from the left menu.
Locate the snet-web row in the subnet table.

You should see snet-web using 10.0.0.0/24 inside vnet-nextwork-lab.

Attempt the overlapping subnet

The next configuration gives a second subnet the same block as snet-web. The address range is the only variable in this test.

Select + Subnet from the toolbar.
Enter snet-overlap in the Name field.
Leave the optional integrations unchanged.

Before you enter the duplicate range, do you think Azure will let you add two subnets that claim the same addresses?

Enter 10.0.0.0 in the Starting address field.
Select /24 (256 addresses) from the Size menu.
Inspect the validation below Subnet address range.
Confirm the Add button is disabled.

You'll see validation that 10.0.0.0/24 overlaps with snet-web. Azure keeps Add disabled, so the duplicate subnet cannot be created.

You hit the intended boundary. Azure has protected the working subnet from a duplicate range.

Why Does Azure Reject the Range?

Every subnet range must sit inside the VNet address space. Each range must also stay unique within that VNet.

Both configurations claim 10.0.0.0/24. Azure rejects the second configuration to keep network addresses unambiguous.

Verify the original network

The subnet table records the configurations Azure accepted. Your final check confirms the failed attempt created no resource.

Before you inspect the table, what entries do you expect to see after Azure blocked the duplicate range?

Close the Add subnet pane.
Inspect the subnet table on the Subnets page.

You should still see snet-web at 10.0.0.0/24. You should not see snet-overlap in the list.

Didn't See the Overlap Validation?

Confirm the Starting address is exactly 10.0.0.0.
Confirm the Size is /24 (256 addresses).
Confirm snet-web still shows 10.0.0.0/24 in the subnet table.
Help me diagnose why Azure did not flag my overlapping subnet range.

The collision test has proved that duplicate subnet ranges cannot coexist. Next, you'll place the application tier in unused address space.

Add the Application Subnet

Your deliberate overlap test in the Azure portal proved that each subnet inside an Azure Virtual Network needs a unique CIDR block. Azure rejected the duplicate range without changing vnet-nextwork-lab.

The application tier now needs unused address space inside the VNet. Placing it in the next available block creates a separate boundary that later security rules can target.

In this step, get ready to:

Create snet-app with an unused subnet range.
Verify that the web subnet has a separate range from the application subnet.
Record the parent VNet range plus both child subnet ranges for Part 2.

Create the non-overlapping subnet

The block 10.0.1.0/24 sits inside the parent range 10.0.0.0/16. It does not occupy the block already assigned to snet-web.

Select + Subnet on the Subnets page from earlier.
Enter snet-app in the Name field.
Enter 10.0.1.0/24 as the subnet address range.

Keep This Subnet Focused

This project adds address segmentation only. Every optional integration stays at its default.

The NAT gateway option remains unchanged.
The network security group option remains unchanged.
The route table option remains unchanged.
The service endpoints option remains unchanged.
The delegation option remains unchanged.
The private endpoint policies option remains unchanged.

Keep every optional integration at its default.

Before you select Add, do you think Azure accepts this range after rejecting the duplicate block?

Select Add to create the subnet.

You should return to the subnet table with snet-app listed at 10.0.1.0/24.

That overlap lesson has paid off. Your application tier now has its own valid network segment.

Subnet Still Not Being Added?

Check that the range starts with 10.0.1.0.
Confirm that the subnet size is /24.
Return to the Subnets page if the rejected attempt is still visible.
Ask for help with the subnet settings.

Review and record the CIDR baseline

The subnet table confirms segmentation at a glance. The VNet pages provide the full baseline that Part 2 builds on.

Select Overview in the menu for vnet-nextwork-lab.

You should see the VNet in East US 2.

Select Address space in the VNet menu.

You should see the parent IPv4 address space 10.0.0.0/16.

Before the final check, how many subnet rows do you expect to see?

Select Subnets in the VNet menu.

You should see snet-web at 10.0.0.0/24. You should also see snet-app at 10.0.1.0/24.

What Does This Baseline Prove?

Both child ranges fit inside 10.0.0.0/16. Each child occupies a unique /24 block.

The remaining address space gives later parts room to add more network segments.

Secret mission

Add a Data Subnet

Your VNet already reserves separate ranges for web and application workloads. Add snet-data for future data workloads while keeping every subnet range unique.

Clean Up Your Resources

Azure Virtual Network is free, so the network resources shown in the Azure portal create no ongoing charges. Choose how you want to leave this foundation below.

Resources you used:

The Azure resource group rg-nextwork-networking contains every resource created in this project.
The VNet vnet-nextwork-lab uses the 10.0.0.0/16 address space in East US 2.
The subnets snet-web at 10.0.0.0/24, snet-app at 10.0.1.0/24, and snet-data at 10.0.2.0/24 reserve separate ranges for the web, application, and data tiers.

Keep everything running

No action needed. Choose this if you plan to continue to Part 2 with the same networking foundation.

Leave rg-nextwork-networking in the intended Azure subscription.
Continue to Part 2 with vnet-nextwork-lab and its three workload subnets.

Pause - I'll come back to this later

There is no compute resource to stop. Signing out leaves the free network configuration in place for later.

Save rg-nextwork-networking in your notes as the resource group for Part 2.
Save vnet-nextwork-lab in your notes as the VNet for Part 2.
Save 10.0.0.0/16 in your notes as the parent address space.
Save snet-web with 10.0.0.0/24 in your notes as the web tier reservation.
Save snet-app with 10.0.1.0/24 in your notes as the application tier reservation.
Save snet-data with 10.0.2.0/24 in your notes as the data tier reservation.
Use the account menu in the top-right corner to sign out of Azure.

Your resource group, VNet, and subnets remain intact for your return.

Delete - I don't want to use this again

Deleting the resource group permanently removes this networking foundation. Choose this only if you are comfortable rebuilding it before a later part.

Use the Azure portal search bar to find Resource groups.
Select Resource groups from the search results.
Select rg-nextwork-networking from the resource group list.
Select Delete resource group.
Enter rg-nextwork-networking to confirm the deletion.
Select Delete.

Azure starts deleting the resource group and everything inside it.

Wait until Azure confirms that the deletion is complete.
Return to Resource groups.
Refresh the resource group list.

You should no longer see rg-nextwork-networking in the list. Its VNet and all three subnets are deleted with it.

Nice Work!

You did it! You built a working Azure Virtual Network with clear boundaries for three workload tiers.

Part 1 of the Azure Networking series is complete. Your CIDR plan keeps each workload in its own subnet while preserving space for future projects.

You've learned how to:

Create a reusable resource lifecycle boundary with rg-nextwork-networking containing vnet-nextwork-lab.
Design a segmented address plan inside 10.0.0.0/16. Assign 10.0.0.0/24 to the web tier. Assign 10.0.1.0/24 to the application tier.
Trigger Azure's overlap protection by attempting to reuse 10.0.0.0/24. Diagnose why Azure rejects the duplicate range.
Complete the optional Secret Mission by adding snet-data at 10.0.2.0/24 for the data tier.

Ready to quiz yourself?