VPCs, Subnets, and Security Groups: AWS Networking for SAA-C03

VPC networking is the single topic that separates candidates who pass the AWS Certified Solutions Architect - Associate (SAA-C03) on the first try from those who walk out unsure. It is not that the individual pieces are hard; it is that a Virtual Private Cloud is built from six or seven components that all sound vaguely similar — subnets, route tables, internet gateways, NAT gateways, security groups, network ACLs — and the exam loves to describe a broken network and ask you which one is at fault. If you only half-understand how they connect, every one of those questions becomes a coin flip. This article walks through the whole picture, then works one concrete example end to end.

The VPC is your private slice of the network

Start with the container. A VPC is a logically isolated virtual network you define inside an AWS region, and you give it an address range using CIDR notation, such as 10.0.0.0/16 — a /16 that yields roughly 65,000 private IP addresses to carve up however you like. Nothing inside a VPC can reach the public internet by default; it is genuinely private until you deliberately open a path. Getting comfortable reading CIDR blocks is foundational for the AWS Certified Solutions Architect - Associate, because almost every networking question assumes you can look at 10.0.1.0/24 and know it is a 256-address slice of the larger VPC.

Inside the VPC you create subnets. A subnet is a smaller CIDR range that lives entirely within one Availability Zone, and it never spans two zones — which is exactly why, when you design for high availability, you place subnets in different AZs and spread instances across them. The words "public" and "private" get attached to subnets constantly, but a subnet is not public or private because of a checkbox — it is public because of how its route table is configured. That distinction is the hinge the next section turns on.

Route tables, gateways, and what actually makes a subnet "public"

Every subnet is associated with exactly one route table — the set of signposts telling traffic where to go based on its destination. A route like 10.0.0.0/16 → local is created automatically and lets everything inside the VPC talk to everything else. What makes a subnet public is one additional route: a path to an internet gateway (IGW).

An internet gateway is a component you attach to the VPC itself — one per VPC — that provides the door to the public internet. A subnet becomes public the moment its route table contains a route for 0.0.0.0/0 (meaning "everywhere else") pointing at that IGW, and its instances have public IP addresses. Remove that route and the identical subnet is now private. This is why "add an internet gateway" is almost never the complete answer on the exam; you attach the IGW and edit the route table, and forgetting the second step is a classic distractor.

Private subnets create a puzzle: an instance with no route to the internet still often needs to reach out — to download patches or call an external API — without accepting inbound connections from strangers. That is the job of a NAT gateway. You place it in a public subnet, and the private subnet's route table sends 0.0.0.0/0 to the NAT gateway instead of to an IGW. Outbound traffic flows through NAT, out the internet gateway, and back; unsolicited inbound traffic has no way in. The analogy that sticks: the internet gateway is your building's front door, while the NAT gateway is the mailroom that sends letters out and takes the replies, but never lets a stranger walk to your desk.

Security groups versus network ACLs: stateful versus stateless

Once traffic can reach a subnet, two more layers decide whether it is allowed through, and confusing them is probably the most common mistake on the SAA-C03 exam. A security group acts as a firewall around an individual resource, most often an EC2 instance's network interface. A network ACL (NACL) is a firewall around the whole subnet. Both filter traffic, but they behave in fundamentally different ways.

The key word for security groups is stateful. If you allow an inbound request, the response is automatically allowed back out regardless of your outbound rules — the security group remembers the connection. Security groups also only have allow rules; you cannot write an explicit deny, and anything you have not permitted is denied by omission.

Network ACLs are stateless. They remember nothing. If you allow inbound traffic on port 443, you must separately allow the outbound response, and because responses use high-numbered ephemeral ports (roughly 1024–65535), a NACL that forgets that ephemeral range will silently break return traffic even though the inbound rule looks perfect. NACLs also evaluate numbered rules in order and support explicit deny rules, which makes them the right tool for blocking a specific malicious IP — something a security group cannot do at all. Hold two sentences and most questions resolve themselves: security groups are stateful, allow-only, and wrap a resource; NACLs are stateless, allow-and-deny, ordered, and wrap a subnet.

A worked example: a web app that cannot reach its database

Picture the pattern you will see over and over. A web server sits in a public subnet; a database sits in a private subnet in the same VPC. The web server serves users fine, but cannot connect to the database on port 3306. Walk the layers in order, because the exam rewards a systematic checklist.

First, routing: both subnets share the automatic 10.0.0.0/16 → local route, so intra-VPC routing is never the problem — that route always exists. Next, the database's security group: does it allow inbound port 3306 from the web server's security group? Referencing the web tier's security group as the source, rather than an IP range, is the idiomatic AWS answer and a frequent correct option, and because security groups are stateful no matching outbound rule is needed for the reply. Finally, the NACL on the private subnet: since it is stateless, confirm it allows inbound 3306 and outbound on the ephemeral range for the response. Nine times out of ten the fix is the database security group; the ephemeral-port NACL trap is the harder variant that separates strong candidates.

That ordered walk — routing, then security group, then NACL — is exactly the reasoning full-length practice builds into reflex. Recognizing the stateful-versus-stateless distinction under time pressure in a four-line scenario only comes from volume. Working through practice questions for the SAA-C03 and reviewing every miss turns these components from a memorized list into a diagnostic you run automatically, and adaptive practice keeps surfacing networking scenarios while your VPC reasoning is still shaky rather than letting you coast on domains you already own.

Knowing when you are ready

Networking is one of several domains on the SAA-C03, but it underpins so many scenario questions that a weak grasp here drags your whole score down. The way to prove you have closed the gap is not to reread the VPC documentation a fourth time — it is to sit a full, timed run and watch how you handle networking scenarios when the clock is moving. Our timed SAA-C03 exam simulations match the real format and pass mark, and readiness tracking shows whether your networking accuracy is genuinely trending upward. When you can walk that routing-then-security-group-then-NACL checklist without hesitating, and your scores clear the bar on fresh questions, you are ready to book the AWS Certified Solutions Architect - Associate with confidence rather than hope.