Step into the role of a Network Engineer at Contoso Ltd. and learn how to design and implement a scalable, secure, and globally distributed network in Microsoft Azure. This practical walkthrough covers the core skills tested in the AZ-700 certification.
Introduction: Why This Project Matters
Ever wondered how large enterprises structure their cloud networks for performance, security, and growth? It all starts with a robust Virtual Network (VNet) design.
In this guide, I'll take you through a real-world scenario: migrating the fictional company Contoso Ltd. to Azure. You'll get hands-on experience designing and implementing a global network infrastructure from the ground up, which is a fundamental skill for the AZ-700: Designing and Implementing Microsoft Azure Networking Solutions certification.
By the end of this article, you'll understand not just how to click buttons in the Azure portal, but why each decision is critical for building a resilient cloud environment.
The Blueprint: Contoso's Global Network Scenario
Before a single resource is created, a successful cloud migration requires a solid architectural plan. For Contoso Ltd., this meant designing a global network that would support diverse business units with varying needs for scale, security, and connectivity. Our blueprint is built on three core virtual networks, each serving a distinct strategic purpose.
1.** CoreServicesVnet** (East US | 10.20.0.0/16)
This network is the beating heart of Contoso's IT infrastructure in Azure. Hosted in the East US region, it's designed to be the central hub for mission-critical applications. It will house:
Public-facing web services and applications.
Sensitive database servers containing company and customer data.
Shared services like Active Directory domain controllers and DNS servers that other networks will depend on.
A future VPN gateway for secure hybrid connectivity back to the on-premises datacenter.
The large /16 address space was chosen deliberately to accommodate significant anticipated growth and complex subnetting, ensuring we never run out of IP addresses for core services.
ManufacturingVnet (West Europe | 10.30.0.0/16)
Located in West Europe to be near Contoso's physical manufacturing plants, this network is engineered for the Internet of Things (IoT). Its primary function is to handle a massive influx of data from countless sensors on the factory floor, monitoring everything from temperature to assembly line efficiency. The /16 address space provides the immense scale needed to segment these devices into multiple dedicated subnets, allowing for better traffic management and security isolation.ResearchVnet (Southeast Asia | 10.40.0.0/16)
This network supports the innovation engine of Contoso: the Research & Development team. Deployed in Southeast Asia to be close to this team, it has a simple, stable requirement. The small R&D team needs a secure environment for a predictable number of virtual machines used for testing and development. The /16 space might seem oversized, but it follows best practices for future-proofing and consistency, even if the current need is only a single subnet.
The Golden Rule: A Non-Overlapping Architecture
The entire design hinges on one critical rule: no address space can overlap. The on-premises network (10.10.0.0/16) and the three Azure VNets (10.20.0.0/16, 10.30.0.0/16, 10.40.0.0/16) are all completely separate. This careful planning is what will allow us to connect them all together in the future via peering and gateways without any routing conflicts, creating a seamless, global hybrid network.
Task 1: Laying the Foundation - The Resource Group
Think of a Resource Group as a logical container for your project. It's a best practice to group related resources for easier management, cost tracking, and cleanup.
Steps:
In the Azure Portal, search for and select Resource groups.
Click + Create.
Basics Tab:
Subscription: Choose your subscription
Resource Group: ContosoResourceGroup
Region: (US) East US (We place the group in the same region as our most critical VNet for metadata latency, but it can manage resources in any region).
Why This Matters: Using a single resource group for this project provides a unified management plane for all networking components, making it easy to monitor costs and apply policies.
Task 2: Building the HQ - CoreServicesVnet and Subnets
This is our most complex VNet, requiring careful subnet planning for security and functionality.
Creating the VNet:
Search for and select Virtual networks.
Click + Create.
Basics Tab:
Resource Group: ContosoResourceGroup
Name: CoreServicesVnet
Region: (US) East US
IP Addresses Tab:
IPv4 Address Space: 10.20.0.0/16
The Art of Subnet Design: Now, we segment this large address space into smaller, purpose-driven subnets. This is crucial for applying Network Security Groups (NSGs) and routing rules.
GatewaySubnet (10.20.0.0/27):
Purpose: Virtual Network Gateway. This is a reserved name! Azure requires this specific subnet to deploy a VPN or ExpressRoute gateway later to connect to on-premises networks.
Size: /27 (32 addresses). This is the minimum recommended size to accommodate future gateway SKUs.
SharedServicesSubnet (10.20.10.0/24): For domain controllers, DNS servers, and other infrastructure VMs. This subnet will have strict NSGs.
DatabaseSubnet (10.20.20.0/24): For database servers. This subnet will have the most restrictive NSGs, likely denying all traffic except from the web service subnet.
PublicWebServiceSubnet (10.20.30.0/24): For web servers facing the public internet. This subnet will have NSGs allowing HTTP/HTTPS traffic.
Pro Tip: Notice the logical IP numbering scheme (.10.x, .20.x, .30.x). This isn't required, but it makes management and troubleshooting much easier!
Task 3 & 4: Deploying Regional VNets (Manufacturing & Research)
The process is repeated for the other VNets, but the subnet design reflects their different purposes.
ManufacturingVnet (10.30.0.0/16) in West Europe:
This network anticipates massive growth from IoT sensors.
Subnets:
ManufacturingSystemSubnet (10.30.10.0/24): For the systems controlling the operations.
SensorSubnet1 (10.30.20.0/24)
SensorSubnet2 (10.30.21.0/24)
SensorSubnet3 (10.30.22.0/24)
Benefit: Using multiple smaller subnets for sensors allows for fine-grained traffic control and isolation. If one sensor network has an issue, it can be contained.
ResearchVnet (10.40.0.0/16) in Southeast Asia:
A simple, small network for a stable team.
Subnet:
ResearchSystemSubnet (10.40.0.0/24): A single subnet for all resources. This is cost-effective and simple for a small, trusted team.
Task 5: Verification - The Most Important Step
A good engineer always verifies their work.
Go to All resources and confirm all three VNets are listed.
Click into each VNet, navigate to Subnets under Settings, and verify:
All subnets are present.
The address ranges are exactly as designed. A typo here could cause major problems later!
Key Takeaways and Benefits
This project taught me to:
Think in Layers: From the broad resource group down to the precise /27 subnet.
Design for Purpose: Subnets are security boundaries. Their design should reflect the security and connectivity requirements of the resources within them.
Plan for Growth: Choosing large enough address spaces (like /16) prevents a painful redesign down the line.
Embrace Global Scale: Azure makes it simple to deploy consistent, secure networks across the globe, bringing applications closer to users.
This architecture is the foundation for everything else: connecting these VNets via VNet Peering, deploying firewalls, setting up load balancers, and achieving a truly hybrid network. Mastering this is the first and most critical step toward Azure networking expertise.
Let's Connect!
I'm passionate about cloud networking and always open to discussing design patterns, troubleshooting, and the journey towards certifications like the AZ-700. Feel free to leave a comment or connect with me on LinkedIn.
What Azure networking topic should I deep-dive into next? Peering? Network Security Groups? Let me know below! 👇
Top comments (0)