Networking Fundamentals: VPC, Subnets, Security Groups

The plain-language idea

A VPC (Virtual Private Cloud) is an isolated network within AWS — your own private address space that resources (EC2 instances, RDS databases, Lambda functions if configured to join one) live inside. Three layers of control:

• Subnets — a VPC is divided into subnets, each in one specific Availability Zone. A public subnet has a route to an internet gateway (reachable from, and able to reach, the internet); a private subnet doesn't — resources there can't be reached directly from outside the VPC at all.
• Security groups — a virtual firewall attached to individual resources (an EC2 instance, an RDS database), controlling inbound and outbound traffic by port and source. Rules are allow-only — there's no explicit "deny" the way IAM has one; anything not allowed is implicitly blocked.
• Route tables — decide where traffic from a subnet actually goes. A public subnet's route table sends internet-bound traffic to an internet gateway; a private subnet's doesn't have that route at all.

See it in a real thing: a database that's never internet-reachable

The public subnet: has a route to the internet gateway — the load balancer lives here, reachable from outside.

BackNext

A typical setup: a load balancer sits in a public subnet (needs to be internet-reachable to accept user traffic), the application servers sit in a private subnet (only need to be reachable from the load balancer, never directly from the internet), and the RDS database sits in an even more restricted private subnet (only reachable from the application servers, on exactly the database port). Each layer's security group only allows traffic from the layer in front of it — the database's security group allows inbound connections on port 5432 only from the application servers' security group, not from 0.0.0.0/0 (anywhere).

What people usually miss

Watch out

• A resource in a "private" subnet can still reach the internet outward, given a NAT gateway — private only means not directly reachable from the internet, not unable to reach the internet. An application server that needs to call an external API still can, via a NAT gateway routing its outbound traffic, without ever being inbound-reachable itself.
• Security group rules are stateful. If inbound traffic on a port is allowed, the response traffic is automatically allowed back out — you don't need a matching outbound rule for a reply to a request that was already permitted in. (Network ACLs, a separate, subnet-level control, are stateless and do need both directions configured — a real, common source of confusion between the two.)
• 0.0.0.0/0 as a security group source means "any IP address on the internet." Seeing it on a database's inbound rule is close to always wrong — it means the database accepts connection attempts from literally anywhere, not just your own application.
• Multiple Availability Zones exist for real fault isolation, not just redundancy on paper. Placing subnets (and the resources in them) across at least two AZs is what lets an application survive an entire data center having a bad day — a VPC confined to one AZ has a single point of failure baked into its network design, regardless of how resilient any individual service is.

Why this matters in interviews

"How would you make sure this database can't be reached directly from the internet?" tests the same instinct as IAM's least privilege, applied to network topology: naming the specific mechanism — private subnet, no internet gateway route, a security group scoped to only the application tier — is a concrete, checkable answer, versus a vague "we'd secure it properly."