Lesson: Creating Virtual Networks and Subnets

Introduction: The Foundation of Cloud Architecture

In the world of cloud computing, the virtual network is the fundamental building block that defines how your resources communicate with one another and the outside world. Just as a physical data center requires switches, routers, and firewalls to organize its servers, a cloud environment requires a Virtual Network (VNet) to provide isolation, security, and connectivity for your virtual machines, databases, and application services. Without a well-structured network, your cloud infrastructure would be an unmanaged, insecure, and chaotic collection of resources.

Understanding how to design, create, and manage virtual networks and subnets is not just a task for network engineers; it is a critical skill for every cloud practitioner. Whether you are deploying a simple web application or a complex, multi-tier enterprise system, the way you carve up your IP address space into subnets dictates your ability to scale, your security posture, and your ability to troubleshoot connectivity issues effectively. This lesson will guide you through the conceptual framework of virtual networking and provide the practical knowledge required to implement them in a production environment.

Understanding Virtual Networks (VNets)

At its core, a Virtual Network is a private, isolated space within a public cloud provider’s infrastructure where you can launch resources. Think of it as your own private data center in the cloud. When you create a VNet, you are essentially defining a range of private IP addresses that your resources will use. These addresses are not routable on the public internet by default, which provides a layer of inherent security.

A VNet allows you to group resources, control traffic flow, and connect your cloud environment to your on-premises data centers or other virtual networks. By default, resources within the same VNet can communicate with each other, but resources in different VNets cannot communicate unless you explicitly configure a connection, such as VNet peering or a VPN gateway. This isolation is the primary mechanism for preventing unauthorized access between different environments, such as separating your development, testing, and production workloads.

The Role of IP Address Spaces

When you define a VNet, you must specify an address space using Classless Inter-Domain Routing (CIDR) notation. For example, you might choose an address space of 10.0.0.0/16. This provides you with 65,536 IP addresses (from 10.0.0.0 to 10.0.255.255). Selecting the right size for your address space is critical because, in many cloud platforms, changing the address space of a VNet after it has been created can be difficult or impossible without deleting and recreating the network.

Callout: Private IP Address Ranges When choosing an address space for your VNet, it is best practice to stick to the private IP ranges defined in RFC 1918. These are:

1. 10.0.0.0 to 10.255.255.255 (10.0.0.0/8)
2. 172.16.0.0 to 172.31.255.255 (172.16.0.0/12)
3. 192.168.0.0 to 192.168.255.255 (192.168.0.0/16) Using these ranges ensures that your cloud resources will not conflict with public internet IP addresses, and they are standard practice for internal network routing.

The Purpose and Utility of Subnets

While a VNet provides the boundary for your private cloud space, subnets allow you to segment that space into smaller, more manageable pieces. A subnet is a range of IP addresses within your VNet. By dividing your VNet into multiple subnets, you can organize your resources by function, security requirements, or geographical location.

For example, you might create a "Web" subnet for your public-facing servers, an "App" subnet for your business logic servers, and a "Data" subnet for your databases. This segmentation is the first step toward implementing a "Defense in Depth" strategy. By separating your database from your web servers, you can apply stricter firewall rules (often called Network Security Groups) to the database subnet, ensuring that only the application servers can communicate with it, while blocking direct access from the internet.

Subnet Sizing and Planning

One of the most common pitfalls when creating subnets is poor planning regarding IP address allocation. If you create a subnet that is too small, you will quickly run out of available IP addresses as you scale your infrastructure, forcing you to add more subnets or move your resources to a different network. If you create subnets that are too large, you might waste valuable IP address space that could have been used elsewhere in your environment.

When calculating the size of your subnets, always account for the future growth of your applications. It is often better to have fewer, larger subnets than to have many tiny subnets that are difficult to manage and prone to address exhaustion. Additionally, remember that cloud providers typically reserve a few IP addresses in every subnet for their own internal use, such as the network address, the gateway address, and the broadcast address.

Note: Most cloud providers reserve five IP addresses in every subnet. For example, in a /24 subnet (256 addresses), only 251 addresses will be available for your virtual machines or other resources.

Best Practices for Network Design

Designing a virtual network is an exercise in balancing flexibility with security. A well-designed network should be easy to manage, easy to secure, and capable of growing with your organization. Below are some industry-standard best practices to guide your design process.

1. Avoid Overlapping IP Ranges: If you plan to connect your VNet to other networks (like an on-premises data center or another VNet), ensure that the IP address ranges do not overlap. If you use 10.0.0.0/16 for your VNet and your on-premises network also uses 10.0.0.0/16, routing traffic between the two will be impossible because the routers will not know which destination the traffic belongs to.
2. Use Descriptive Naming Conventions: Give your VNets and subnets names that clearly describe their purpose, environment, and region. For example, vnet-prod-east-01 and snet-prod-web-01 are much more descriptive than vnet1 or subnet1.
3. Implement Least Privilege: Use subnets to enforce the principle of least privilege. Only allow traffic that is strictly necessary for the application to function.
4. Plan for Future Expansion: When allocating address space, leave room for future subnets. You do not need to use all your available address space immediately, but you should have a clear roadmap for how the remaining space will be used as the environment grows.
5. Use Network Security Groups (NSGs): Always associate security groups with your subnets or individual network interfaces. These act as virtual firewalls, allowing you to define granular rules for inbound and outbound traffic.

Step-by-Step Implementation: Creating a VNet and Subnet

Let's walk through the process of creating a virtual network and a subnet. While specific commands vary by cloud provider, the logic remains consistent across the industry. We will use a generic command-line approach that mirrors how most cloud platforms function.

Step 1: Define the Virtual Network

First, you must create the VNet container. You will need to specify a name, a region, and the primary address space.

# Example: Creating a VNet with a 10.0.0.0/16 address space
cloud-cli network create \
  --name "vnet-company-prod" \
  --location "eastus" \
  --address-prefix "10.0.0.0/16"

In this command, we define the scope of our network. The address-prefix is the most important part here, as it defines the entire pool of IP addresses available to this network.

Step 2: Create Subnets

Once the VNet exists, you can begin carving it into subnets. You should create multiple subnets for different layers of your application.

# Example: Creating a Web Subnet (10.0.1.0/24)
cloud-cli network subnet create \
  --vnet-name "vnet-company-prod" \
  --name "snet-web" \
  --address-prefix "10.0.1.0/24"

# Example: Creating a Database Subnet (10.0.2.0/24)
cloud-cli network subnet create \
  --vnet-name "vnet-company-prod" \
  --name "snet-db" \
  --address-prefix "10.0.2.0/24"

By defining these as 10.0.1.0/24 and 10.0.2.0/24, we have carved out two distinct segments from our original 10.0.0.0/16 space. This allows us to manage them independently.

Step 3: Verify the Configuration

After creating your resources, you should always verify that the configuration matches your design. Most platforms provide a "list" or "describe" command to view the current state of your network.

# Example: Listing subnets in a VNet
cloud-cli network subnet list \
  --vnet-name "vnet-company-prod"

Comparison: VNet Peering vs. VPN Gateways

Sometimes, you need to connect two different VNets together. Understanding the difference between VNet peering and VPN gateways is essential for choosing the right architecture.

Callout: When to use which? Use VNet Peering whenever possible, especially if your VNets are in the same region. It is essentially a high-speed backbone connection provided by the cloud vendor. Use VPN Gateways when you need to connect to an external physical data center or when you have very specific encryption and compliance requirements that demand a managed tunnel.

Common Pitfalls and How to Avoid Them

Even experienced engineers run into issues when managing virtual networks. Being aware of these common traps can save you hours of troubleshooting.

1. The "Address Exhaustion" Trap

This occurs when you choose a subnet size that is too small for the number of resources you intend to deploy.

• Avoidance: Always calculate the maximum number of resources you expect to have in a subnet, add a 20-30% buffer for growth, and choose a CIDR block that supports that number. Remember to account for the reserved IP addresses mentioned earlier.

2. The "Circular Routing" Trap

This happens when you accidentally create routes that cause traffic to loop back on itself, effectively killing network performance or causing connectivity to drop.

• Avoidance: Keep your routing tables simple. Avoid complex, multi-hop routing configurations unless they are strictly necessary for a hub-and-spoke network topology. Always document your route tables clearly.

3. Over-Reliance on Default Settings

Many cloud platforms provide a "default" VNet configuration that is often too permissive or lacks the structure needed for a production environment.

• Avoidance: Always create custom VNets and subnets. Never rely on the default networking environment for production workloads. Customization allows you to align the network with your specific security and organizational policies.

4. Ignoring Network Security Groups (NSGs)

Creating a VNet and subnet without applying NSGs is like building a house without locking the front door.

• Avoidance: Adopt a "deny-by-default" policy. Your NSGs should explicitly allow only the traffic that is required, and deny all other traffic by default.

Advanced Configuration: Network Security Groups (NSGs)

While the VNet and subnet provide the structure, the Network Security Group (NSG) provides the control. An NSG contains a list of security rules that allow or deny network traffic to resources connected to a VNet. You can associate an NSG with a subnet or with a specific network interface (the virtual equivalent of a network card).

How NSG Rules Work

Each rule in an NSG is processed in priority order. When a packet arrives, the cloud platform checks the rules from the lowest priority number (e.g., 100) to the highest. As soon as a rule matches the packet, the action (Allow or Deny) is taken, and no further rules are processed. This is why rule ordering is so important.

# Example: Creating an NSG rule to allow HTTP traffic
cloud-cli network nsg rule create \
  --nsg-name "nsg-web" \
  --name "allow-http" \
  --priority 100 \
  --destination-port-ranges 80 \
  --protocol Tcp \
  --access Allow

Best Practices for NSGs

• Use Specific Rules: Avoid using "Any" or "*" when defining source or destination IP addresses. Be as specific as possible to reduce the attack surface.
• Document Your Rules: Because NSGs can become complex, maintain documentation that explains why a specific rule exists. This is invaluable during security audits.
• Monitor Traffic: Many cloud platforms provide traffic flow logs. Enable these logs to gain visibility into what traffic is being allowed or denied by your NSGs. This can help you identify misconfigured rules or potential security threats.

Troubleshooting Connectivity Issues

Connectivity issues are the most common problems in virtual networking. When a resource cannot connect to another, follow a systematic approach to identify the root cause:

1. Check Local Firewalls: Is the software firewall on the virtual machine (like iptables or Windows Firewall) blocking the traffic?
2. Check NSGs: Is the NSG attached to the subnet or the NIC blocking the traffic? Review the rules to see if a "Deny" rule is overriding your "Allow" rule.
3. Check Route Tables: Is there a route that prevents the traffic from reaching its destination? A custom route might be sending traffic to an incorrect gateway or virtual appliance.
4. Check VNet Peering/VPN Status: If the resources are in different networks, is the peering connection active? Is the VPN tunnel up and passing traffic?
5. Use Diagnostic Tools: Most cloud providers offer built-in diagnostic tools like "Connection Troubleshoot" or "Packet Capture." Use these to see exactly where the traffic is being dropped.

Tip: When troubleshooting, start from the resource itself and work outward. Check the virtual machine, then the NIC, then the subnet, then the VNet, and finally the connection between VNets. This "inside-out" approach is often faster than guessing where the problem lies.

Integrating with On-Premises Networks

In many enterprise scenarios, your virtual network is just one part of a larger, hybrid environment. Connecting your cloud VNet to an on-premises data center requires careful planning.

Hybrid Connectivity Options

• Site-to-Site VPN: Creates an encrypted tunnel between your VNet and your on-premises router over the public internet. It is cost-effective but relies on the quality of your internet connection.
• Dedicated Private Connection: Provides a private, dedicated connection (like a fiber cross-connect) between your data center and the cloud provider's edge. This offers consistent bandwidth and lower latency but is significantly more expensive and takes longer to set up.

When planning hybrid connectivity, you must ensure that your on-premises IP ranges do not overlap with your VNet address spaces. Additionally, you will need to update your on-premises routing tables to know how to reach the cloud subnets, and update your cloud route tables to know how to reach the on-premises subnets.

Scaling Your Network Architecture

As your organization grows, a single VNet may no longer be sufficient. You might need to implement a "Hub-and-Spoke" architecture. In this model, you have a central "Hub" VNet that handles shared services like firewalls, VPN gateways, and DNS, and multiple "Spoke" VNets that house your specific application workloads.

The Spokes are peered to the Hub, allowing them to communicate with each other through the Hub's security controls. This architecture is highly scalable and makes it much easier to manage security and connectivity across hundreds of virtual networks. It also enforces central governance, as you can control all traffic routing through the Hub's appliances.

Security Considerations for Virtual Networks

Security is not a one-time configuration; it is an ongoing process. Beyond NSGs, consider these additional layers of security:

• Application Security Groups (ASGs): ASGs allow you to group your VMs based on their function (e.g., "Web-Servers", "DB-Servers") and apply security rules to the entire group, rather than individual IP addresses. This makes rule management much more dynamic and easier to maintain.
• Virtual Appliances: For advanced security, you can deploy virtual firewalls or intrusion detection systems (IDS) within your VNet. These appliances can perform deep packet inspection that standard NSGs cannot.
• Private Endpoints: For cloud-native services (like storage or databases), use Private Endpoints. This allows these services to appear as if they are inside your VNet, removing the need to expose them to the public internet.

Summary: A Checklist for Success

When you are ready to build your virtual network, keep this checklist in mind to ensure you haven't missed any critical steps:

1. Define Address Spaces: Ensure they are from private RFC 1918 ranges and do not overlap with existing networks.
2. Segment into Subnets: Create logical subnets for different tiers of your application (e.g., Web, App, Data).
3. Implement Security: Apply NSGs to all subnets immediately. Do not leave resources exposed.
4. Plan for Routing: Determine how traffic will flow between subnets and outside the VNet.
5. Document Everything: Maintain a network diagram and an IP address spreadsheet.
6. Test Connectivity: Verify that your security rules are working as expected by testing from within the network.
7. Monitor: Set up logs and alerts for any unusual network activity.

Key Takeaways

The configuration and management of virtual networks and subnets serve as the backbone of your cloud infrastructure. By mastering the concepts of IP address management, subnetting, and security group configuration, you gain the ability to build scalable, secure, and resilient applications.

• VNets are Isolated: They provide a private, containerized environment that keeps your resources secure by default.
• Subnetting is for Organization: Use subnets to group resources logically and enforce security policies at the functional level of your application.
• Plan IP Ranges Carefully: Overlapping IP ranges are a major source of connectivity failure. Always use RFC 1918 private address ranges and plan for future growth.
• Security is Layered: Use NSGs to control traffic flow and implement a "deny-by-default" strategy to minimize your attack surface.
• Troubleshooting is Systematic: When connectivity fails, follow a logical path from the source resource to the destination, checking firewalls, route tables, and peering connections.
• Design for Scale: Consider a Hub-and-Spoke architecture as your environment grows to maintain central control and governance.
• Infrastructure as Code: Whenever possible, use tools like Terraform or CloudFormation to define your networks. This ensures consistency, repeatability, and version control for your infrastructure.

By adhering to these principles, you move beyond simply "turning on" cloud resources and start architecting professional-grade environments that can support the most demanding business requirements. Virtual networking is a skill that rewards careful planning, consistent documentation, and a deep understanding of how traffic flows across your infrastructure.