8.2 Cloud Virtual Networks, Subnetting, Security Groups & Microsegmentation

8.2 Cloud Virtual Networks, Subnetting, Security Groups & Microsegmentation

Quick Answer: In cloud computing, physical networks are abstracted by Software-Defined Networking (SDN), which decouples the centralized Control Plane (route logic and policy) from the distributed Data Plane (packet forwarding). Tenants operate within isolated Virtual Private Clouds (VPCs) built on overlay networks (such as VXLAN and Geneve). Network traffic is regulated through tiered subnets: public subnets route traffic directly through an Internet Gateway (IGW), while private subnets egress securely through a NAT Gateway. At the packet layer, cloud platforms enforce defense-in-depth through two distinct filtering mechanisms: Security Groups (stateful, applied at the instance vNIC level, automatic return traffic tracking) and Network ACLs (stateless, applied at the subnet boundary, requiring explicit bidirectional rules and ephemeral port ranges). To stop attackers from traversing networks laterally, organizations implement microsegmentation, eliminating flat architectures by enforcing least-privilege Zero Trust boundaries on all East-West communication.

In legacy on-premises datacenters, physical switches, routers, and VLAN trunking (IEEE 802.1Q) defined network topology. Network reconfigurations required physical cabling, manual switch port tagging, and dedicated hardware appliances. Cloud computing completely replaces physical network administration with programmable Software-Defined Networking (SDN), shifting network security from perimeter hardware boxes to declarative, API-driven policy controls.

---

Cloud Software-Defined Networking (SDN) & VPC Topologies

Cloud SDN architectures enforce a strict mathematical separation between two operational planes:

1. The Control Plane: The centralized, software-driven brain of the cloud network. It handles network configuration, routing policy distribution, IP address management (IPAM), and security rule translation. When an administrator creates a route or updates a firewall rule via API or console, the Control Plane validates and compiles the policy.
2. The Data Plane (Forwarding Plane): The physical network infrastructure (Spine-Leaf Clos network topology) and virtual switches (vSwitches) residing in the hypervisor. The Data Plane blindly forwards, encapsulates, and filters physical packets at wire speed based on forwarding tables pushed down by the Control Plane.

┌────────────────────────────────────────────────────────────────────────┐
│                     CLOUD OVERLAY NETWORKING (SDN)                     │
├────────────────────────────────────────────────────────────────────────┤
│  TENANT VIRTUAL PRIVATE CLOUD (VPC / VNET)                             │
│  ┌──────────────────────────────┐     ┌──────────────────────────────┐ │
│  │ Tenant VM 1 (IP: 10.0.1.15)  │     │ Tenant VM 2 (IP: 10.0.2.88)  │ │
│  └──────────────┬───────────────┘     └──────────────┬───────────────┘ │
│                 │ Virtual L3 Packet                  │                 │
│                 ▼                                    ▼                 │
│  ┌──────────────────────────────────────────────────────────────────┐  │
│  │ Hypervisor vSwitch / Hardware Offload (AWS Nitro / SmartNIC)     │  │
│  │ Encapsulation: Inner Packet (Tenant IP) encapsulated in:         │  │
│  │ Outer Packet: VXLAN (RFC 7348) / Geneve (RFC 8926) + Physical IP │  │
│  └──────────────────────────────┬───────────────────────────────────┘  │
│                                 │ Encapsulated UDP Frames              │
│                                 ▼                                      │
│  ┌──────────────────────────────────────────────────────────────────┐  │
│  │ PHYSICAL UNDERLAY NETWORK (Spine-Leaf Clos Fabric / 100-400 Gbps)│  │
│  │ Physical Top-of-Rack Switches / BGP ECMP Line-Rate Forwarding    │  │
│  └──────────────────────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────────────────────┘

Overlay Networks (VXLAN & Geneve)

Physical datacenter switches cannot maintain routing tables for millions of dynamic tenant IP addresses. Instead, cloud providers employ Overlay Networks:

• The tenant's virtual network packet (the inner packet, containing private RFC 1918 IPs) is encapsulated inside a standard UDP packet (the outer packet) by the hypervisor vSwitch before entering the physical datacenter fabric.
• Encapsulation Protocols: Modern cloud providers use VXLAN (Virtual Extensible LAN - RFC 7348) using UDP port 4789, or Geneve (Generic Network Virtualization Encapsulation - RFC 8926) using UDP port 6081. While legacy VLANs support only 4,096 logical segments (12-bit VLAN ID), VXLAN and Geneve utilize a 24-bit Virtual Network Identifier (VNI), supporting up to 16,777,216 isolated virtual networks on the same physical underlay.

Virtual Private Clouds (VPCs) and Subnet Architecture

A Virtual Private Cloud (VPC) (or Azure Virtual Network / VNet) is an isolated, software-defined Layer 3 network domain bound to a customer account. Within a VPC, administrators allocate private IPv4 CIDR blocks (under RFC 1918: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) and optional IPv6 CIDR blocks (/56).

VPCs are subdivided into Subnets, each mapped to a specific Availability Zone (AZ) to ensure fault tolerance. Subnets are classified strictly by their routing tables:

┌─────────────────────────────────────────────────────────────────────────┐
│                     THREE-TIER VPC ROUTING TOPOLOGY                     │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│                      INTERNET GATEWAY (IGW)                             │
│                                ▲                                        │
│                                │ 0.0.0.0/0                              │
│       ┌────────────────────────┴─────────────────────────┐              │
│       │ PUBLIC SUBNET (10.0.1.0/24)                      │              │
│       │ • Public Load Balancers (ALB)                   │              │
│       │ • NAT Gateway (Elastic IP: 54.210.10.5) ────────┐│              │
│       └─────────────────────────────────────────────────┼┘              │
│                                                         │ 0.0.0.0/0     │
│                                                         │ (Egress Only) │
│       ┌─────────────────────────────────────────────────┼┐              │
│       │ PRIVATE APPLICATION SUBNET (10.0.2.0/24)        ││              │
│       │ • Backend Microservices / Compute Instances <───┘│              │
│       │ • No Direct Inbound Internet Path                │              │
│       └────────────────────────┬─────────────────────────┘              │
│                                │ Local DB Query                         │
│                                ▼ (Port 5432)                            │
│       ┌──────────────────────────────────────────────────┐              │
│       │ ISOLATED DATABASE SUBNET (10.0.3.0/24)           │              │
│       │ • Database Clusters / Secrets Vaults             │              │
│       │ • ZERO Internet Routing (No IGW, No NAT Route)   │              │
│       │ • Access only via PrivateLink / VPC Endpoints    │              │
│       └──────────────────────────────────────────────────┘              │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

1. Public Subnet:
   • Route table contains a default route directing non-local traffic to an Internet Gateway (IGW) (0.0.0.0/0 -> igw-xxxx).
   • Compute instances must possess a public IPv4 address (or Elastic IP) to communicate with external entities over the internet.
   • Workloads: Public-facing Application Load Balancers (ALBs), bastion hosts, and NAT Gateways.
2. Private Subnet:
   • Route table lacks an Internet Gateway route. Instead, internet-bound traffic is routed to a Network Address Translation (NAT) Gateway (0.0.0.0/0 -> nat-xxxx) residing in the public subnet.
   • Workloads possess only private RFC 1918 IP addresses. The NAT Gateway performs Source Network Address Translation (SNAT), allowing private instances to initiate outbound connections (e.g., OS security patches, external API calls) while completely preventing external internet entities from initiating inbound connections to the private instances.
   • Workloads: Application servers, internal microservices, backend workers.
3. Isolated / Data Subnet:
   • Route table contains no default internet route (0.0.0.0/0 is entirely absent). Traffic is strictly confined to intra-VPC communication.
   • Connectivity to cloud provider PaaS services (e.g., S3, DynamoDB, Key Vault) is achieved privately using VPC Endpoints / PrivateLink, bypassing public IP routing entirely.
   • Workloads: Production databases, hardware security modules (CloudHSM), sensitive financial repositories.

[!NOTE] Reserved IP Addresses in Cloud Subnets: In almost all cloud platforms (e.g., AWS VPC), the provider automatically reserves the first four IP addresses and the last IP address of every subnet CIDR block. For example, in a 10.0.0.0/24 subnet: 10.0.0.0 (Network address), 10.0.0.1 (VPC router), 10.0.0.2 (DNS resolver), 10.0.0.3 (Future use), and 10.0.0.255 (Network broadcast). A /24 subnet yields 251 usable IP addresses, not 256.

---

Stateful vs. Stateless Filtering: Security Groups vs. Network ACLs

Cloud infrastructure enforces network filtering at two distinct architectural layers: the instance network interface (vNIC) and the subnet perimeter.

┌────────────────────────────────────────────────────────────────────────┐
│                     SECURITY GROUPS VS. NETWORK ACLS                   │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│   INTERNET / INCOMING PACKET                                           │
│       │                                                                │
│       ▼                                                                │
│  ┌──────────────────────────────────────────────────────────────────┐  │
│  │ SUBNET BOUNDARY: NETWORK ACL (NACL)                              │  │
│  │ • STATELESS: Does NOT track connection state.                    │  │
│  │ • Evaluates every packet independently.                         │  │
│  │ • Numbered rules (e.g., Rule 100, 200, *) in ascending order.   │  │
│  │ • Supports explicit ALLOW and DENY rules.                        │  │
│  │ • Inbound and Outbound return paths must be explicitly opened.   │  │
│  └──────────────────────────────┬───────────────────────────────────┘  │
│                                 │ Passed NACL Check                    │
│                                 ▼                                      │
│  ┌──────────────────────────────────────────────────────────────────┐  │
│  │ INSTANCE BOUNDARY: SECURITY GROUP (SG)                           │  │
│  │ • STATEFUL: Uses hypervisor connection tracking (conntrack).     │  │
│  │ • If Inbound is allowed, Return Outbound is AUTOMATICALLY allowed.│  │
│  │ • No explicit DENY rules; default deny with ALLOW whitelist.    │  │
│  │ • Applied directly to the Virtual Network Interface (vNIC/ENI).  │  │
│  │ • Supports Security Group ID referencing (dynamic membership).   │  │
│  └──────────────────────────────┬───────────────────────────────────┘  │
│                                 │ Passed SG Check                      │
│                                 ▼                                      │
│                      [ GUEST VIRTUAL MACHINE ]                         │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘

1. Security Groups (Stateful Filtering)

Security Groups act as a virtual firewall for compute instances, enforced directly at the hypervisor's virtual network interface card (vNIC / ENI).

• Stateful Connection Tracking: Security Groups maintain a connection state table (conntrack) in the hypervisor. When an inbound packet matches an ALLOW rule, the hypervisor automatically records the 5-tuple flow (source IP, destination IP, source port, destination port, protocol). Return outbound traffic for that established session is automatically permitted, bypassing outbound rule evaluation. The inverse is also true: outbound requests automatically permit return inbound responses.
• Rule Philosophy: Whitelist only. All rules are permissive (ALLOW). There are no explicit DENY rules. Any packet not explicitly matched by an allow rule is dropped by the default implicit deny.
• Dynamic Security Group Referencing: Rather than writing rules targeting static IP addresses or CIDR blocks, Security Groups can reference other Security Group IDs as sources or destinations (e.g., allowing port 5432 ingress only from sg-appserver). When new application instances scale up dynamically, they inherit sg-appserver and immediately gain database access without manual IP modifications.

2. Network Access Control Lists (NACLs) (Stateless Filtering)

Network ACLs operate as a secondary layer of defense, enforced at the perimeter boundary of an entire subnet.

• Stateless Operation: NACLs maintain zero connection state memory. Every single packet—inbound or outbound, request or response—is evaluated as a completely independent event against the rule table.
• Rule Processing: Rules are assigned explicit numerical indices (e.g., Rule 100, Rule 200, Rule *). Packets are evaluated sequentially from lowest rule number to highest. As soon as a packet matches a rule, that rule's action (ALLOW or DENY) is executed immediately, terminating further evaluation.
• Explicit Deny Capability: Unlike Security Groups, NACLs natively support explicit DENY rules. This makes NACLs the primary mechanism for blacklisting compromised IP addresses or malicious subnets before their packets ever reach compute instances.
• The Ephemeral Port Imperative: Because NACLs are stateless, when an instance inside a private subnet initiates an outbound connection (e.g., curl https://api.stripe.com:443), the outbound NACL must allow destination port 443. However, the client OS assigns a high ephemeral port (ranging from 1024 to 65535 depending on OS flavor) as the source port. When the external server responds, its response packet has source port 443 and destination port in the client's ephemeral port range. Therefore, the inbound NACL must have an explicit rule allowing inbound traffic on ports 1024–65535, or the response packet will be dropped at the subnet boundary.

---

Microsegmentation & Zero Trust Network Zoning

Traditional enterprise networks relied on a "castle-and-moat" design: a hardened outer perimeter firewall shielding a wide, unsegmented, flat internal network. In a flat network, once an adversary breaches a single perimeter node (e.g., an unpatched public web server), they enjoy unimpeded network visibility, allowing unrestricted East-West (lateral) movement across internal subnets to access databases, Active Directory domain controllers, and proprietary APIs.

The Microsegmentation Paradigm

Microsegmentation applies the foundational principles of Zero Trust Architecture (NIST SP 800-207) directly to network topologies. It decomposes the cloud environment into granular, cryptographically isolated zones, enforcing the doctrine: "Assume breach; verify explicitly; never trust, always verify."

┌────────────────────────────────────────────────────────────────────────┐
│                     MICROSEGMENTATION TRAFFIC FLOWS                    │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│       NORTH-SOUTH TRAFFIC (External Client to Cloud Datacenter)        │
│       ═════════════════════════════════════════════════════════        │
│       Public User ──► [ Edge WAF / CDN ] ──► [ Public ALB ]            │
│                                                     │                  │
│  ┌──────────────────────────────────────────────────┼───────────────┐  │
│  │ CLOUD VIRTUAL PRIVATE CLOUD (VPC)                │               │  │
│  │                                                  ▼               │  │
│  │ ┌──────────────────────────────────────────────────────────────┐ │  │
│  │ │ WEB TIER (Security Group: sg-webtier)                        │ │  │
│  │ │ Ingress: Port 443 from ALB only                              │ │  │
│  │ └──────────────────────────────┬───────────────────────────────┘ │  │
│  │                                │ EAST-WEST LATERAL TRAFFIC       │  │
│  │                                │ (Strict Microsegmentation)      │  │
│  │                                ▼                                 │  │
│  │ ┌──────────────────────────────────────────────────────────────┐ │  │
│  │ │ APPLICATION TIER (Security Group: sg-apptier)                │ │  │
│  │ │ Ingress: Port 8080 from sg-webtier ONLY                      │ │  │
│  │ │ DENIED: Any direct access from Public ALB or Internet        │ │  │
│  │ └──────────────────────────────┬───────────────────────────────┘ │  │
│  │                                │ EAST-WEST LATERAL TRAFFIC       │  │
│  │                                │ (mTLS + Port 5432 Enforcement)  │  │
│  │                                ▼                                 │  │
│  │ ┌──────────────────────────────────────────────────────────────┐ │  │
│  │ │ DATABASE TIER (Security Group: sg-dbtier)                    │ │  │
│  │ │ Ingress: Port 5432 from sg-apptier ONLY                      │ │  │
│  │ │ BLOCKED: All traffic from sg-webtier, public ALB, or egress  │ │  │
│  │ └──────────────────────────────────────────────────────────────┘ │  │
│  └──────────────────────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────────────────────┘

North-South vs. East-West Traffic

• North-South Traffic: Data moving into or out of the cloud datacenter (client-to-server, or cloud-to-internet). Defended via Edge Firewalls, DDoS scrubbers, Web Application Firewalls (WAF), and API Gateways.
• East-West Traffic: Data moving laterally between workloads, containers, virtual machines, and microservices inside the cloud datacenter. Studies confirm that over 75% of datacenter traffic is East-West. Without microsegmentation, lateral movement is completely invisible and unconstrained.

Operationalizing Microsegmentation in Cloud

1. Tier-Based Security Group Chaining: Enforce strict unidirectional dependencies between architecture tiers. The Web Tier accepts port 443 from the Load Balancer. The App Tier accepts port 8080 only from sg-webtier. The Database Tier accepts port 5432 only from sg-apptier. If an attacker compromises a Web Tier node, their packets targeting the Database Tier are dropped at the hypervisor layer by sg-dbtier.
2. Service Mesh Architecture (Envoy / Istio): In containerized Kubernetes environments, sidecar proxies intercept all container-to-container network traffic, enforcing Mutual TLS (mTLS) encryption and Layer 7 attribute-based authorization policies (e.g., verifying that Service A possesses a valid SPIFFE identity token before invoking Service B's /checkout endpoint).
3. eBPF-Powered Kernel Microsegmentation (Cilium): Extended Berkeley Packet Filter (eBPF) programs running in the Linux kernel bypass standard IP routing overhead, filtering packets directly at the socket layer based on cryptographic workload identities and application API endpoints, eliminating IP-based firewall bottlenecks.