Production 3-Tier Enterprise VPC: Complete Network Isolation
Architecting a secure enterprise VPC topology with public ingress, private application compute subnets, and air-gapped isolated database subnets.
1. Business Problem & Context
An enterprise SaaS company preparing for SOC2 Type II and PCI-DSS certification discovered their application servers and PostgreSQL databases were residing in a single flat VPC subnet. If an attacker exploited a remote code execution vulnerability in the public web app, they gained direct network access to the database credentials and customer records.
2. Requirements & Constraints
- 3-Tier Network Isolation: Strict separation of Ingress, Compute, and Persistence.
- Air-Gapped Database Subnets: Databases must have zero internet gateway or NAT gateway routes.
- Least-Privilege Security Group Chaining: Ingress rules reference security group IDs, never IP addresses.
3. Architecture Overview & Data Flow
Interactive Architecture Diagram (Use controls to zoom & pan)
4. AWS Services Used & Rationales
AWS Services Architecture Rationale
Concrete reasons why these specific services were chosen over alternatives
| Service | Category | Architectural Rationale ("Why this service?") |
|---|---|---|
| Amazon VPC | Networking | Provides isolated private networking across 3 Availability Zones. |
| Security Group Chaining | Security | Database SG allows inbound port 5432 ONLY from App-SG-ID, making IP address changes irrelevant. |
| NAT Gateways (Per AZ) | Networking | Ensures AZ independence so an outage in one AZ NAT gateway does not disrupt compute in others. |
5. Key Design Trade-offs
Architecture Decision & Trade-Off Matrix
Evaluating alternative approaches under real-world constraints
Single NAT Gateway Across All AZs
- + Saves ~$64/month on NAT hourly fees
- − Cross-AZ data transfer fees
- − Single point of failure: if AZ-A dies, compute in AZ-B loses internet
Dedicated NAT Gateway Per AZ (Chosen)
✓ Chosen Design- + Zero cross-AZ single points of failure
- + Full compliance with enterprise high availability SLAs
- − Additional ~$32/mo per AZ baseline
6. Implementation Highlights
IaC Recipe Security Group Chaining Terraform Blueprint
# Database Security Group allowing traffic ONLY from the Application SG
resource "aws_security_group" "database" {
name = "prod-aurora-db-sg"
vpc_id = aws_vpc.main.id
description = "Allow inbound PostgreSQL strictly from App tier"
ingress {
description = "PostgreSQL from App Tier"
from_port = 5432
to_port = 5432
protocol = "tcp"
security_groups = [aws_security_group.app.id] # SG Chaining!
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}7. Results & Key Metrics
- 100% SOC2 Compliance achieved on initial audit round.
- Zero Inbound Exploitation Surface for database tier.
8. Key Architectural Takeaways
Security Rule: Never write CIDR IP blocks (e.g.
10.0.10.0/24) in internal application and database Security Groups. Always chain Security Group IDs to create immutable access control.
