VPC design: subnets, routing and security groups

A VPC (virtual private cloud) is your own isolated network inside a cloud provider. You choose the address range, create subnets, control routing and decide what can talk to what. Good VPC design is one of the strongest security steps you can take.

Step 1: choose the address range

Pick a private CIDR block, such as 10.0.0.0/16 (about 65,000 addresses).

• Make it big enough to grow, since changing it later is painful.
• Make sure it does not overlap with other VPCs, your office network or your VPN, or you cannot connect them.

Step 2: split into subnets, across zones

A subnet is a slice of the VPC that lives in one availability zone. A common layout, repeated in at least two zones:

• Public subnets: for things that must face the internet, such as load balancers.
• Private (app) subnets: application servers. No direct inbound access from the internet.
• Data subnets: databases and caches. Reachable only from the app subnets.

Example: 10.0.0.0/24 public in zone A, 10.0.1.0/24 public in zone B, 10.0.10.0/24 and 10.0.11.0/24 private app, 10.0.20.0/24 and 10.0.21.0/24 data.

Step 3: routing

Each subnet uses a route table.

• A subnet is "public" because its route table sends internet traffic (0.0.0.0/0) to an internet gateway.
• A "private" subnet has no such route. For outbound access only (updates, calling external APIs), route 0.0.0.0/0 to a NAT gateway that sits in a public subnet. Nothing from the internet can start a connection inward through it.
• Data subnets often have no internet route at all.

NAT gateways cost money and charge for data processed, so watch them. Use VPC endpoints (private links) to reach cloud services such as object storage without going through the internet or NAT.

Step 4: security groups

A security group is a virtual firewall attached to a resource (a server, a database, a load balancer).

• Stateful: if inbound traffic is allowed, the reply is allowed automatically.
• Allow rules only. Everything not allowed is denied.
• Can reference other security groups, not just IP ranges.

The powerful pattern is chaining them:

• Load balancer group: allow 443 from the internet.
• App group: allow 3000 only from the load balancer group.
• Database group: allow 5432 only from the app group.

Now the database cannot be reached from anywhere else, even inside the VPC.

Network ACLs

A network ACL is a stateless firewall at the subnet level, with allow and deny rules. Most setups leave it at the default and rely on security groups. Use it as an extra layer, for example to block a known bad range.

Reaching private servers for administration

• A bastion host in a public subnet, tightly locked down.
• Better: a managed session service or a VPN so servers need no public IP and no open SSH port.
• Databases should never have a public IP in normal designs. If you need to use one from your laptop, use a tunnel.

Mistakes to avoid

• Putting databases in public subnets, or opening 0.0.0.0/0 on database ports. This is a classic cause of data leaks.
• Allowing SSH (22) or RDP (3389) from the whole internet.
• One flat subnet for everything.
• Everything in one availability zone.
• Overlapping CIDR ranges between networks.
• Forgetting to turn on VPC flow logs for troubleshooting and investigations.

Quick checklist

• Private CIDR, no overlaps, room to grow.
• Public, app and data subnets in two or more zones.
• Only load balancers public.
• Security groups chained by reference, least access.
• No public IPs on app and database servers.
• Flow logs on, endpoints for cloud services.

Takeaway: put only the front door in public subnets, keep apps and data in private ones, chain security groups so each tier talks only to the one before it, and plan address ranges so networks can connect later.

---

Networking & Cloud series, Part 2 (cloud fundamentals): 2 of 5. Previous: Cloud basics: IaaS, PaaS, SaaS and the shared responsibility model.