AWS VPC Design: Subnets, NAT, Peering, Transit Gateway, and Security Groups

Introduction

Amazon Virtual Private Cloud (VPC) is the foundational networking layer for AWS infrastructure. Every AWS resource — EC2 instances, RDS databases, Lambda functions, ECS tasks — exists within a VPC. Proper VPC design directly impacts security, performance, scalability, and cost. A poorly designed VPC can cause connectivity issues, security vulnerabilities, and expensive data transfer bills.

This article covers subnet design, NAT strategies, VPC peering, Transit Gateway, security groups, and network ACLs.

VPC and Subnet Design

A VPC spans all Availability Zones (AZs) in a region. The CIDR block must be large enough to accommodate current and future workloads. The standard RFC 1918 ranges are used: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. A /16 CIDR (65,536 addresses) provides sufficient capacity for most organizations.

Subnets are associated with a single AZ and can be public or private. Public subnets have a route table entry pointing to an Internet Gateway. Private subnets route through a NAT Gateway or NAT Instance for outbound internet access. Best practice dictates at least two AZs for high availability, each with public and private subnets.

VPC: 10.0.0.0/16

us-east-1a:

Public: 10.0.1.0/24

Private: 10.0.11.0/24

Data: 10.0.21.0/24

us-east-1b:

Public: 10.0.2.0/24

Private: 10.0.12.0/24

Data: 10.0.22.0/24

NAT Gateways and Internet Connectivity

NAT Gateways enable private subnet resources to access the internet for updates, downloads, and external API calls while preventing unsolicited inbound connections. They are highly available within an AZ and managed by AWS, eliminating the maintenance burden of NAT Instances.

Each NAT Gateway costs approximately $0.045/hour plus data processing charges. For high availability, deploy a NAT Gateway in each AZ used for production workloads. This increases cost but provides resiliency against AZ failures. Alternatively, a single shared NAT Gateway can serve all private subnets via transit gateway attachments.

VPC Peering

VPC Peering connects two VPCs using AWS's internal network, providing low-latency, high-bandwidth connectivity with no bandwidth limits or single point of failure. Peered VPCs can be in the same or different accounts and regions.

Key limitations: transitive peering is not supported (A to B and B to C does not imply A to C), overlapping CIDR blocks cannot be peered, and route tables must be manually configured on both sides. For more than a few VPCs, Transit Gateway is a better solution.

AWS Transit Gateway

Transit Gateway (TGW) is a network transit hub connecting VPCs, VPN connections, and AWS Direct Connect. It supports transitive routing, eliminating the mesh complexity of VPC peering at scale.

Transit Gateway

├── VPC: Production (us-east-1)

├── VPC: Staging (us-east-1)

├── VPC: Shared Services (us-east-1)

├── VPC: Production (eu-west-1)

├── VPN: Branch Office

└── Direct Connect: Data Center

TGW supports route tables per attachment, enabling network segmentation. The default behavior is full mesh, but route table associations limit traffic flow between specific VPCs. TGW Peering connects transit gateways across regions, providing inter-region connectivity at premium data transfer rates.

Security Groups vs. Network ACLs

Security groups act as virtual stateful firewalls at the instance level. They support allow rules only (no explicit deny), evaluate all rules before returning a decision, and track connection state automatically. Security groups are the primary security mechanism for AWS resources.

Network ACLs (NACLs) are stateless firewalls at the subnet level. They support both allow and deny rules, evaluate rules in order (lowest number first), and require explicit rules for return traffic. NACLs provide a secondary defense layer and are useful for blocking specific IP ranges that security groups cannot deny.

Defense in depth combines both: security groups for traffic control between logical application tiers, and NACLs for broad traffic filtering such as blocking known malicious IP ranges at the subnet boundary.

Conclusion

AWS VPC design requires careful planning of CIDR allocation, subnet layout, and connectivity strategies. Transit Gateway simplifies multi-VPC networking at scale, while security groups and NACLs provide layered defense. The most successful VPC designs are those that plan for growth, maintain isolation between environments, and implement connectivity in alignment with organizational security requirements.