In the previous pages, we explored how virtual switches, overlay networks, and VXLAN enable the creation of isolated virtual networks. But having the capability to isolate networks is only half the challenge—the other half is designing an intelligent segmentation strategy that balances security, operational efficiency, and application performance.

Network segmentation is the practice of dividing a computer network into smaller, isolated sub-networks (segments) to improve security, performance, and manageability. It's a foundational security principle based on the concept of defense in depth: even if an attacker breaches one segment, they cannot easily move to others.

The importance of segmentation has never been greater. Modern threats don't simply breach the perimeter and exfiltrate data—they move laterally within networks, pivoting from initially compromised hosts to high-value targets. Without proper segmentation, a compromised developer workstation can reach production databases, an infected IoT device can access financial systems, and a single malware instance can spread across an entire enterprise.

This page explores segmentation strategies from traditional VLANs through microsegmentation and zero-trust architectures, providing the conceptual framework to design robust, secure network architectures in virtualized and cloud environments.

Network segmentation creates boundaries that control which systems can communicate with each other. The fundamental concept is simple: by default, systems in different segments cannot communicate unless explicitly permitted through controlled pathways.

Core Objectives

1. Limit Blast Radius When a breach occurs (and eventually, it will), segmentation contains the damage. An attacker who compromises a system in the "guest WiFi" segment cannot reach systems in the "financial applications" segment, because there's no network path between them.

2. Reduce Attack Surface By limiting connectivity, you reduce the number of potential attack vectors. A system that can only be reached from one other system has a smaller attack surface than one reachable from anywhere.

3. Enforce Least Privilege Systems receive only the network access they need to perform their function. A web server doesn't need to reach the HR database, so there should be no network path.

4. Simplify Compliance Regulations like PCI DSS, HIPAA, and GDPR require segmentation of sensitive data. Proper segmentation reduces the scope of compliance audits—only the segment containing cardholder data needs PCI compliance, not the entire network.

5. Improve Performance Segmentation reduces broadcast domains, limiting the scope of broadcast traffic. This is particularly important for protocols that rely on broadcasts (ARP, DHCP, some service discovery).

Segmentation exists on a spectrum from coarse-grained (macro) to fine-grained (micro). Different approaches suit different requirements; most modern environments use a combination.

Macro-Segmentation (Traditional)

Macro-segmentation divides the network into large zones based on broad categories: production vs. development, internal vs. DMZ, trusted vs. untrusted. Enforcement happens at zone boundaries using firewalls or routers.

Characteristics:

• Zones contain hundreds or thousands of hosts
• Enforcement at zone perimeter only
• Traffic within a zone is unrestricted
• Implemented via VLANs, VRFs, and physical/virtual firewalls

Limitations:

• Once inside a zone, lateral movement is unrestricted
• Zones become "safe harbors" where attackers can pivot freely
• Changes require reconfiguring perimeter devices

Microsegmentation (Modern)

Microsegmentation applies security policies at the individual workload level—each VM, container, or pod has its own security perimeter. Instead of "systems in this zone can reach systems in that zone," policies specify "this specific application can reach that specific database on port 5432."

Characteristics:

• Policies defined per workload, not per network segment
• Enforcement distributed across all hosts (virtual switch, hypervisor, or container runtime)
• Traffic controlled even within traditional segments
• Policy follows workload during migration

Advantages:

• Dramatically reduces lateral movement capability
• Enables true least-privilege networking
• Policy independent of network topology
• Supports dynamic cloud environments

VLANs remain the foundational technology for network segmentation, creating separate broadcast domains that isolate Layer 2 traffic. Despite the limitations we discussed in overlay networks, VLANs remain essential for physical network segmentation and integration with overlay architectures.

How VLAN Segmentation Works

Layer 2 Isolation: Hosts in different VLANs cannot communicate at Layer 2—no Ethernet frames cross VLAN boundaries. This prevents ARP spoofing, DHCP attacks, and broadcast-based attacks from crossing VLANs.

Inter-VLAN Routing: Communication between VLANs requires Layer 3 routing through a router or Layer 3 switch. This routing point becomes a natural enforcement location for access control.

Scalability Limits: As discussed earlier, the 4,094 VLAN limit constrains large-scale deployments. This is where overlays (VXLAN with 16M+ VNIs) extend segmentation capability.

Common VLAN Segmentation Patterns

Functional Segmentation: Separate VLANs for different functions:

• VLAN 10: Management (infrastructure access)
• VLAN 20: Servers
• VLAN 30: User workstations
• VLAN 40: IoT/OT devices
• VLAN 50: Guest WiFi

Environment Segmentation: Separate VLANs for environments:

• VLAN 100-199: Production
• VLAN 200-299: Staging
• VLAN 300-399: Development
• VLAN 400-499: Test

Application Tier Segmentation: Separate VLANs for application tiers:

• VLAN 10: Web tier (DMZ)
• VLAN 20: Application tier
• VLAN 30: Database tier

While VLANs provide Layer 2 segmentation, Virtual Routing and Forwarding (VRF) provides Layer 3 segmentation by creating multiple, independent routing tables within a single router or switch. This enables complete network path isolation—traffic in different VRFs never intersects, even at Layer 3.

VRF Concepts

Routing Table Isolation: Each VRF maintains its own routing table (RIB) and forwarding table (FIB). Routes in VRF-A are invisible to VRF-B, and vice versa.

Interface Assignment: Network interfaces (physical or logical) are assigned to a specific VRF. An interface can belong to only one VRF.

Overlapping Address Space: Different VRFs can use the same IP address ranges. VRF-A and VRF-B can both use 10.0.0.0/8 because they have completely separate routing tables.

VRF Use Cases

Multi-Tenancy: Service providers use VRFs to completely isolate tenant traffic. Each customer gets their own VRF, ensuring no routing leakage between customers.

Security Zone Isolation: Enterprise networks use VRFs to isolate high-security zones. A "PCI" VRF for payment card data has no routing relationship with a "General" VRF.

Management Separation: A dedicated "Management" VRF carries infrastructure management traffic (SSH, SNMP, syslog) completely separate from production traffic.

VRF-Lite vs. MPLS VRF

VRF-Lite: VRFs are locally significant on each device. Inter-VRF communication requires physical or logical interconnections between devices. Simple but doesn't scale well.

MPLS VPN with VRF: VRFs are extended across an MPLS core using MP-BGP and MPLS labels. VRFs can span entire networks while maintaining isolation. Used by service providers for L3VPN services.

Security Groups are the primary mechanism for microsegmentation in cloud and virtualized environments. Unlike VLANs and VRFs that operate on network constructs, security groups operate on workload identity—applying policies based on what a workload is, not where it is.

Security Group Concepts

Identity-Based Policies: Security groups attach to workloads (VMs, containers, pods) by label, tag, or membership. When a workload moves or scales, its security group membership—and thus its policies—move with it.

Stateful Filtering: Security groups typically implement stateful filtering. When you allow outbound traffic to a destination, return traffic is automatically permitted. This simplifies rules and reduces administrative burden.

Distributed Enforcement: Policies are enforced at the virtual switch on each host, not at a central firewall. This distributes enforcement load and eliminates traffic hairpinning through a chokepoint.

Default Deny: Most security group implementations default to deny—a workload with no security group rules can communicate with nothing. You explicitly add allow rules; everything else is blocked.

Security Group Example

Consider a three-tier web application:

Security Group: web-servers

• Allow inbound HTTP/HTTPS from anywhere (0.0.0.0/0)
• Allow inbound SSH from SG:bastion-hosts
• Allow outbound to SG:app-servers on port 8080

Security Group: app-servers

• Allow inbound port 8080 from SG:web-servers only
• Allow outbound to SG:database-servers on port 5432
• Allow outbound HTTP/HTTPS to internet (for external APIs)

Security Group: database-servers

• Allow inbound port 5432 from SG:app-servers only
• No other inbound allowed
• Allow outbound only for management traffic

The classic multi-tier architecture (web, application, database) provides a natural segmentation model that combines network isolation with security group policies. Let's examine a comprehensive segmentation design for a typical enterprise application.

Defense in Depth Layers

Layer 1: Network Zones (Macro-Segmentation)

• DMZ: Internet-facing load balancers and WAF
• Web Tier: Web servers (internal side of DMZ)
• App Tier: Application servers
• Data Tier: Databases and data stores
• Management: Bastion hosts, monitoring, CI/CD

Layer 2: VLANs/VNIs per Zone

• Each zone maps to one or more VLANs/VNIs
• Zones connected via firewalls or router ACLs

Layer 3: Security Groups per Role

• Within each zone, security groups limit lateral movement
• Web-A and Web-B in same network can't communicate unless permitted

Layer 4: Host-Based Firewall

• Final layer: host firewall (iptables, Windows Firewall)
• Defense in depth—even if network policy fails, host blocks unauthorized traffic

Zero Trust represents a fundamental shift from traditional network security models. The traditional model—"trust but verify" with a hard perimeter and soft interior—assumes that anything inside the network is trusted. Zero Trust inverts this: "never trust, always verify."

Zero Trust Principles

1. Verify Explicitly Always authenticate and authorize based on all available data points:

• User identity (who is requesting?)
• Device health (is the device compliant?)
• Location (where is the request from?)
• Service identity (what service is making the request?)
• Data classification (how sensitive is the data?)

2. Use Least Privilege Access Limit access to the minimum needed for the task:

• Just-in-time access (grant temporarily, revoke automatically)
• Just-enough access (minimum permissions needed)
• Risk-based adaptive policies (adjust based on context)

3. Assume Breach Design as if attackers are already inside:

• Minimize blast radius through microsegmentation
• Use end-to-end encryption (no trusted networks)
• Continuous monitoring and anomaly detection

Zero Trust Network Access (ZTNA)

ZTNA replaces traditional VPNs with application-specific access:

Traditional VPN:

• User authenticates once
• Gets broad network access ("on the network")
• Can reach any system on accessible subnets
• Network is implicitly trusted after connection

ZTNA:

• User authenticates per-application
• Gets access only to authorized applications
• No network-level access—only application tunnels
• Continuous verification (not just at connection time)

Implementing segmentation requires combining the technologies we've discussed into coherent patterns. Here are proven patterns for common scenarios.

Pattern 1: Cloud VPC Segmentation

For AWS, Azure, GCP workloads:

1. VPC/VNet per environment: Separate VPCs for production, staging, development
2. Subnets per tier: Public subnets (load balancers), private subnets (apps, databases)
3. Security groups per workload role: web-sg, app-sg, db-sg
4. Network ACLs as zone boundaries: Additional subnet-level rules for defense in depth
5. Transit Gateway for inter-VPC: Controlled connectivity between environments when needed

Pattern 2: Kubernetes Segmentation

For containerized workloads:

1. Namespaces for environments: production, staging, dev namespaces
2. NetworkPolicy per workload: Kubernetes NetworkPolicy objects control pod-to-pod traffic
3. Service mesh for L7 control: Istio/Linkerd for application-layer policies
4. Default deny per namespace: Start with denying all traffic, explicitly allow required flows

Pattern 3: Hybrid/Multi-Cloud Segmentation

For distributed environments:

1. Consistent VNI/VRF scheme: Same network identifiers across all locations
2. Centralized policy management: Single source of truth for security policies
3. Encrypted site-to-site links: IPsec or SD-WAN between clouds and on-premises
4. Federated identity: Same identity provider across all environments
5. Unified monitoring: Aggregate logs and metrics to single platform for visibility

Network segmentation is not just a technical control—it's a strategic security capability that fundamentally limits attackers' ability to move through your environment. The combination of macro-segmentation (zones), microsegmentation (workload policies), and zero trust principles creates a defense-in-depth architecture that can contain breaches and limit damage.

Next Up: We'll complete our network virtualization journey by exploring Multi-Tenancy—the architectural patterns that enable multiple independent tenants to share physical infrastructure while maintaining complete isolation, privacy, and dedicated resource guarantees.