DEV Community

Joy Imarah
Joy Imarah

Posted on

Azure Virtual Network Configuration, Subnets, IP Addressing & Network Security (Part 7)

Azure Virtual Network Configuration, Subnets, IP Addressing & Network Security (Part 7)

In the previous part of my Azure Cloud Journey, I deployed a Node.js application to Azure App Service using GitHub Actions, where the focus was on application hosting and continuous deployment.

This time, I moved away from applications and into something every cloud engineer eventually realizes is just as important—networking.

Applications don't exist in isolation. They communicate, exchange data, and interact with other services, and all of that depends on how the network is designed. A poorly designed network can lead to security vulnerabilities, connectivity problems, and scalability limitations.

To better understand Azure networking, I built a small virtual infrastructure from the ground up using Azure Virtual Networks (VNets), subnets, Network Security Groups (NSGs), Virtual Network Peering, and User Defined Routes (UDRs).

By the end of the project, many networking concepts that once seemed abstract finally started making practical sense.

Project Goals

The objectives of this project were to:

  • Understand CIDR notation and IP address planning.
  • Create and configure Azure Virtual Networks.
  • Segment networks using subnets.
  • Control traffic with Network Security Groups.
  • Differentiate between public and private IP addressing.
  • Configure Virtual Network Peering.
  • Explore custom routing using User Defined Routes.
  • Validate connectivity between Azure resources.

Designing the Network

Rather than deploying everything into a single network, I wanted to simulate a more realistic cloud environment.

The primary virtual network was divided into three logical layers:

  • Web Layer
  • Application Layer
  • Database Layer

I also created a second virtual network to demonstrate Virtual Network Peering and communication between separate Azure networks.

This type of segmentation improves security, keeps resources organized, and makes future expansion much easier.

Learning CIDR Notation

One of the first concepts I encountered was CIDR (Classless Inter-Domain Routing).

Initially, CIDR notation looked intimidating, but it simply defines how large a network is.

For example:

10.0.0.0/16
Enter fullscreen mode Exit fullscreen mode

This provides enough IP addresses to create multiple subnets while leaving room for future growth.

Each workload was then assigned its own /24 subnet:

  • Web: 10.0.1.0/24
  • Application: 10.0.2.0/24
  • Database: 10.0.3.0/24

Separating workloads into dedicated subnets is a common cloud networking practice because it allows each layer to have its own security rules and routing policies.

Building the Virtual Network

With the address space planned, I created the primary Azure Virtual Network.

This virtual network acts as the private communication boundary where Azure resources can securely communicate with one another without exposing internal traffic to the internet.

Once deployed, it became the foundation for every networking component used throughout the project.

Securing the Network with NSGs

Next came Network Security Groups (NSGs).

Before this project, I thought of firewalls as physical devices sitting at the edge of a network. Azure showed me that cloud networking handles this differently.

An NSG functions like a virtual firewall that evaluates traffic based on:

  • Source
  • Destination
  • Protocol
  • Port
  • Action

I configured separate NSGs for the web, application, and database layers, allowing each subnet to enforce its own security rules.

For example, the web subnet was configured to allow web traffic, while the database subnet accepted connections only from approved sources.

This reinforced an important cloud security principle: least privilege. Every subnet should only receive the traffic it actually needs.

Public vs Private IP Addresses

Another concept that became much clearer during the project was the difference between public and private IP addresses.

Public IP addresses allow communication with the internet.

Private IP addresses are used for communication between Azure resources inside the virtual network.

Most backend resources should never require a public IP. Keeping them private significantly reduces the attack surface of the environment.

Connecting Networks with VNet Peering

To understand communication between separate networks, I created a second virtual network and configured Virtual Network Peering.

One interesting challenge appeared almost immediately.

Azure refused to create the peering because both VNets initially shared the same address space.

After assigning a different CIDR block to the second network, the peering completed successfully.

This was a valuable lesson in IP planning. Even something as simple as overlapping address spaces can prevent networks from communicating.

Exploring User Defined Routes

Azure automatically manages routing for most deployments, but I wanted to understand how traffic could be customized.

Using a Route Table, I created a User Defined Route that redirected traffic to a specific destination.

Although the routing scenario was relatively simple, it demonstrated how administrators can override Azure's default routing behavior to meet more advanced networking requirements.

This concept becomes especially important when working with Azure Firewall, VPN Gateways, and hybrid cloud environments.

Challenges Along the Way

Like every hands-on project, this one came with a few obstacles.

The biggest issue occurred during Virtual Network Peering when Azure reported overlapping address spaces.

After redesigning the IP plan and assigning a different address range to the second VNet, the peering completed successfully.

While frustrating at first, troubleshooting these issues made the networking concepts much easier to understand than simply reading documentation.

Key Takeaways

This project helped reinforce several important Azure networking concepts:

  • Proper IP planning prevents deployment issues.
  • CIDR notation is fundamental to scalable cloud networking.
  • Subnet segmentation improves organization and security.
  • Network Security Groups provide granular traffic filtering.
  • Virtual Network Peering enables communication across separate virtual networks.
  • User Defined Routes allow administrators to customize network traffic flow.

More importantly, it showed me how traditional networking concepts translate into Azure's software-defined networking model.

Final Thoughts

Networking often sits quietly behind applications, but it is one of the most important building blocks of cloud infrastructure.

This project gave me practical experience designing, securing, and connecting Azure networks while reinforcing concepts that are essential for cloud engineering.

As I continue this Azure Cloud Journey, these networking fundamentals will become the foundation for more advanced topics such as Azure Firewall, Load Balancers, VPN Gateways, Application Gateways, and enterprise-scale cloud architectures.

Every project continues to make Azure feel a little less like a collection of services and a little more like a complete ecosystem.

GitHub Repository

https://github.com/JoySmarty/3mtt-azure-vnet-subnet-project

If you're also learning Azure, I'd love to hear about your experience or answer any questions in the comments.

Top comments (0)