Network Segmentation Strategies
Key concepts
Tier-based segmentation
Environment isolation
Micro-segmentation
Transit Gateway for hub-and-spoke
PrivateLink for service access
Overview
Network segmentation is the practice of dividing a network into smaller, isolated segments to limit the blast radius of security incidents, improve performance, and simplify compliance. In AWS, segmentation is achieved through VPCs, subnets, route tables, security groups, and network ACLs working together.
Proper segmentation ensures that a compromise in one part of your infrastructure doesn't automatically grant access to everything else. This is a core principle of defense in depth and is heavily tested on the SAA-C03 exam, particularly in scenarios involving multi-tier applications, compliance requirements, and hybrid architectures.
Segmentation Principle
Segment by function, sensitivity, and trust level. Production should be isolated from development. Databases should be isolated from web servers. Internet-facing resources should be isolated from internal systems.
When a question mentions 'limiting the blast radius,' 'isolating workloads,' or 'compliance requirements for network separation,' think network segmentation using VPCs, subnets, and security controls.
Architecture Diagram
Key Concepts
Segmentation Layers
Network Segmentation Layers
AWS provides multiple layers for implementing network segmentation:
Layer 1: Account-Level Isolation
- Separate AWS accounts for different environments
- Strongest isolation boundary
- Managed via AWS Organizations
Layer 2: VPC-Level Isolation
- Separate VPCs for different applications or tiers
- Logically isolated networks
- Connected via VPC Peering or Transit Gateway when needed
Layer 3: Subnet-Level Isolation
- Public, private, and isolated subnets
- Controlled by route tables
- NACLs provide stateless filtering
Layer 4: Resource-Level Isolation
- Security groups on individual resources
- Stateful, instance-level firewall
- Most granular control
Micro-Segmentation
Micro-Segmentation
Micro-segmentation applies security controls at the workload level, rather than the network perimeter.
AWS Implementation:
- Security groups per application tier
- Security group references (SG-to-SG rules)
- No reliance on IP addresses
- Zero-trust networking principles
Benefits:
- Limits lateral movement
- Workload-specific policies
- Dynamic scaling support
- Simplified compliance auditing
VPC Design Patterns
Single VPC Multi-Tier
Pattern: One VPC with multiple subnet tiers
Structure:
- Public subnets (DMZ)
- Private app subnets
- Private data subnets
- Isolated subnets (no internet)
Use When:
- Simple applications
- Single team ownership
- Lower complexity requirements
- Cost-sensitive environments
Multi-VPC Architecture
Pattern: Separate VPCs for different purposes
Common Separation:
- Production VPC
- Development VPC
- Shared Services VPC
- Security/Inspection VPC
Use When:
- Multiple teams with ownership boundaries
- Compliance requires hard separation
- Different security postures needed
- Large enterprise environments
Segmentation Approaches
| Approach | Isolation Level | Complexity | Use Case |
|---|---|---|---|
| Subnets in same VPC | Logical (route tables) | Low | Small-medium applications |
| Multiple VPCs | Network boundary | Medium | Team/environment isolation |
| Separate Accounts | IAM + Network | High | Strongest isolation, compliance |
| Transit Gateway | Controlled hub-spoke | Medium-High | Centralized networking |
How It Works
Subnet Segmentation Strategy
VPC: 10.0.0.0/16
Tier 1 - Public (Internet-Facing)
├── 10.0.1.0/24 - Public-1a (ALB, NAT Gateway)
├── 10.0.2.0/24 - Public-1b
└── 10.0.3.0/24 - Public-1c
Route: 0.0.0.0/0 → IGW
Tier 2 - Private App (Application Servers)
├── 10.0.10.0/24 - App-1a
├── 10.0.11.0/24 - App-1b
└── 10.0.12.0/24 - App-1c
Route: 0.0.0.0/0 → NAT Gateway
Tier 3 - Private Data (Databases)
├── 10.0.20.0/24 - Data-1a (RDS, ElastiCache)
├── 10.0.21.0/24 - Data-1b
└── 10.0.22.0/24 - Data-1c
Route: Local only (no internet route)
Tier 4 - Isolated (Sensitive Processing)
├── 10.0.30.0/24 - Isolated-1a
├── 10.0.31.0/24 - Isolated-1b
└── 10.0.32.0/24 - Isolated-1c
Route: Local only + VPC EndpointsSecurity Group Micro-Segmentation
ALB-SG:
Inbound: 443 from 0.0.0.0/0
Outbound: All traffic
App-SG:
Inbound: 8080 from ALB-SG (reference, not CIDR!)
Outbound: All traffic
DB-SG:
Inbound: 3306 from App-SG (reference, not CIDR!)
Outbound: None required (stateful)
Cache-SG:
Inbound: 6379 from App-SG
Outbound: None required
Key Point: Traffic can ONLY flow through the chain.
Even if an attacker compromises a web server, they
cannot directly access the database without going
through an app server.Multi-VPC with Transit Gateway
Transit Gateway with Segmented Route Tables:
Production Route Table:
- Production VPC attachment
- Shared Services VPC attachment
- NO route to Development VPC
Development Route Table:
- Development VPC attachment
- Shared Services VPC attachment
- NO route to Production VPC
Shared Services Route Table:
- Shared Services VPC attachment
- Production VPC attachment
- Development VPC attachment
Result: Prod and Dev cannot communicate directly,
but both can access shared services (DNS, logging, etc.)Network Firewall Inspection
Inspection VPC Pattern:
Internet
↓
Internet Gateway
↓
Firewall Subnet (AWS Network Firewall)
↓ (inspected traffic)
Transit Gateway
↓
Workload VPCs
All ingress/egress traffic passes through
the Network Firewall for deep packet inspection,
IDS/IPS, and domain filtering.Use Cases
Use Case 1: PCI-DSS Compliance
Scenario: E-commerce application must isolate cardholder data environment (CDE).
Architecture:
- Separate VPC for CDE (Cardholder Data Environment)
- Dedicated subnets for payment processing
- AWS Network Firewall between CDE and other VPCs
- No direct internet access to CDE
- All access through hardened jump boxes with logging
Use Case 2: Multi-Tenant SaaS Application
Scenario: SaaS provider needs to isolate customer workloads.
Architecture:
- Option A: VPC per customer (strongest isolation)
- Option B: Subnet per customer (medium isolation)
- Option C: Security groups per customer (logical isolation)
- Transit Gateway for centralized management
- Separate encryption keys per tenant
Use Case 3: Development/Production Isolation
Scenario: Prevent development environment from affecting production.
Architecture:
- Separate AWS accounts (strongest)
- Or separate VPCs in same account
- No VPC peering between dev and prod
- Shared services accessed via Transit Gateway with segmented route tables
- Different IAM roles and policies per environment
Use Case 4: Zero-Trust Network Architecture
Scenario: Implement zero-trust principles where no traffic is inherently trusted.
Architecture:
- Micro-segmentation with security groups
- Every resource has explicit allow rules
- No "allow all" rules between tiers
- VPC endpoints for AWS service access
- Private DNS for service discovery
- mTLS between services where possible
Best Practices
Network Segmentation Best Practices
- Segment by Trust Level - Internet-facing, internal, and sensitive data should be in different segments
- Use Security Group References - Reference SGs instead of CIDR blocks for dynamic scaling
- Apply Least Privilege - Only allow necessary traffic between segments
- Document Traffic Flows - Maintain network diagrams showing allowed paths
- Use VPC Flow Logs - Monitor all traffic for compliance and security
- Consider Account Separation - For highest isolation, use separate AWS accounts
- Centralize Egress - Route all internet-bound traffic through inspection points
- Plan CIDR Carefully - Non-overlapping ranges for VPC peering/Transit Gateway
Common Segmentation Patterns
By Environment:
- Production, Staging, Development, Sandbox
By Function:
- Web tier, App tier, Data tier, Management tier
By Compliance:
- PCI scope, HIPAA scope, General workloads
By Team:
- Team A VPC, Team B VPC, Shared Services VPC
Common Exam Scenarios
Exam Scenarios
| Scenario | Solution | Why |
|---|---|---|
| Limit blast radius if web server compromised | Security group chaining (SG references) | Attacker cannot reach DB directly |
| PCI compliance requires isolated CDE | Separate VPC with Network Firewall inspection | Hard network boundary, inspected traffic |
| Dev team should not access production data | Separate accounts or VPCs, segmented TGW routes | No network path between environments |
| Need to inspect all egress traffic | Centralized inspection VPC with Network Firewall | Single chokepoint for all outbound traffic |
| Workloads scale dynamically, need isolation | Security groups with SG references (not CIDRs) | SG references work regardless of IP changes |
| Multiple teams share infrastructure | Multi-VPC with Transit Gateway, route table isolation | Controlled connectivity, team boundaries |
| Sensitive data processing must be air-gapped | Isolated subnets with no internet route, VPC endpoints only | No path to/from internet |
| Third-party vendor needs limited access | Dedicated subnet with restrictive NACLs and SGs | Explicit allow-list for vendor IPs |
Common Pitfalls
Pitfall 1: Flat Network Architecture
Mistake: Putting all resources in the same subnet or using wide-open security groups.
Why it's dangerous:
- Single compromise exposes everything
- Lateral movement is easy
- Compliance violations
- No defense in depth
Correct Approach:
- Tier subnets by function and sensitivity
- Use security group chaining
- Apply least privilege networking
Pitfall 2: Using CIDR Instead of SG References
Mistake: Writing security group rules with IP ranges instead of security group references.
Why it's problematic:
- Rules break when instances change IPs
- Auto Scaling adds instances with new IPs
- Maintenance burden keeping CIDRs updated
Correct Approach:
- Reference source/destination security groups
- Dynamic, scales automatically
- Only use CIDR for external sources
Pitfall 3: VPC Peering Everything
Mistake: Creating full-mesh VPC peering between all VPCs.
Why it's problematic:
- N² connections as VPCs grow
- No centralized control
- Hard to implement security policies
- Management nightmare
Correct Approach:
- Use Transit Gateway for hub-spoke
- Segment with route tables
- Centralize inspection and logging
Pitfall 4: Overlooking Egress Filtering
Mistake: Focusing only on ingress security, ignoring outbound traffic.
Why it's dangerous:
- Compromised instances can exfiltrate data
- Command-and-control traffic goes unchecked
- DNS tunneling possible
Correct Approach:
- Centralized NAT with monitoring
- AWS Network Firewall for egress
- DNS firewall for domain filtering
- VPC endpoints to avoid internet for AWS services
Test Your Knowledge
What is the PRIMARY benefit of using security group references instead of CIDR blocks?
A company needs to ensure their development environment can NEVER communicate with production. What is the STRONGEST isolation approach?
How can you allow Production and Development VPCs to both access Shared Services VPC, but prevent Prod-Dev communication?
What AWS service provides deep packet inspection and IDS/IPS capabilities for VPC traffic?
Related Services
Quick Reference
Segmentation Decision Matrix
When to Use Each Approach
| Requirement | Recommended Approach |
|---|---|
| Team autonomy with shared infrastructure | Multi-VPC + Transit Gateway |
| Strongest possible isolation | Separate AWS accounts |
| Simple application, cost-sensitive | Single VPC, multiple subnets |
| Compliance (PCI, HIPAA, etc.) | Dedicated VPC + Network Firewall |
| Dynamic scaling workloads | Security group references |
| Inspect all traffic | Centralized inspection VPC |
| Hybrid cloud connectivity | Transit Gateway + VPN/DX |
Key Limits
Relevant Service Limits
| Resource | Default Limit | Notes |
|---|---|---|
| VPCs per Region | 5 | Easily increased |
| Subnets per VPC | 200 | Plan CIDR carefully |
| Security groups per VPC | 2,500 | Usually sufficient |
| Rules per security group | 60 in + 60 out | Can request increase |
| Transit Gateway attachments | 5,000 | Per Transit Gateway |
| Route tables per TGW | 20 | For segmentation |
CLI Commands Reference
# Create VPC with CIDR
aws ec2 create-vpc --cidr-block 10.0.0.0/16
# Create Transit Gateway
aws ec2 create-transit-gateway \
--description "Segmented TGW" \
--options DefaultRouteTableAssociation=disable,DefaultRouteTablePropagation=disable
# Create TGW Route Table (for segmentation)
aws ec2 create-transit-gateway-route-table \
--transit-gateway-id tgw-xxx
# Associate VPC attachment with route table
aws ec2 associate-transit-gateway-route-table \
--transit-gateway-route-table-id tgw-rtb-xxx \
--transit-gateway-attachment-id tgw-attach-xxx
# Create security group rule with SG reference
aws ec2 authorize-security-group-ingress \
--group-id sg-database \
--protocol tcp \
--port 3306 \
--source-group sg-app-servers
# Enable VPC Flow Logs
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-xxx \
--traffic-type ALL \
--log-destination-type cloud-watch-logs \
--log-group-name /vpc/flow-logs