AWS VPC Networking Review: Subnet, Route Table, IGW, NAT, VPN, Direct Connect, Security Group, and NACL

A VPC is a private network space in AWS. EC2 instances run inside subnets, and subnets belong to a VPC.

VPC and Subnet

A VPC is a logically isolated network area. A subnet groups resources based on security or operational needs.

Common split:

• Public Subnet: web servers, load balancers, public-facing resources
• Private Subnet: databases and internal services

Typical inbound path:

Internet -> Internet Gateway -> Network ACL -> Security Group -> EC2

Internet Gateway

An Internet Gateway enables two-way internet communication for a VPC.

For a public EC2 instance to be reachable:

1. The subnet route table points to the IGW.
2. The resource has a public IP.
3. The security group allows inbound traffic.
4. The NACL allows inbound and outbound traffic.

NAT Gateway

NAT Gateway lets private subnet instances access the internet, but prevents the internet from initiating access to those instances.

Typical use: private EC2 instances downloading patches or calling external APIs.

VPN and Direct Connect

Client VPN: secure access for remote workers.

Site-to-Site VPN: encrypted tunnel between on-premises networks and VPC.

Direct Connect: dedicated physical connection with low latency and high bandwidth.

PrivateLink: private access to AWS, third-party, or custom services without public internet.

Transit Gateway

Transit Gateway is a central hub for connecting multiple VPCs and on-premises networks. It is useful for multi-VPC, multi-account, hybrid architectures.

Security Group vs NACL

Security Group is an instance-level firewall.

• Stateful
• Allow rules only
• Controls individual resources
• Return traffic is automatically allowed

Network ACL is a subnet-level firewall.

• Stateless
• Allow and deny rules
• Controls an entire subnet
• Inbound and outbound rules both matter

Memory aid:

• Security Group is the instance guard
• NACL is the subnet border checkpoint

Security groups are used more often. NACLs are useful for coarse subnet boundary control.

Deeper Notes

When reviewing this topic, do not memorize names only. Focus on VPC, subnets, route tables, IGW, NAT, VPN, Direct Connect, security groups, and NACLs. If this stays at the definition level, it becomes hard to explain in interviews or apply in projects. A stronger way to study it is to place it in a concrete scenario: who calls it, where the input comes from, what happens on failure, and whether data or state can be processed twice.

• AWS review should connect services into architecture: entry point, compute, networking, storage, permissions, monitoring, and cost.
• For each service, ask what problem it solves, who operates it, and what the blast radius is when it fails.
• Both exams and real projects care about boundaries: Region vs AZ, managed vs self-managed, stateful vs stateless resources.

In a real project, use it as a decision framework: identify inputs, constraints, failure modes, and observability before choosing a specific tool or pattern. If a solution looks simple, keep asking whether it still works when scale grows, permissions change, recovery matters, and more people collaborate on it.

Practical Checklist

• Identify where this concept sits in the system: development-time constraint, runtime behavior, infrastructure capability, or collaboration workflow.
• Write one minimal working example and one failure example; only knowing the happy path is usually not enough.
• Record common misuses: edge cases, permission assumptions, performance assumptions, sync/async differences, or environment differences.
• Connect the concept to a project experience so that an interview answer can be grounded in real tradeoffs.
• End with one sentence about tradeoff: what it gives up and what it buys.

Self-Check Questions

1. What core problem does this topic solve?
2. What alternatives exist, and what are their costs?
3. Where are the most likely edge cases?
4. How would code, tests, or monitoring prove that it is reliable?

Applied Scenario

A practical way to study this topic is to place it inside a small SaaS deployment: users enter through a domain, CloudFront or a load balancer receives traffic, the app runs on EC2, ECS, or Lambda, databases and caches live in private subnets, logs go to CloudWatch, permissions are controlled by IAM, and static assets are stored in S3. For every AWS service, ask where it sits in this chain: entry, compute, network, storage, security, monitoring, or cost control.

Common Pitfalls:

• Memorizing service names without being able to draw the request path.
• Ignoring network boundaries and exposing databases publicly.
• Not estimating cost or failure blast radius.