VPC networking

Subnets, routing, NAT, security groups.

The VPC (Virtual Private Cloud) is your isolated network in AWS, and its design underpins the security and connectivity of everything you deploy. Subnets, routing, and gateways are the pieces to get right.

Subnets, routing, and gateways

A VPC spans the AZs of one Region, and you carve it into subnets, each tied to a single AZ. A public subnet has a route to an internet gateway, so resources in it can be reached from and reach the internet; a private subnet has no such route, keeping databases and app servers off the public internet. For private instances that need outbound internet (to fetch updates) without being reachable inbound, a NAT gateway provides outbound-only access. The standard pattern is public subnets for load balancers and NAT, private subnets for app and data tiers — internet-facing entry points are few and deliberate.

VPC 10.0.0.0/16  (spans the Region's AZs)
 ├─ public subnet  10.0.1.0/24 (AZ-a)  → route to Internet Gateway
 │    └─ load balancer, NAT gateway
 └─ private subnet 10.0.11.0/24 (AZ-a) → route to NAT (outbound only)
      └─ app servers, database   (no inbound from the internet)
 
# Repeat the pair in AZ-b/AZ-c for high availability.

Security groups, NACLs, and private connectivity

Two firewall layers protect a VPC. Security groups are stateful, instance-level allowlists — you permit inbound/outbound and return traffic flows automatically; reference other security groups by ID so rules follow workloads as they scale. Network ACLs are stateless, subnet-level filters evaluated in order, a coarser second layer. To reach AWS services (S3, DynamoDB) or other VPCs privately without traversing the internet, use VPC endpoints / PrivateLink and VPC peering or Transit Gateway. Keeping data-plane traffic private and workloads in private subnets is the core of a secure network design.