Chapter 2 — Networking (VPC)

Day 1 — VPC, Subnets, and Route Tables

1. Concept Primer

A VPC is an isolated network with a CIDR range (e.g. 10.0.0.0/16). Subnets carve that range into smaller blocks, each tied to an Availability Zone. A subnet is "public" only if its route table sends 0.0.0.0/0 traffic to an Internet Gateway — nothing else makes it public.

2. Hands-on Exercise

Build a VPC with one public subnet: create the VPC, subnet, internet gateway, and route table, then wire them together.

3. Exact Commands

floci start && eval $(floci env)

VPC_ID=$(aws ec2 create-vpc --cidr-block 10.0.0.0/16 \
  --query 'Vpc.VpcId' --output text)
echo "VPC: $VPC_ID"

SUBNET_ID=$(aws ec2 create-subnet --vpc-id $VPC_ID \
  --cidr-block 10.0.1.0/24 \
  --query 'Subnet.SubnetId' --output text)
echo "Subnet: $SUBNET_ID"

IGW_ID=$(aws ec2 create-internet-gateway \
  --query 'InternetGateway.InternetGatewayId' --output text)
aws ec2 attach-internet-gateway --vpc-id $VPC_ID --internet-gateway-id $IGW_ID

RT_ID=$(aws ec2 create-route-table --vpc-id $VPC_ID \
  --query 'RouteTable.RouteTableId' --output text)
aws ec2 create-route --route-table-id $RT_ID \
  --destination-cidr-block 0.0.0.0/0 --gateway-id $IGW_ID
aws ec2 associate-route-table --route-table-id $RT_ID --subnet-id $SUBNET_ID

aws ec2 describe-vpcs --vpc-ids $VPC_ID
aws ec2 describe-route-tables --route-table-ids $RT_ID

4. Gotchas

• Floci accepts the full VPC object graph (VPC → subnet → IGW → route table) and stores the relationships correctly, but it doesn't actually enforce network-level packet routing the way a real VPC does — nothing you deploy locally is genuinely isolated by this configuration. Use this to build fluency with the resource model, not to test real traffic isolation.
• Keep the exported VPC_ID/SUBNET_ID/RT_ID shell variables around — most VPC commands are unusable without chaining IDs from prior steps.

5. Self-Check

What single route is the difference between a "public" and a "private" subnet?

Day 2 — Security Groups vs NACLs

1. Concept Primer

Security Groups are stateful (allow the response to a request automatically) and attach to instances/ENIs. Network ACLs are stateless (you must explicitly allow both directions) and attach to subnets. SGs only support "allow" rules; NACLs support both allow and deny.

2. Hands-on Exercise

Create a security group allowing inbound SSH and HTTP, then inspect its rule set.

3. Exact Commands

eval $(floci env)

SG_ID=$(aws ec2 create-security-group \
  --group-name web-sg --description "Web + SSH" --vpc-id $VPC_ID \
  --query 'GroupId' --output text)

aws ec2 authorize-security-group-ingress --group-id $SG_ID \
  --protocol tcp --port 22 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress --group-id $SG_ID \
  --protocol tcp --port 80 --cidr 0.0.0.0/0

aws ec2 describe-security-groups --group-ids $SG_ID

4. Gotchas

• Allowing SSH from 0.0.0.0/0 is a real-world anti-pattern (kept here only because it's a local emulator with no real internet exposure) — don't carry this rule into any real account without restricting the CIDR.
• Security group rule changes are stored and returned by describe-security-groups, but as with VPCs, Floci won't actually block/allow real traffic based on them.

5. Self-Check

If a Security Group is stateful, why do NACLs need explicit outbound rules for return traffic when SGs don't?