SynfraCore
Synfracore
Start Learning
Navigation

Academies

Platform

RoadmapsLabsCertificationsInterviewPYQsAI AssistantCareer
Start Learning Free Learning Roadmaps

VPC β€” Overview

What it is, why it matters, architecture and key concepts

πŸ“„
Last updated Aug 2026
Expert Content

AWS VPC β€” Your Private Network in the Cloud

Before you start: basic AWS familiarity (Regions, AZs β€” see the AWS Core Services Overview) is assumed. No prior networking experience is required, though basic IP-addressing concepts help.

A VPC (Virtual Private Cloud) is your own isolated network inside AWS. When you launch EC2 instances, RDS databases, or Lambda functions β€” they all live inside a VPC. You control the IP ranges, subnets, routing, and firewalls.

:::tip Analogy: A VPC is a gated business park you lease

Think of AWS as one enormous shared city, and your VPC as a gated business park you've leased inside it β€” nobody else's traffic can wander in unless you build a gate for them. Subnets are the individual buildings inside your park, each with its own address range, some facing the street (public) and some tucked in the back with no street entrance (private). The Internet Gateway is the park's main street entrance β€” only buildings with a paved road to it (a route table entry) can be reached from outside. A NAT Gateway is like a delivery desk in the front building: back-office buildings can send requests out through it, but strangers on the street can't use it to walk in. Security Groups are the individual lock on each building's door (instance-level, remembers who it let out so it can let the reply back in); NACLs are the security guard at each building's parking lot entrance (subnet-level, checks every car in and out, remembers nothing between checks).

:::

VPC Architecture

Traffic from the internet reaches the VPC through one door β€” the Internet Gateway β€” before it ever touches a subnet:

🌐 Internet
Internet Gateway (IGW)
The only way in from outside
VPC: 10.0.0.0/16
Everything below lives inside here

Inside the VPC β€” 4 subnets across 2 Availability Zones:

Public Subnet (10.0.1.0/24) β€” AZ-1a
NAT Gateway (Elastic IP) + App Load Balancer. Route: 0.0.0.0/0 β†’ IGW
Public Subnet (10.0.2.0/24) β€” AZ-1b
NAT Gateway + App Load Balancer (Multi-AZ). Route: 0.0.0.0/0 β†’ IGW
Private Subnet (10.0.3.0/24) β€” App Tier
EC2/ECS app servers. Route: 0.0.0.0/0 β†’ NAT GW
Private Subnet (10.0.4.0/24) β€” DB Tier
RDS Primary + Standby (Multi-AZ failover). Route: local only β€” no internet!

Public vs Private Subnets

Public SubnetPrivate Subnet

|---|---|---|

**Internet access**Direct via IGWOutbound only via NAT
What lives hereLoad balancers, NAT GatewayApp servers, databases
Public IPAssigned automaticallyNo public IP
SecurityExposed to internetProtected

:::tip Design Rule

Load Balancers β†’ Public subnet (need internet access)

App Servers β†’ Private subnet (only ALB needs to reach them)

Databases β†’ Private subnet with NO internet route

:::

Security Groups vs Network ACLs

Security Group β€” instance level, stateful (response traffic is auto-allowed, nothing to configure for replies):

βœ… Inbound rule
Port 443 from 0.0.0.0/0
βœ… Inbound rule
Port 22 from 10.0.0.0/8
πŸ”„ Stateful
Response traffic auto-allowed
Allow rules only
All rules evaluated together β€” no explicit deny

Network ACL β€” subnet level, stateless (nothing is remembered between checks, so return traffic needs its own explicit rule):

Rule 100
Allow 443 inbound
Rule 200
Deny specific IP inbound
Ephemeral ports
Must also allow 1024-65535 for replies
Allow AND Deny rules
Evaluated in order β€” lowest rule number first

Annotated Example: Quick Setup with AWS CLI

This is the minimum sequence to make one subnet in a new VPC actually reachable from the internet β€” each step exists because the previous one alone isn't enough:

bash
# 1. Create the VPC itself β€” just an empty, isolated /16 address space so far.
#    Nothing inside it can reach the internet yet, even though the VPC now exists.
aws ec2 create-vpc --cidr-block 10.0.0.0/16 \
    --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=prod-vpc}]'

# 2. Carve out one subnet (a /24 slice of the VPC's /16) in a specific AZ.
#    A subnet is still private by default β€” creating it does NOT grant internet access.
aws ec2 create-subnet --vpc-id vpc-xxx \
    --cidr-block 10.0.1.0/24 --availability-zone us-east-1a

# 3. Create an Internet Gateway and attach it to the VPC β€” this is the VPC's
#    only door to the internet. One IGW per VPC. Attaching it still isn't
#    enough on its own: nothing routes traffic to it yet.
aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --vpc-id vpc-xxx --internet-gateway-id igw-xxx

# 4. Add a route so traffic actually gets sent to that door. Without this
#    route, instances in the subnet still have no path out β€” this is the
#    step that turns a subnet from "private" into "public".
aws ec2 create-route --route-table-id rtb-xxx \
    --destination-cidr-block 0.0.0.0/0 --gateway-id igw-xxx

The instance itself still needs a public IP (or an Elastic IP) to be reachable β€” the route only makes the path exist, it doesn't assign the instance an internet-routable address.

:::tip Try It (2 minutes)

In the AWS Console, open VPC β†’ Your VPCs β†’ find the default VPC in your account's default region. Click into it, then open its Route Table. Find the row with destination 0.0.0.0/0 β€” its target should be an igw-... ID. That single row is the entire difference between a public and a private subnet: everything else (security groups, NACLs) filters traffic, but this route table entry is what decides whether traffic can leave to the internet at all.

:::

Share:
Join our Community
Daily tips, job alerts, interview help β€” join engineers learning together
β†’
Up Next
πŸ”€
VPC β€” Fundamentals
Core concepts and commands β€” hands-on from the start
Also Worth Exploring
← Back to all VPC modules
Prerequisites β†’