VPC Architecture for Mid-Market SaaS: A 2026 Reference
There is a reference VPC layout that gets used at most mid-market SaaS companies. It is not glamorous; it is correct.
The reference shape
One VPC per environment (dev, staging, prod). Three or four AZs. Public subnets for load balancers; private subnets for compute; isolated subnets for databases.
VPC peering or Transit Gateway for cross-VPC connectivity; PrivateLink for connecting to managed services.
Subnet patterns
- Three-tier: public / private / isolated. The classic; works for 80% of teams.
- Hub-and-spoke: shared services VPC + per-team VPCs via Transit Gateway. For larger orgs.
- Single-tier private: private only; load balancers in private subnet behind ingress controllers. Simplest.
Security boundaries
Security groups as the primary boundary, not network ACLs. NACLs are stateless and confusing; SGs are stateful and intuitive.
Egress restricted by default. Allow specific destinations; deny rest. The hardest discipline; the highest impact.
When to deviate
Deviate when you have multi-tenant workloads needing tenant isolation, or when compliance requires per-customer VPCs. Both are major undertakings; do not start there.
Most teams should start with the three-tier reference and only deviate when forced.
Antipatterns
- Single AZ. One AZ outage and you are down.
- All public subnets. Every instance has internet exposure.
- NACLs as the primary firewall. Use SGs first; NACLs as a backup if at all.
What to do this week
Three moves. (1) Pick the most exposed instance of the pattern in your environment. (2) Apply the lightest fix and measure for one week. (3) Schedule a quarterly review so the discipline does not rot.