VPCs, Subnets, Security Groups + NACLs

Every cloud workload runs inside a network you define, and that network is itself a set of controls an auditor will ask about. "Is production segmented from corporate?" "Can the database be reached from the internet?" "Who can open a port?" Those are network questions, and they are answered by a handful of primitives that work the same way across AWS, GCP, and Azure under different names. This lesson gives you the model: the VPC as the boundary, subnets as the zones inside it, and the two filtering layers — security groups and NACLs — that decide which traffic actually moves. Once you can read these, "segment the network" stops being a slogan and becomes something you can verify in a config.

The VPC is your private slice of the cloud

A VPC (Virtual Private Cloud — "VNet" in Azure, "VPC network" in GCP) is an isolated virtual network that belongs only to you. You give it an address range in private space (a CIDR block like 10.0.0.0/16, which is ~65,000 addresses), and nothing inside it is reachable from the internet unless you deliberately wire a path out. That default isolation is the foundation: workloads in separate VPCs cannot talk to each other unless you peer them or route between them.

The single most important architectural decision inside a VPC is the public/private split. 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 — resources there reach the internet only outbound, through a NAT gateway, and can never be reached inbound from the internet directly. The rule that falls out of this is simple and it is the one auditors care about: databases and application servers belong in private subnets; only internet-facing entry points (a load balancer, a bastion) belong in public ones.

Subnets are how you segment

Segmentation is the network control behind "limit the blast radius." If everything sits in one flat subnet, a single compromised host can reach everything else. Splitting workloads into subnets by tier (web / app / data) and by trust level (production / staging / corporate) means traffic between zones has to cross a boundary where you can filter and log it.

A common, defensible layout for a three-tier application:

• Public subnet — the load balancer only. It accepts HTTPS from the internet and forwards inward.
• Private app subnet — the application servers. They accept traffic only from the load balancer, never from the internet.
• Private data subnet — the database. It accepts traffic only from the app tier, never from the load balancer and never from the internet.

That "only from the tier directly above" pattern is least privilege expressed as network design. The data tier is two boundaries away from the internet, and each boundary is a place you can prove access is controlled.

Two filtering layers: security groups vs NACLs

Inside the VPC, two mechanisms decide whether a given packet is allowed. They operate at different levels and behave differently, and conflating them is a classic source of both outages and findings.

A security group is a stateful firewall attached to a resource (an instance, a load balancer, a database). Stateful means it tracks connections: if you allow an inbound request, the response is automatically allowed back out — you don't write a return rule. Security groups are allow-only (you list what's permitted; everything else is implicitly denied) and, crucially, they can reference other security groups as the source. "Allow the database SG to accept 5432 from the app SG" is one rule that keeps working as instances scale up and down, because it names the group, not IP addresses.

A NACL (Network ACL — a "stateless" subnet firewall) operates at the subnet boundary. Stateless means it evaluates every packet independently: if you allow inbound traffic you must also explicitly allow the outbound response (typically on ephemeral ports), or the connection hangs. NACLs support explicit deny rules and are evaluated in numbered order, which makes them the right tool for coarse, subnet-wide guardrails — for example, blocking a known-bad IP range across an entire subnet, something a (allow-only) security group cannot express.

The practical guidance most teams follow: do the real access control with security groups (they're stateful, group-aware, and easy to reason about), and use NACLs sparingly for broad subnet-level denies you can't express any other way. When you review an environment, the security groups are where the interesting least-privilege story lives.

What an auditor reads in a VPC

When a SOC 2 or ISO 27001 auditor evaluates network security, they are testing whether access is restricted and segmented, and whether you can prove it. The same handful of artifacts answer it:

1. Segmentation exists — production is in its own VPC/subnets, separated from staging and corporate; sensitive tiers (data) are in private subnets with no internet route.
2. No over-broad ingress — no security group allows 0.0.0.0/0 to sensitive ports (SSH/RDP/database). Management ports are restricted to a bastion, VPN, or a known IP range.
3. Least-privilege flows — tiers accept traffic only from the tier that needs them, ideally expressed as SG-to-SG references rather than wide CIDR ranges.
4. Flow logging — VPC Flow Logs are enabled so traffic is recorded; without them you cannot investigate an incident or prove what the network allowed.

These map to SOC 2 CC6.1 and CC6.6 (logical access, including the boundaries that protect it) and ISO 27001 Annex A 8.20–8.22 (network security, segregation, and controls). The evidence is the network configuration itself plus the config-scanning service's report — AWS Config / Security Hub, GCP Security Command Center, Azure Defender for Cloud — which flags open security groups and missing flow logs fleet-wide.

What to carry forward

A VPC is your isolated network; subnets segment it into public (internet-facing entry points only) and private (everything sensitive) zones; security groups (stateful, allow-only, resource-level, group-aware) do the real least-privilege filtering; and NACLs (stateless, deny-capable, subnet-level) handle coarse guardrails. The breaches come from over-broad ingress — 0.0.0.0/0 to a sensitive port — which is a scannable settings problem with a settings fix, and the evidence is the config report plus VPC flow logs.

In the next lesson you'll put this to work: design the security group rules for a real three-tier application, enforcing least privilege tier to tier and proving the database is unreachable from the internet.