AWS Cloud Architect & Developer · AWS Cloud Architecture
VPC Networking
Virtual Private Cloud design with subnets, route tables, gateways and security controls.
Eight concepts on VPC design for SAA-style questions — public versus private subnets, CIDR usable addresses, security groups versus NACLs, NAT, peering versus transit, endpoints, and a two-tier layout you can draw.
- AWS Cloud Architect & Developer
- Hard level
- 8 concepts
- 5 practice questions
1Public and private subnets
A subnet's "public" or "private" label is not a checkbox on the subnet — it is the route table. A public subnet has a route for 0.0.0.0/0 pointing at an Internet Gateway. A private subnet has no such IGW route; outbound internet, when needed, goes through a NAT Gateway (or similar) instead. Instances also need a public IP or Elastic IP to be reachable from the internet even in a public subnet.
Figure. Public vs private is the default route target: Internet Gateway versus NAT (or none) — not a magical subnet flag.
How the exam tells them apart
- Read the route0.0.0.0/0 → igw-… means public. No IGW default route means private.
- Public IPInternet-facing instances in a public subnet still need a public or Elastic IP.
- Private outboundPrivate subnets that must call the internet route 0.0.0.0/0 to a NAT in a public subnet.
| Trait | Public subnet | Private subnet |
|---|---|---|
| Default route 0.0.0.0/0 | Internet Gateway | NAT (if outbound needed) or none |
| Inbound from internet | Possible with public IP + SG | Not via IGW |
| Typical tier | Load balancers, bastions, NAT | App, data, internal services |
A subnet has no route to an Internet Gateway. Instances there need outbound internet for updates. What do you add?
- Nothing — every subnet can reach the internet by default
- A NAT Gateway in a public subnet and a 0.0.0.0/0 route from the private subnet to that NAT
- A second Internet Gateway attached directly to the private subnet
Private subnets do not take an IGW route. Outbound initiation goes through NAT placed in a public subnet that does have the IGW route.
2CIDR ranges and reserved IPs
A VPC IPv4 CIDR must be between /16 (65,536 addresses) and /28 (16 addresses). Inside each subnet AWS reserves five addresses — network, VPC router, DNS, future use, and broadcast — so usable hosts are total − 5. A /28 therefore gives 11 usable IPs, not 16. Undersizing a subnet is a common exam trap.
Figure. AWS reserves network, router, DNS, future-use and broadcast inside every subnet. A /28 therefore yields 16 − 5 = 11 usable host addresses — not 16.
Usable hosts in a subnet
- Count the blockA /28 has 2^(32−28) = 16 addresses.
- Subtract fiveAWS keeps network, router, DNS, future, broadcast.
- Usable16 − 5 = 11 addresses for ENIs and instances.
Usable IPs in a /28
A subnet is carved as 10.0.1.0/28. How many IP addresses can you assign to instances and ENIs?
- addresses in /28 = 2^{4}16
- AWS reserved5
- usable = 16 − 511
Pro tip. If the question says "/28" and an option is 16, that option forgot the five reserved addresses. Default to 11 usable.
How many usable IPv4 addresses does a /28 subnet provide in a VPC?
- 16
- 14
- 11
16 total minus 5 AWS-reserved leaves 11. Fourteen would be the old "subtract network and broadcast only" habit from generic networking textbooks.
3Security groups versus NACLs
Security groups are stateful allow-only rules attached to ENIs. Return traffic for an allowed connection is automatically permitted. Network ACLs are stateless subnet-level filters that support allow and deny; you must explicitly allow ephemeral return ports (1024–65535) when you allow inbound. Default soft limits include about 60 inbound and 60 outbound rules per security group and up to five security groups per ENI. NACL rules evaluate in ascending rule-number order; the first match wins, and rule 32767 is the implicit deny.
Figure. Security groups are stateful on the ENI; NACLs are stateless subnet filters with explicit deny.
One-way traffic that "should work"
- SymptomOutbound or inbound seems allowed, but replies never arrive.
- Suspect NACLStateless rules need a matching ephemeral-port allow for the return path.
- Contrast SGA security group that allowed the request already allows the response — no second rule for return.
| Trait | Security group | Network ACL |
|---|---|---|
| Level | ENI / instance | Subnet |
| State | Stateful | Stateless |
| Rules | Allow only | Allow and deny |
| Return traffic | Automatic | Must allow ephemeral ports |
| Evaluation | All rules considered | Ascending rule number; first match |
Traffic works one way through a subnet but replies are dropped. The security group looks correct. What is the most likely miss?
- The subnet needs a second Internet Gateway
- A stateless NACL allows the forward path but not ephemeral ports for return traffic
- Security groups cannot allow HTTPS
One-way success with failed replies is the classic stateless NACL fingerprint. Security groups would have allowed the return automatically.
4NAT Gateway
A NAT Gateway lets instances in private subnets start outbound IPv4 to the internet while blocking unsolicited inbound connections. You place it in a public subnet (it needs an IGW path) and point the private subnet's 0.0.0.0/0 route at the NAT. NAT Gateways are AZ-specific: for resilience and to avoid cross-AZ data charges, deploy one per AZ and route each private subnet to the NAT in its own AZ.
Figure. NAT sits in a public subnet; private subnets default-route to it for outbound IPv4 without inbound exposure.
Private subnet cannot reach the internet
- NAT exists?Confirm a NAT Gateway is deployed in a public subnet with an IGW route.
- RoutePrivate subnet route table: 0.0.0.0/0 → that NAT.
- AZ alignmentPrefer a NAT in the same AZ as the private subnet.
Where must a NAT Gateway be deployed for private subnets to reach the internet?
- In the private subnet itself
- In a public subnet that has a route to an Internet Gateway
- In a separate VPC with no IGW
The NAT must itself reach the internet via an IGW, so it lives in a public subnet. Private subnets only need a route to the NAT.
5VPC peering versus Transit Gateway
VPC peering is non-transitive one-to-one connectivity: A↔B and B↔C does not give A↔C. Overlapping CIDRs cannot peer. Transit Gateway is a hub that attaches many VPCs and on-premises networks and routes among them transitively. Choose peering for simple pairs; choose TGW when the mesh of peerings would explode or when on-premises and many VPCs share one hub.
Figure. Solid edges are non-transitive peerings. Dashed edges show the hub alternative that does give A↔C.
Pick the connector
- Two VPCs, no overlapPeering is enough if you only need that pair.
- Many VPCs or on-premTransit Gateway as the hub beats an N² peering mesh.
- Overlapping CIDRsPeering fails — re-IP or expose specific services with PrivateLink instead.
| Trait | VPC peering | Transit Gateway |
|---|---|---|
| Topology | One-to-one | Hub and spoke |
| Transitive routing | No | Yes |
| Overlapping CIDRs | Not allowed | Still a design problem — separate routes carefully |
| Scale cue | Few pairs | Many VPCs / hybrid |
VPCs A–B and B–C are peered. Can A reach C through B by default?
- Yes — peering is always transitive
- No — peering is non-transitive; use Transit Gateway (or another hub) for A↔C
- Only if A and C use the same CIDR
Peering does not chain. Same CIDR would also block peering between a pair; it does not create a transitive path.
6VPC endpoints
VPC endpoints reach AWS services without sending traffic over the public internet. Gateway endpoints exist for S3 and DynamoDB: you associate them with route tables and they add a prefix-list route — no hourly charge for the gateway endpoint itself. Interface endpoints (PrivateLink) place an ENI in your subnet for other services and do incur hourly and data costs. For private high-throughput S3 from a VPC without a NAT, prefer a Gateway VPC Endpoint.
Figure. Endpoints reach AWS APIs without a public IP path — Gateway for S3/DynamoDB, Interface (PrivateLink) for others.
Private S3 without NAT
- Create gateway endpointChoose S3 (or DynamoDB) in the VPC.
- Associate route tablesPrivate subnet route tables get the prefix-list route to S3.
- Optional policyTighten which buckets the endpoint may reach.
| Trait | Gateway endpoint | Interface endpoint |
|---|---|---|
| Services | S3, DynamoDB | Most other AWS services (PrivateLink) |
| How traffic leaves the subnet | Prefix-list route in the route table | ENI in the subnet |
| Typical cost cue | No hourly / data charge for the endpoint | Hourly + data processing |
| Exam "cut NAT cost for S3" answer | Gateway endpoint | Usually not first choice for S3 |
Private-subnet instances must download from S3 without a NAT Gateway to cut cost. What do you configure?
- An Interface endpoint for every bucket URL
- A Gateway VPC Endpoint for S3 associated with the private route tables
- VPC peering to a public subnet in another account
Gateway endpoints for S3 keep traffic on the AWS network and avoid NAT data charges. Interface endpoints are the wrong default for this S3 cost cue.
7Two-tier VPC design
A common exam design: internet-facing web tier in public subnets, app tier in private subnets that may start outbound updates but must not accept inbound internet. Public subnets route 0.0.0.0/0 to an IGW; private subnets route 0.0.0.0/0 to a NAT in a public subnet; security groups allow only the web tier to reach the app tier on the required port. One NAT per AZ keeps failure domains and data-transfer costs sane.
Figure. IGW and NAT both sit with the public tier. Web defaults to the IGW; app defaults to NAT; NAT reaches the IGW; web may talk to app via security groups.
Build the tiers
- Public webSubnets with 0.0.0.0/0 → IGW for load balancers or web instances that must be reachable.
- Private appSubnets with no IGW route; 0.0.0.0/0 → NAT for outbound only.
- SG lockApp SG allows inbound only from the web tier SG on the app port.
In a two-tier design, the app tier must pull patches from the internet but must not accept inbound internet connections. Which pairing is correct?
- App in public subnet with IGW; no NAT
- App in private subnet with NAT for outbound; SG denies internet inbound
- App in private subnet with an IGW route and a public IP
Private + NAT gives outbound initiation without an inbound internet path. An IGW route on the app subnet would make it public.
8Soft limits that show up on exams
Default soft limits include five VPCs per Region and two hundred subnets per VPC. Security groups default to about sixty inbound and sixty outbound rules each, with up to five security groups per ENI. These numbers are soft — they can be raised — but exam stems often treat the defaults as the constraint you must design around when a diagram suddenly needs a sixth VPC in one Region.
Soft quotas that show up on exams — default 5 VPCs per Region, 5 IUWs, security-group and rule counts — live in the limits table. A bar labelled 5 restates the quota without teaching when to request an increase.
When a limit bites
- Count VPCsMore than five in one Region ⇒ request a limit increase or consolidate.
- Count SG rulesRule bloat ⇒ consolidate CIDRs or split roles across fewer, clearer groups.
- Remember soft"Default" is not a hard ceiling in the real account — but it is what the exam expects you to know.
| Resource | Default soft limit |
|---|---|
| VPCs per Region | 5 |
| Subnets per VPC | 200 |
| Inbound rules per security group | 60 |
| Outbound rules per security group | 60 |
| Security groups per ENI | 5 |
An account already has five VPCs in ap-south-1 and the exam asks for another isolated VPC there. What is the issue under default soft limits?
- You cannot create more than five VPCs per Region without a limit increase
- VPCs are global, so the five already count worldwide
- The sixth VPC is free and unlimited by default
The default soft limit is five VPCs per Region. Soft means raisable, but the exam answer names that default.
Notes
- Subnets and Route Tables: A public subnet has a route table entry (0.0.0.0/0) pointing to an Internet Gateway; a private subnet has no such route and reaches the internet only via a NAT Gateway.
- Security Groups vs NACLs: Security Groups are stateful and operate at the ENI level with allow-only rules; Network ACLs are stateless, operate at the subnet level, and support both allow and deny rules.
- NAT Gateway: Lets instances in private subnets initiate outbound IPv4 traffic to the internet while blocking inbound connections; it is deployed in a public subnet and is AZ-specific.
- VPC Peering vs Transit Gateway: Peering is non-transitive one-to-one connectivity; Transit Gateway is a hub that connects many VPCs and on-premises networks transitively.
- VPC Endpoints: Gateway endpoints (S3, DynamoDB) and Interface endpoints (PrivateLink) let resources reach AWS services privately without traversing the internet.
Formulas
- VPC CIDR range: netmask must be between /16 (65,536 addresses) and /28 (16 addresses).
- Reserved IPs per subnet: AWS reserves 5 addresses per subnet, so a /28 gives 11 usable IPs, not 16.
- Security Group limit: default 60 inbound and 60 outbound rules per security group, up to 5 security groups per ENI.
- NACL rules: evaluated in ascending rule-number order; the first match applies and rule 32767 is the implicit deny.
- VPC per Region: default soft limit of 5 VPCs per Region and 200 subnets per VPC.
Exam traps & shortcuts
- If instances in a private subnet cannot reach the internet, first check for a NAT Gateway route and that the NAT sits in a public subnet with an IGW route.
- When a connectivity question says traffic works one way but replies are dropped, suspect a stateless NACL missing the ephemeral port range (1024-65535) for return traffic.
- To connect two VPCs whose CIDRs overlap, peering fails; the exam answer is to re-IP or use PrivateLink to expose specific services.
- For private, high-throughput S3 access from a VPC without a NAT, choose a Gateway VPC Endpoint - it is free and avoids NAT data charges.
Reference tables
Figures the SAA stems reuse. Soft limits can be raised in a real account; exams still expect the defaults.
| Fact | Value |
|---|---|
| VPC CIDR mask range | /16 to /28 |
| Addresses in a /28 | 16 |
| AWS-reserved addresses per subnet | 5 |
| Usable IPs in a /28 | 11 |
| Default VPCs per Region (soft) | 5 |
| Default subnets per VPC (soft) | 200 |
| NACL implicit deny rule number | 32767 |
Recap
Routes decide public versus private; five reserved IPs decide usable size; stateful SG versus stateless NACL decides the one-way-traffic trap; endpoints and TGW are how you avoid NAT meshes and peering spiders.
- Routes
- Public ⇔ 0.0.0.0/0 → IGW; private outbound ⇔ NAT in a public subnet.
- /28 usable
- /28 ⇒ 16 − 5 = 11 usable — never answer 16.
- SG vs NACL
- SG stateful allow-only at ENI; NACL stateless allow/deny at subnet (+ ephemeral return).
- Connect
- Peering non-transitive; TGW is the hub; overlapping CIDRs break peering.
- Endpoints
- S3 without NAT ⇒ Gateway VPC Endpoint.
Practise VPC Networking
Reading is free and needs no account. Practice, mocks and progress live in the app.
- 5 exam-style questions on this topic, with explanations
- A 5-question practice set that ends the chapter
- Timed mocks scored with the real marking scheme
- Readiness tracked per topic, kept on your device