Subnet Design and Network Segmentation

Subnet Design and Network Segmentation

Watch the video to deepen your understanding.

Subscribe

Earn 25 points (50 with Pro) in two steps

  1. ① Read through the lesson — each section gets a ✓ as you scroll through it.
  2. ② When every section has a ✓, tap Complete lesson.

0 of 3 read · keep scrolling

✦ See fewer ads and earn double points — 50 a lesson instead of 25 — with Pro

Lesson: Subnet Design and Network Segmentation

Introduction

In modern cloud and on-premises infrastructure, a "flat" network—where every device can communicate with every other device—is a significant security and performance liability. Subnetting is the process of dividing a large network into smaller, distinct sub-networks (subnets). Network Segmentation is the architectural practice of isolating these subnets to control traffic flow.

By designing effective subnets, you achieve three primary goals:

  1. Security: Restricting lateral movement for attackers.
  2. Performance: Reducing broadcast traffic and congestion.
  3. Manageability: Organizing resources based on function, environment, or sensitivity.

The Mechanics of Subnetting

Subnetting relies on the Subnet Mask (or CIDR notation), which tells a device which part of an IP address represents the network and which part represents the individual host.

Practical Example: Designing a Three-Tier Architecture

Imagine you are deploying a web application. A secure design requires three distinct segments:

  • Public Tier (DMZ): Contains Load Balancers and Web Servers.
  • Application Tier: Contains the business logic servers.
  • Data Tier: Contains databases.

If we have the network range 10.0.0.0/16, we can divide it as follows:

Tier Subnet Range CIDR Purpose
Public 10.0.1.0/24 /24 Internet-facing assets
App 10.0.2.0/24 /24 Internal logic
Data 10.0.3.0/24 /24 Sensitive storage

Code Snippet: Defining Subnets (Terraform)

When deploying infrastructure as code (IaC), you define these boundaries explicitly. Below is a snippet using Terraform for an AWS VPC:

resource "aws_subnet" "public_subnet" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
  tags = { Name = "Public-Tier" }
}

resource "aws_subnet" "data_subnet" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.3.0/24"
  tags = { Name = "Data-Tier" }
}

Not read yet

Network Segmentation Strategies

Segmentation is not just about IP ranges; it is about the policies enforced between them.

1. Security Groups (Stateful Firewalls)

Security groups act as virtual firewalls at the instance level. They allow you to define "Allow" rules.

  • Best Practice: The Database subnet should only accept traffic on port 5432 (PostgreSQL) from the Application subnet's IP range. It should deny all traffic from the Public subnet.

2. Network Access Control Lists (NACLs)

NACLs act at the subnet level and are stateless. They are often used as a "second line of defense" to block specific malicious IP ranges or to provide a coarse-grained filter for all traffic entering or leaving a subnet.

3. Micro-segmentation

In advanced environments, you may implement micro-segmentation, where security policies are applied to individual workloads or containers regardless of their physical location or subnet. This is common in Kubernetes environments using Network Policies.

💡 Pro-Tip: The Principle of Least Privilege

Always design your network segments so that resources only communicate with the specific services they require to function. If a web server doesn't need to talk to the database directly (because it talks to the app server instead), the network policy should explicitly block that connection.


Not read yet

Best Practices

  1. Plan for Growth: Do not create subnets that are too small. If you anticipate needing 200 hosts, use a /24 (256 addresses) rather than a /25 (128 addresses) to allow for future expansion.
  2. Use Non-Overlapping Ranges: If you plan to connect your VPC/Network to a corporate office or another cloud environment, ensure your IP ranges do not overlap. This is the #1 cause of routing failures.
  3. Separate Environments: Always keep Production, Staging, and Development in separate VPCs or at least separate, strictly firewalled subnets. Never allow a Dev server to initiate a connection to a Production database.
  4. Automate Policy: Use Infrastructure as Code (IaC) to define your segmentation. Manual changes in a web console lead to "configuration drift," where security rules become inconsistent over time.

Common Pitfalls

  • The "One Subnet for Everything" Trap: Avoid putting all your assets in a single subnet just because it is easier to configure. This makes security auditing and traffic monitoring nearly impossible.
  • Over-reliance on IP Filtering: Remember that IP addresses are dynamic. Use tags or security group referencing (e.g., "Allow traffic from Security Group A") rather than hardcoding IP addresses in your rules.
  • Ignoring Egress Traffic: Most engineers focus on ingress (what comes in). Don't forget to restrict egress (what goes out). Databases should generally not be able to initiate outbound connections to the public internet.

Key Takeaways

  • Subnetting is the logical division of your network IP space to organize resources and improve performance.
  • Segmentation uses firewalls, NACLs, and routing policies to control traffic flow between those subnets.
  • Tiered Architecture (Public/App/Data) is the industry standard for securing applications.
  • Security is iterative: Always apply the Principle of Least Privilege. If a service doesn't need a connection, block it by default.
  • Automation is essential: Use IaC to ensure network configurations are version-controlled, repeatable, and auditable.

By mastering subnet design, you transition from simply "connecting computers" to building a resilient, defensible infrastructure capable of scaling with your organization's needs.

Not read yet

Each section gets a ✓ as you scroll through it. Tap the button to jump to the next one.