Public and Private Subnet Design

A Virtual Private Cloud (VPC) is your logically isolated network in AWS. Within it you carve out subnets, ranges of IP addresses tied to a single Availability Zone. How you divide a VPC into subnets is the first and most important security decision, because it determines what can reach what.

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 direct internet route. The distinction is defined entirely by the route table, not by any property of the subnet itself.

Only resources that must face the internet belong in public subnets: load balancers, NAT gateways, and bastion alternatives. Keeping this tier minimal shrinks the attack surface. Application servers and databases should never sit in a public subnet where the internet could reach them directly.

Place application servers, databases, and internal services in private subnets. They can still serve traffic via a load balancer in the public subnet and reach the internet for updates through NAT, but they are never directly addressable from outside, drastically reducing exposure.

A common secure layout uses three tiers: a public subnet for load balancers, a private app subnet for compute, and a private data subnet for databases. Traffic flows inward tier by tier, and each tier only accepts connections from the one in front of it.

For resilience, replicate subnets across multiple Availability Zones (AZs). A public and private subnet pair in each AZ lets load balancers and workloads survive the loss of one zone. This is a high-availability practice that also supports secure, redundant designs.

Plan your CIDR blocks so subnets do not overlap and you leave room to grow. Thoughtful, non-overlapping ranges make routing, peering, and security-rule references cleaner. Overlapping CIDRs across VPCs later block peering and complicate connectivity, so plan address space deliberately up front.

Subnet design is a security control because it lets you isolate sensitive workloads. A data subnet with no internet route and no inbound path except from the app tier is structurally protected, even before you add security groups. Architecture, not just rules, enforces this boundary.

Subnets define where network ACLs apply, since NACLs attach at the subnet boundary. Pairing well-designed subnets with subnet-level NACLs and resource-level security groups gives you the layered, defense-in-depth network model that the SCS-C02 exam expects.

The classic mistake is placing a database in a public subnet or giving private instances public IPs out of convenience. Both expose resources that should stay internal. Default to private placement and justify every public-subnet resource explicitly.

Sound subnet design is the backbone of a secure VPC. By separating internet-facing from internal resources and spanning AZs, you build isolation and resilience into the network itself, the foundation that gateways, route tables, and firewalls then build upon.

Apply subnet design reasoning.

A VPC is divided into subnets tied to Availability Zones. A subnet is public only when its route table reaches an internet gateway; otherwise it is private. Keep only load balancers and NAT in public subnets, and place app and data tiers privately. Use a multi-tier pattern across multiple AZs with planned, non-overlapping CIDRs so isolation is built into the architecture itself.