Network Segmentation

Network Segmentation is the practice of dividing your network into smaller, isolated segments to limit an attacker's ability to move laterally after an initial compromise. In AWS, this is implemented through VPCs, subnets, security groups, and NACLs.

AWS Segmentation Strategies

• Multi-VPC: separate VPCs for production, staging, development
• Public/private subnets: internet-facing resources in public subnets, everything else in private
• Multi-account: separate AWS accounts per workload or environment (strongest isolation)
• Security groups: micro-segmentation at the instance level
• Transit Gateway: controlled routing between VPCs

The Layers, Ranked by Strength

Not all segmentation is equal, and it helps to be explicit about the ordering when you design:

• Account boundary: strongest. IAM principals, resource policies, and quotas all stop at the account line. Cross-account access must be granted explicitly and is auditable.
• VPC boundary: strong at the network layer. Two VPCs cannot reach each other without peering, a transit gateway, or PrivateLink. But a single IAM principal with broad EC2 permissions in the same account can change that.
• Subnet and route table: controls what a workload can reach. A private subnet with no route to an internet gateway cannot initiate outbound internet traffic regardless of security groups.
• Security group: the practical micro-segmentation tool. Stateful, and it can reference other security groups as sources, which lets you express "the app tier may reach the database tier" without hard-coding IP ranges.
• NACL: coarse, stateless subnet-level allow and deny. A useful backstop, limited by a default quota of 20 rules per direction (adjustable to 40).

Segmentation is only real if identity segmentation matches network segmentation. Splitting production and development into separate VPCs while giving the same role ec2:* across both gives you the appearance of isolation and none of the substance.

How It Goes Wrong in Practice

The most common failure is security groups that reference 0.0.0.0/0 internally. A team builds three tiers, then during troubleshooting someone opens the database security group to the full VPC CIDR "temporarily" so a debugging container can connect. The tiers still exist on the diagram, but every instance in the VPC can now reach the database directly. Lateral movement from a compromised web server to the database is a single hop. Use security group references (source = the app tier's security group ID) rather than CIDR blocks, so the rule expresses intent and cannot accidentally widen when the VPC grows.

The second pattern is the transit gateway that quietly becomes a flat network. Transit Gateway defaults make life easy: a single default association route table and default propagation mean every attached VPC learns routes to every other attached VPC. That is convenient on day one and catastrophic as a security posture, because your carefully separated production, development, and shared-services VPCs are now fully routable to each other. Real segmentation with Transit Gateway requires multiple route tables, deliberate associations, and propagation turned off where you do not want reachability, plus blackhole routes for pairs that must never talk.

Third, teams segment the network and forget the data plane. A private subnet with no internet route still reaches S3, DynamoDB, and every other AWS API if traffic goes out through a NAT gateway, and an attacker with instance credentials can exfiltrate to any bucket in any account. Closing that path means VPC endpoints with endpoint policies, and ideally the aws:PrincipalOrgID condition so the endpoint only permits access to resources in your own organization.

Checking Transit Gateway Route Tables From the CLI

To see how many route tables a transit gateway actually has, and which are the defaults:

aws ec2 describe-transit-gateway-route-tables --filters Name=transit-gateway-id,Values=tgw-0123456789abcdef0

The output lists each TransitGatewayRouteTableId with its State, plus two booleans that tell you the whole story: DefaultAssociationRouteTable and DefaultPropagationRouteTable. Valid filter names include transit-gateway-id, transit-gateway-route-table-id, state, default-association-route-table, and default-propagation-route-table. If your transit gateway has exactly one route table and both booleans are true, you have a flat network, whatever the architecture diagram says. Follow up with aws ec2 search-transit-gateway-routes to see the actual routes in a given table.

Frequently Asked Questions

Is one big VPC with many subnets enough segmentation?

It can be, for a single workload with clearly separated tiers, provided the security groups reference each other rather than CIDR ranges and the route tables genuinely differ. It stops being enough as soon as workloads with different sensitivity or different teams share the VPC, because everything in one VPC shares one IAM blast radius and one set of route tables.

Where does zero trust fit in?

Zero trust says network position should not by itself grant access. That does not mean segmentation is obsolete; it means segmentation is a containment control rather than an authentication control. You still segment to limit what a compromised workload can reach, and you still authenticate and authorize every request on top of that.

How do I stop workloads from talking to each other without breaking shared services?

Put shared services (DNS, logging, artifact repositories) behind PrivateLink endpoint services or in a dedicated shared services VPC reachable through a specific transit gateway route table, and keep the workload VPCs isolated from each other. That way each spoke reaches the hub without reaching its peers, which is the segmentation property you usually want.