AWS Fundamentals
Build a secure network foundation with VPC, subnets, Internet Gateway, NAT Gateway, and Security Groups.
What You'll Build
Every AWS deployment starts with networking. In this module you'll create a production-grade VPC with public and private subnets, gateways, route tables, and security groups — step by step through the AWS Console.
Module 1 — Resource Checklist
0/12 (0%)- ☐VPC
sandbox-vpc - ☐Internet Gateway
sandbox-igw - ☐Public Subnet AZ-a
sandbox-public-1a - ☐Public Subnet AZ-b
sandbox-public-1b - ☐Private Subnet AZ-a
sandbox-private-1a - ☐Private Subnet AZ-b
sandbox-private-1b - ☐NAT Gateway
sandbox-nat - ☐Public Route Table
sandbox-public-rt - ☐Private Route Table
sandbox-private-rt - ☐ALB Security Group
sandbox-alb-sg - ☐EC2 Security Group
sandbox-ec2-sg - ☐RDS Security Group
sandbox-rds-sg
Azure ↔ AWS Mapping
| Azure | AWS | Notes |
|---|---|---|
VNet | VPC | AWS requires explicit Internet Gateway |
Subnet | Subnet | Same concept, route tables per subnet |
NSG | Security Group | AWS SGs are allow-only, no deny rules |
Route Table | Route Table | Identical concept |
(implicit) | Internet Gateway | Azure VNets auto-get internet; AWS needs IGW |
NAT Gateway | NAT Gateway | Same purpose! ~$32/mo in AWS |
Biggest difference: In Azure, a VNet automatically has internet access. In AWS, you must create an Internet Gateway, attach it, and configure route tables.
Step 1: Create the VPC
A VPC (Virtual Private Cloud) is your isolated network in AWS. Think of it as your own private data center with a defined IP range.
CIDR cheat sheet: 10.0.0.0/16 = 65,536 IPs.10.0.1.0/24 = 256 IPs. Each subnet gets a slice of the VPC's CIDR range.
Console: VPC → Your VPCs → Create VPC
| Setting | Value |
|---|---|
| Resources to create | VPC only |
| Name tag | sandbox-vpc |
| IPv4 CIDR block | 10.0.0.0/16 |
| IPv6 CIDR block | No IPv6 |
| Tenancy | Default |
Click Create VPC.
Step 2: Create the Internet Gateway
The Internet Gateway (IGW) allows resources in public subnets to access the internet. Azure VNets get this automatically — AWS requires an explicit gateway that you attach to your VPC.
Console: VPC → Internet gateways → Create internet gateway
| Setting | Value |
|---|---|
| Name tag | sandbox-igw |
Click Create internet gateway.
Then attach it to your VPC:
- Select
sandbox-igw - Click Actions → Attach to VPC
- Select
sandbox-vpc - Click Attach internet gateway
Step 3: Create Subnets (4 total)
Subnets divide your VPC into segments. You need 2 public and 2 private subnets across 2 Availability Zones for high availability.
- Public subnets — For the ALB and NAT Gateway (internet-facing)
- Private subnets — For EC2 instances and RDS (internal only)
Console: VPC → Subnets → Create subnet
Select VPC: sandbox-vpc, then add all 4 subnets:
Subnet 1 — Public AZ-a
| Setting | Value |
|---|---|
| Subnet name | sandbox-public-1a |
| Availability Zone | us-east-1a |
| IPv4 CIDR block | 10.0.1.0/24 |
Subnet 2 — Public AZ-b
| Setting | Value |
|---|---|
| Subnet name | sandbox-public-1b |
| Availability Zone | us-east-1b |
| IPv4 CIDR block | 10.0.2.0/24 |
Subnet 3 — Private AZ-a
| Setting | Value |
|---|---|
| Subnet name | sandbox-private-1a |
| Availability Zone | us-east-1a |
| IPv4 CIDR block | 10.0.10.0/24 |
Subnet 4 — Private AZ-b
| Setting | Value |
|---|---|
| Subnet name | sandbox-private-1b |
| Availability Zone | us-east-1b |
| IPv4 CIDR block | 10.0.11.0/24 |
Tip: Click "Add new subnet" to create all 4 in one go.
Enable auto-assign public IPs (public subnets only)
- Select
sandbox-public-1a - Actions → Edit subnet settings
- Check ✅ Enable auto-assign public IPv4 address
- Click Save
- Repeat for
sandbox-public-1b
In Azure, subnets in a VNet are "private" by default and you use NSGs to control access. In AWS, the route table determines if a subnet is public — a route to the IGW makes it public.
Step 4: Create Route Tables
Route tables control where network traffic goes. You need a public one (routes to IGW) and a private one (routes to NAT Gateway).
Console: VPC → Route tables → Create route table
Public Route Table
| Setting | Value |
|---|---|
| Name | sandbox-public-rt |
| VPC | sandbox-vpc |
Click Create route table.
Add internet route:
- Select
sandbox-public-rt - Tab: Routes → Edit routes → Add route
| Destination | Target |
|---|---|
0.0.0.0/0 | Internet Gateway → sandbox-igw |
Click Save changes.
Associate with public subnets:
- Tab: Subnet associations → Edit subnet associations
- Select both:
sandbox-public-1aandsandbox-public-1b - Click Save associations
Create Private Route Table
| Setting | Value |
|---|---|
| Name | sandbox-private-rt |
| VPC | sandbox-vpc |
Click Create route table.
Associate with private subnets:
- Tab: Subnet associations → Edit subnet associations
- Select:
sandbox-private-1aandsandbox-private-1b - Click Save associations
We'll add the NAT Gateway route in the next step.
Step 5: Create a NAT Gateway
The NAT Gateway lets private subnet resources make outbound internet requests (e.g., downloading updates, API calls) without being directly accessible from the internet. It's a one-way door — traffic goes out only.
Cost alert: NAT Gateways cost ~$0.045/hr (~$32/month). Delete when not actively learning!
Console: VPC → NAT gateways → Create NAT gateway
| Setting | Value |
|---|---|
| Name | sandbox-nat |
| Subnet | sandbox-public-1a (must be public!) |
| Connectivity type | Public |
| Elastic IP | Click Allocate Elastic IP |
Click Create NAT gateway. Wait ~2 minutes for status Available.
Now add NAT route to the private route table:
- Go to VPC → Route tables → select
sandbox-private-rt - Tab: Routes → Edit routes → Add route
| Destination | Target |
|---|---|
0.0.0.0/0 | NAT Gateway → sandbox-nat |
Click Save changes.
Step 6: Create Security Groups
Security Groups are stateful firewalls attached to resources. They are allow-only (no deny rules) and stateful (return traffic is automatically allowed).
You'll create 3 security groups that form a chain:
Internet → [ALB SG: allow 80/443 from anywhere]
→ [EC2 SG: allow 3000 from ALB SG only]
→ [RDS SG: allow 5432 from EC2 SG only]Console: VPC → Security groups → Create security group
1. ALB Security Group
| Setting | Value |
|---|---|
| Name | sandbox-alb-sg |
| Description | Allow HTTP/HTTPS from internet to ALB |
| VPC | sandbox-vpc |
Inbound rules:
| Type | Port | Source |
|---|---|---|
| HTTP | 80 | 0.0.0.0/0 |
| HTTPS | 443 | 0.0.0.0/0 |
2. EC2 Security Group
| Setting | Value |
|---|---|
| Name | sandbox-ec2-sg |
| Description | Allow app traffic from ALB only |
| VPC | sandbox-vpc |
Inbound rules:
| Type | Port | Source |
|---|---|---|
| Custom TCP | 3000 | sandbox-alb-sg (select SG, not IP!) |
3. RDS Security Group
| Setting | Value |
|---|---|
| Name | sandbox-rds-sg |
| Description | Allow PostgreSQL from EC2 only |
| VPC | sandbox-vpc |
Inbound rules:
| Type | Port | Source |
|---|---|---|
| PostgreSQL | 5432 | sandbox-ec2-sg (select SG!) |
Key insight: Each SG references the previous SG as its source — not IP ranges. This creates a security chain that stays valid even when IPs change.
Key Takeaways
- VPCs are isolated networks — always start here before deploying anything
- Use public subnets for ALB and NAT Gateway only
- Keep EC2 and RDS in private subnets — never expose them directly
- Security Groups reference each other to create a defense chain
- Always deploy across at least 2 AZs for high availability
- Delete the NAT Gateway when not actively testing (~$32/month!)