Network Segmentation

Network segmentation creates boundaries between groups of systems so that connectivity follows security requirements instead of being universally available. Typical boundaries separate production from development, internet-facing components from internal services, and application servers from sensitive databases. The objective is to reduce the paths an attacker can use and limit the blast radius of a compromised workload. Start by identifying required communication: which source must reach which destination, on what protocol and port, and for what operational purpose.

Cloud networks implement these boundaries using virtual networks, subnets, routing, and traffic filtering. In AWS, an Amazon VPC provides a logically isolated network, and each subnet occupies one Availability Zone. Route tables determine where subnet traffic is directed. An internet gateway supports direct internet connectivity, while a NAT gateway can provide outbound IPv4 internet access for workloads without exposing them to unsolicited inbound connections through that gateway. NAT is not a substitute for traffic filtering or application-aware egress inspection.

A public subnet has a route to an internet gateway. That designation does not automatically expose every resource: direct IPv4 internet communication also requires suitable public addressing and permissive security controls. A private subnet lacks a direct route to an internet gateway but may have outbound access through NAT. An isolated subnet has no route for internet access, including through NAT, although it can retain explicitly permitted private connectivity. Private service endpoints can provide access to supported cloud services without requiring an internet route.

Subnets alone do not enforce application isolation. Within an AWS VPC, route tables normally include local routing between its address ranges. Security groups provide stateful filtering on associated network interfaces, while network ACLs provide stateless subnet-level filtering. Security groups contain allow rules; network ACLs support allow and deny rules and require explicit consideration of return traffic. Network ACLs do not filter traffic between resources in the same subnet, so workload-level controls remain important.

North/south traffic crosses a defined environment boundary, such as traffic between the internet and an application. East/west traffic moves between workloads or internal segments. Protecting an internet entry point does not prevent lateral movement between application servers and databases. For a three-tier application, permit HTTPS to the public load balancer, permit application traffic only from the load balancer to the application tier, and permit database connections only from the application tier. Where supported, security group references can express these relationships without relying on changing instance IP addresses.

Stronger boundaries may use separate virtual networks or accounts, with explicitly controlled connectivity through a transit network or inspection firewall. Central inspection only works when routing actually sends the relevant traffic through the firewall; stateful inspection also requires consistent forward and return paths. Additional boundaries increase route management, policy maintenance, troubleshooting effort, and potentially cost and latency. Validate both permitted and prohibited paths using connectivity analysis, flow logs, and controlled tests. When troubleshooting, inspect routes, security groups, network ACLs, firewall policy, addressing, and return paths rather than assuming that a private subnet is inherently isolated.