You have been studying for weeks. Practice tests, whitepapers, YouTube videos at midnight. Then an SAA-C03 scenario drops a VPC question on you – something about a private subnet needing internet access, or whether a NACL rule fires before a Security Group – and everything you thought you understood starts to blur.
That’s not a knowledge gap. That’s a wiring problem. You know the pieces, but how they connect under pressure isn’t fully clicking yet.
This guide is written for exactly that moment. By the end, the relationships between subnets, Security Groups, NACLs, NAT Gateway and VPC Peering will feel obvious – not memorized.
What Your VPC Actually Is (And Why It Matters)
A VPC is your own isolated network inside AWS. You define a CIDR block like 10.0.0.0/16 and everything you build lives within that address space, completely separated from other AWS customers by default.
VPCs are regional. One VPC spans an entire AWS region, but the subnets inside it are tied to specific Availability Zones. That distinction shows up constantly in high-availability questions.
The core promise of a VPC is isolation. Nothing gets in or out unless you deliberately open it up. Every component you’re about to read about exists to manage exactly that.
Subnets and the Public vs. Private Divide
Here’s something that trips people up early: a subnet isn’t inherently public or private. That label comes entirely from its route table.
If the route table points 0.0.0.0/0 to an Internet Gateway, the subnet is public. If there’s no such route, it’s private. That’s the whole distinction.
Public subnets typically hold your load balancers, bastion hosts and NAT Gateways. Private subnets hold databases and backend servers – anything that shouldn’t be directly reachable from outside.
One detail worth remembering: AWS reserves five IP addresses in every subnet – the first four and the last one. A /24 subnet gives you 251 usable addresses, not 256. That comes up in capacity planning questions.
Security Groups vs. NACLs – Getting This Wrong Costs You Marks
Both are firewalls. Both control traffic. But they work completely differently and mixing them up is one of the most common ways candidates drop points.
Security Groups work at the instance level. They’re stateful – allow an inbound request and the return traffic is automatically permitted. No explicit deny rules exist. If something isn’t allowed, it’s blocked.
NACLs work at the subnet level. They’re stateless, meaning you write both inbound and outbound rules explicitly. They support allow and deny rules and they process them in ascending numerical order – rule 100 fires before rule 200, no exceptions.
In practice, Security Groups handle most of your traffic control. NACLs add a broader filter at the subnet boundary when you need one – like blocking an entire untrusted IP range.
NAT Gateway Does One Thing, But Does It Well
Private subnet resources sometimes need to reach the internet. A database pulling a software update. An app server calling an external API. They can’t go through an Internet Gateway because they have no public IPs and aren’t supposed to be reachable from the internet.
NAT Gateway solves this. It sits in a public subnet with an Elastic IP and your private subnet’s route table sends outbound traffic through it. Your private resources can initiate connections outward. Nobody from outside can initiate one inward.
One exam trap worth burning into memory: NAT Gateway is not a security tool. It doesn’t filter or inspect traffic. It’s purely a routing mechanism. Questions sometimes try to position it as a firewall – it isn’t one.
VPC Peering and the Transitive Routing Trap
Sometimes two VPCs need to communicate. Your production VPC might need access to a shared services VPC, or a dev environment might need limited access to production data. VPC Peering creates a direct, private connection between the two over AWS’s internal network – no public internet involved.
Peering works across accounts and across regions. But there’s one rule that catches almost every candidate who hasn’t been specifically warned: VPC Peering is non-transitive.
If VPC A peers with VPC B and VPC B peers with VPC C, VPC A cannot reach VPC C through that chain. You need a direct peering connection between A and C. This shows up in architecture scenarios constantly – someone describes a hub-and-spoke layout and asks why traffic isn’t flowing. The answer is almost always this.
How These Five Pieces Fit a Real Architecture
Picture a standard two-tier web application. The Application Load Balancer sits in a public subnet, accessible from the internet through an Internet Gateway. App servers sit in private subnets, receiving traffic from the ALB but unreachable from outside directly.
When those app servers need to call an external API, outbound traffic routes through the NAT Gateway in the public subnet. Security Groups sit on each resource controlling instance-level access. NACLs provide an additional subnet-level filter if needed.
If a second VPC enters the picture – say, a centralized logging service – you’d establish peering, update route tables in both VPCs and adjust Security Groups to allow traffic from the peered CIDR range. Every piece has one job and they don’t overlap.
Mistakes That Cost Marks on Exam Day
Before exam day, these are the four mistakes worth knowing about.
Confusing stateful and stateless is the biggest one. Security Groups are stateful – response traffic is automatic. NACLs are stateless – you write both directions explicitly.
Assuming NAT Gateway allows inbound connections is another common one. It doesn’t. External access to a resource goes through an Internet Gateway and a public subnet, not NAT Gateway.
Forgetting subnets are AZ-specific matters for resilience questions. High availability needs resources spread across multiple subnets in different AZs.
Treating VPC Peering as transitive will cost you on architecture questions. There’s no chain. A to B to C is never A to C.
Reading about this and applying it under simulated exam pressure are different skills. Testing yourself with scenario-based questions using Updated Amazon SAA-C03 Exam Dumps helps you reason through problems the way the actual exam expects – not just recall definitions.
What This Means for You
VPC is one of those topics where you can read everything correctly and still freeze when the question wraps it in an unfamiliar language. The fix is building the mental model solid enough that the components snap into place automatically.
Subnets are AZ-specific. Security Groups are stateful and instance-level. NACLs are stateless and subnet-level. NAT Gateway is outbound-only routing. VPC Peering is private but never transitive.
Sit with those relationships until they feel obvious – then go test them.