Cargando...
Cargando...
Master AWS virtual networking from CIDR to connectivity — pass every cert question with confidence
Amazon VPC (Virtual Private Cloud) is the foundational networking layer for virtually every AWS workload, giving you logically isolated network space where you control IP addressing, routing, subnets, and connectivity. Understanding VPC fundamentals is non-negotiable across all AWS certifications — from Cloud Practitioner to Advanced Networking Specialty — because nearly every architecture question involves VPC design decisions. Getting subnets, route tables, gateways, and security controls wrong on the exam means failing questions that appear deceptively simple.
Understand how traffic flows INTO, OUT OF, and BETWEEN resources in AWS so you can correctly identify which combination of subnets, route tables, gateways, NACLs, and Security Groups solves a given architectural scenario on the exam.
Public Subnet Pattern
A subnet is 'public' when its route table contains a route to an Internet Gateway (IGW) AND resources inside have public or Elastic IP addresses. The IGW performs NAT for instances with public IPs. The subnet itself has no inherent 'public' property — it's entirely defined by the route table association.
Use for resources that must be directly reachable from the internet: load balancers, bastion hosts, NAT Gateways, and public-facing web servers.
Direct internet exposure increases attack surface. Resources must have a public IP or Elastic IP to actually send/receive internet traffic — a route to an IGW alone is insufficient.
Private Subnet with NAT Gateway Pattern
Private subnets have NO route to an IGW in their route table. Outbound internet access is achieved by routing 0.0.0.0/0 to a NAT Gateway (or NAT Instance) that lives in a PUBLIC subnet. The NAT Gateway has an Elastic IP and performs source NAT so responses return correctly. Inbound connections from the internet are blocked by design.
Use for application servers, databases, Lambda functions, and any resource that needs outbound internet access (e.g., downloading patches, calling external APIs) but must NOT be directly reachable from the internet.
NAT Gateway incurs hourly charges plus per-GB data processing fees. For high-throughput workloads, NAT Gateway costs can be significant. NAT Gateway is managed, highly available within an AZ — deploy one per AZ for full HA.
Isolated Private Subnet Pattern (No Internet Access)
A subnet with no route to an IGW and no route to a NAT Gateway. Resources communicate only within the VPC or via VPC Endpoints/PrivateLink. Often used for databases, data stores, and compliance-sensitive workloads that must never touch the public internet.
Use for RDS databases, ElastiCache clusters, Redshift clusters, and any workload where regulatory requirements prohibit internet connectivity. Pair with VPC Interface Endpoints to reach AWS services privately.
AWS service calls (e.g., S3, DynamoDB, SSM) require VPC Endpoints or they will fail — there is no internet path. Adds endpoint management overhead but maximizes security posture.
VPC Peering Pattern
A one-to-one, non-transitive networking connection between two VPCs (same or different accounts/regions) that routes traffic using private IP addresses. Peered VPCs must have non-overlapping CIDR blocks. Route tables in BOTH VPCs must be updated manually. Peering is NOT transitive — if VPC A peers with B and B peers with C, A cannot reach C through B.
Use when two VPCs need direct, low-latency private communication without a central hub. Ideal for cross-account resource sharing or connecting a shared-services VPC to application VPCs.
Does not scale well beyond a handful of VPCs due to the O(n²) peering mesh required. No transitive routing. For hub-and-spoke or large-scale connectivity, Transit Gateway is the correct answer.
Transit Gateway (TGW) Hub-and-Spoke Pattern
A regional, scalable network transit hub that connects VPCs, VPNs, and Direct Connect attachments through a central router. Supports transitive routing between all attached networks. Each VPC attaches to the TGW and only needs a single route to the TGW for cross-VPC communication.
Use when connecting more than a few VPCs, when you need transitive routing, when you need centralized network inspection (with Gateway Load Balancer), or when connecting on-premises networks to many VPCs simultaneously.
TGW incurs per-attachment and per-GB data processing charges. More complex to configure than VPC Peering. Requires careful route table design on the TGW itself (route domains/isolation).
VPC Endpoint Pattern (Gateway vs. Interface)
Gateway Endpoints (S3 and DynamoDB only) are free, added as route table entries, and keep traffic on the AWS network without needing an ENI. Interface Endpoints (AWS PrivateLink) create ENIs in your subnet with private IPs, support most AWS services and custom services, and incur hourly + data charges. Both eliminate the need for internet, NAT, or IGW to reach AWS services.
Use Gateway Endpoints for S3 and DynamoDB in any private subnet — they're free and simple. Use Interface Endpoints for all other AWS services (SSM, Secrets Manager, KMS, etc.) or to expose your own services privately across accounts.
Gateway Endpoints are region-scoped and cannot be extended outside the VPC (no cross-region, no on-premises access via Gateway Endpoint). Interface Endpoints can be accessed from on-premises via Direct Connect or VPN, making them the choice for hybrid architectures.
Security Layering: Security Groups + NACLs
Security Groups (SGs) are stateful, instance-level firewalls — return traffic is automatically allowed. NACLs are stateless, subnet-level firewalls — you must explicitly allow both inbound AND outbound traffic including ephemeral ports (1024-65535). SGs support only ALLOW rules; NACLs support both ALLOW and DENY rules. NACLs are evaluated in rule number order (lowest first) and stop at the first match.
Use Security Groups as your primary defense layer (stateful, easier to manage). Add NACLs as a secondary layer when you need to explicitly DENY specific IP ranges (e.g., blocking a known malicious IP) — something SGs cannot do since they have no deny rules.
NACLs are stateless, so misconfiguring ephemeral ports is a common real-world and exam trap. SGs are stateful but cannot deny — they only allow. Both layers must be considered when troubleshooting connectivity failures.
STEP 1 — Does traffic need to come FROM the internet TO your resource? → YES:
• Public Subnet (route to IGW + public/EIP on resource) | NO: Private Subnet.
STEP 2 — Does your private resource need to INITIATE outbound internet connections? → YES:
• Private Subnet + NAT Gateway in public subnet | NO: Isolated private subnet.
STEP 3 — Does your private resource need to call AWS services (S3, DynamoDB, SSM, etc.)? → S3 or DynamoDB:
• Gateway VPC Endpoint (free) | All other services: Interface Endpoint (PrivateLink).
STEP 4 — Do you need to connect TWO VPCs privately? → 2-3 VPCs with simple topology:
• VPC Peering | 4+ VPCs, transitive routing, or hybrid: Transit Gateway.
• STEP 5 — Do you need to DENY specific IPs? → Use NACL (SGs cannot deny). Do you need stateful return traffic? → Use Security Group.
STEP 6 — On-premises connectivity? → Low-cost/backup:
• Site-to-Site VPN (over internet, encrypted) | Dedicated, consistent bandwidth: AWS Direct Connect | Both for HA: Direct Connect + VPN as failover.
A subnet is public ONLY if its route table has a route to an Internet Gateway AND the resource has a public/Elastic IP. The IGW alone or the public IP alone is insufficient — BOTH are required for internet connectivity.
VPC Peering is NOT transitive. If A↔B and B↔C, A cannot reach C. The exam loves to present hub-and-spoke scenarios and ask which service enables transitive routing — the answer is Transit Gateway, not VPC Peering.
NACLs are STATELESS — you must allow ephemeral/return ports (1024-65535) explicitly on outbound rules for inbound-initiated connections, and on inbound rules for outbound-initiated connections. Forgetting this causes silent connectivity failures.
Security Groups are STATEFUL — if you allow inbound traffic on port 443, the return traffic is automatically allowed without an explicit outbound rule. This is the opposite of NACL behavior and a frequent source of confusion.
NAT Gateways must be deployed in a PUBLIC subnet and are associated with an Elastic IP. The private subnet's route table must point 0.0.0.0/0 to the NAT Gateway — NOT to the IGW. For high availability, deploy one NAT Gateway per AZ.
Public subnet = route table with IGW route AND resource has public/Elastic IP — BOTH required, neither alone is sufficient.
VPC Peering is non-transitive — for transitive routing across multiple VPCs use Transit Gateway, not chained peering connections.
NACLs are stateless — always add outbound rules for ephemeral ports (1024-65535) or inbound-initiated connections will silently fail.
Gateway VPC Endpoints (S3 and DynamoDB) are FREE and work by adding entries to your route table. Interface Endpoints (PrivateLink) cost money (hourly + data) but support far more services and can be accessed from on-premises via Direct Connect/VPN.
The default VPC has a CIDR of 172.31.0.0/16, comes with a default subnet in each AZ, a default route table with an IGW route, and a default Security Group. Default subnets auto-assign public IPs to instances — a security consideration often tested.
CIDR blocks for VPCs must be between /16 (65,536 IPs) and /28 (16 IPs). AWS reserves 5 IP addresses in every subnet: network address (.0), VPC router (.1), DNS server (.2), reserved for future use (.3), and broadcast (.255). Always subtract 5 from your subnet size when calculating usable hosts.
You CANNOT change the primary CIDR block of a VPC after creation, but you CAN add secondary CIDR blocks. When extending a VPC, add a secondary CIDR — do not try to resize the primary.
Security Groups can reference OTHER Security Groups as sources/destinations (not just IP ranges). This is the preferred pattern for allowing traffic between application tiers — e.g., allow the web-tier SG as a source in the app-tier SG, so any instance added to the web SG automatically gains access.
Common Mistake
A subnet labeled 'public' in the AWS console is automatically internet-accessible.
Correct
The label 'public' is just a name. A subnet is functionally public ONLY if: (1) its associated route table has a 0.0.0.0/0 route pointing to an IGW, AND (2) resources within it have a public or Elastic IP address. Both conditions must be true simultaneously.
Exam questions frequently describe a scenario where an EC2 instance 'can't reach the internet' and give you a subnet with the word 'public' in its name but with one of these two conditions missing. Always check BOTH the route table AND the public IP assignment.
Common Mistake
VPC Peering allows resources in VPC-A to reach VPC-C if VPC-A peers with VPC-B and VPC-B peers with VPC-C (transitive routing).
Correct
VPC Peering is strictly non-transitive. Each VPC pair requires its own peering connection and route table entries. There is no concept of routing through a peer. Transit Gateway is the AWS-managed solution for transitive, hub-and-spoke connectivity.
This is one of the most commonly tested VPC misconceptions. The exam presents multi-VPC connectivity scenarios and includes VPC Peering as a distractor. If the scenario involves more than 2 VPCs needing to communicate transitively, the answer is Transit Gateway.
Common Mistake
Security Groups can be used to BLOCK or DENY traffic from a specific malicious IP address.
Correct
Security Groups support ALLOW rules only — there is no concept of a DENY rule in a Security Group. To explicitly block a specific IP or CIDR, you must use a Network ACL (NACL), which supports both ALLOW and DENY rules evaluated in numeric order.
A common exam scenario: 'A malicious IP is attacking your EC2 instance — what is the MOST effective way to block it immediately?' The answer is NACL, not Security Group. Candidates who don't know SGs lack DENY rules will choose the wrong answer.
Common Mistake
A NAT Gateway in a private subnet enables outbound internet access for resources in that same subnet.
Correct
A NAT Gateway MUST be deployed in a PUBLIC subnet (one with a route to an IGW). The private subnet's route table then points outbound traffic to the NAT Gateway. The NAT Gateway itself uses the IGW for actual internet access. A NAT Gateway in a private subnet has no path to the internet.
This architectural dependency (NAT GW in public subnet, private subnet routes to NAT GW, NAT GW routes through IGW) is frequently tested. Getting the placement wrong means the architecture fails entirely.
Common Mistake
NACLs and Security Groups both automatically allow return traffic for established connections.
Correct
Only Security Groups are stateful and automatically allow return traffic. NACLs are completely stateless — every packet is evaluated independently against the rules. You must explicitly create outbound rules allowing ephemeral ports (1024-65535) for inbound-initiated connections to work correctly.
This stateful vs. stateless distinction is one of the highest-frequency exam topics. A scenario describing 'clients can connect but receive no response' almost always points to a missing NACL outbound rule for ephemeral ports.
Common Mistake
Enabling 'DNS hostnames' and 'DNS resolution' in VPC settings is optional and doesn't affect connectivity.
Correct
For EC2 instances to receive public DNS hostnames, BOTH 'Enable DNS resolution' AND 'Enable DNS hostnames' must be enabled on the VPC. For VPC Interface Endpoints (PrivateLink) to work with private DNS names, 'Enable DNS resolution' must be enabled. Disabling these breaks common connectivity patterns.
Exam scenarios involving 'instances can't resolve their own hostname' or 'PrivateLink endpoint DNS isn't resolving' often trace back to these VPC-level DNS settings being disabled.
PUBLIC = Route + IP (both required): 'You need a ROAD (route to IGW) AND an ADDRESS (public IP) to be found on the internet.'
NACL vs SG: 'NACLs are Naughty — they forget everything (stateless) and can say NO (deny). SGs are Smart — they remember (stateful) but are always Positive (allow only).'
5 Reserved IPs per subnet: 'Never Give Routers Free Beer' → .0 Network, .1 Gateway/Router, .2 Reserved DNS, .3 Future use, .255 Broadcast
VPC Peering non-transitive: 'A friend of a friend is NOT your friend in VPC land — use Transit Gateway to be everyone's friend.'
NAT Gateway placement: 'NAT lives in PUBLIC, serves PRIVATE' — the NAT Gateway always goes in the public subnet to serve private subnet traffic outbound.
Candidates assume that placing an EC2 instance in a 'public subnet' is sufficient for internet access — forgetting that the instance ALSO needs a public or Elastic IP address. The exam presents both missing-IGW-route and missing-public-IP scenarios as answer choices, and candidates who don't know BOTH are required choose the wrong fix.
CertAI Tutor · · 2026-02-22
Key Services
Comparisons
Guides & Patterns