🎓 Free • Self-Paced • Hands-On

Systems Architect
Academy

A 7-week guided lecture series that bridges cloud-native architecture to bare-metal homelab infrastructure. Go from AWS VPCs to Proxmox clusters with hands-on labs every week.

Start Week 1 → View Syllabus

📊 Your Progress

0 of 7 weeks completed

W1

W2

W3

W4

W5

W6

W7

📚 Course Syllabus

Click any week to jump into the lecture content.

📡 Week 1

Core Networking Fundamentals

From copper wires to web browsers: MAC vs IP addresses, switches vs routers, ARP protocol, and hands-on CLI labs to inspect your own network stack.

○ 0%

☁️ Week 2

Cloud Foundations & Subnet Math

VPC design, CIDR notation and subnet math, Security Groups vs NACLs, Internet Gateways, and the AWS CLI lab.

○ 0%

⚖️ Week 3

HA, Load Balancing & Compute Scale

ALB vs NLB vs GLB, target groups and health checks, Auto Scaling Groups, and multi-AZ resilience.

○ 0%

🚪 Week 4

Home Gateways, NAT & Isolation

RFC 1918 private IPs, NAT deep dive, home gateway triple-play (NAT+DHCP+DNS), double NAT, and AWS NAT options.

○ 0%

🖥️ Week 5

Bare-Metal Hypervisors & Proxmox

Type 1 vs Type 2 hypervisors, Proxmox VE installation, the Linux Bridge (vmbr0), VMs and LXC containers.

○ 0%

🔀 Week 6

Virtual Routing & VLANs

802.1Q VLAN tagging, OPNsense virtual firewall/router, VLAN-aware bridging, inter-VLAN routing rules.

○ 0%

🌐 Week 7

Edge Traffic, DNS & Capstone

Cloudflare Tunnels, DNS record types, split-horizon DNS, and the full-stack capstone architecture.

○ 0%

🎯 What You'll Learn

This course takes a unique approach by mirroring enterprise cloud patterns onto physical infrastructure. You'll start in the cloud with AWS VPCs, load balancers, and NAT Gateways, then translate those exact concepts to bare-metal hypervisors, OPNsense firewalls, and Cloudflare Tunnels. By the end, you'll have both a cloud VPC and a homelab running production-grade architectures.

Design multi-AZ cloud architectures with fault tolerance

Automate infrastructure deployment with Terraform

Build and manage Proxmox hypervisor clusters

Segment networks with VLANs and virtual firewalls

Expose services securely with Cloudflare Tunnels

📋 Prerequisites

💻

Basic Linux CLI

Comfortable with cd, ls, ssh, and text editors (nano/vim)

☁️

AWS Free Tier Account

Sign up at aws.amazon.com — labs stay within free tier limits

🖥️

A Computer for Homelab

Any x86_64 machine with 16GB+ RAM for Proxmox (Week 5+)

🧠

Curiosity & Persistence

Willingness to troubleshoot and experiment is the most important skill

Week 1

📡 Core Networking Fundamentals

From Copper Wires to Web Browsers: Landing on the Network

Welcome to Week 1! Before we spin up Virtual Private Clouds in Amazon Web Services or build Proxmox clusters on physical hardware, we have to pull back the curtain on what a network actually is. Cloud engineering and homelabbing are just software pretending to be hardware. If you don't know what a physical switch, router, or packet is, configuring them in the cloud will feel like guesswork. This week, we dismantle the mystery of how data moves from Point A to Point B.

🎯 Learning Objectives

• Understand what actually happens when you type a URL and press Enter
• Master the practical 4-layer architectural stack (not the theoretical 7-layer one)
• Distinguish MAC addresses (birth certificate) from IP addresses (mailing address)
• Understand how switches work locally vs routers globally
• Learn how ARP discovers devices on your local network
• Run hands-on CLI commands to inspect your own machine's networking stack

🏗️ The Core Ecosystem: What Happens When You Type a URL?

Imagine you open your browser and type https://google.com. In less than a second, a page appears. What actually happened?

At its simplest, networking is just a high-speed game of telephone between two computers: your Client (the browser) and a Server (a computer sitting in a data center).

To make this happen without chaos, the tech industry relies on a conceptual blueprint called the OSI Model (Open Systems Interconnection). While the textbook model has 7 layers, as a Systems Architect, you only need to master 4 critical layers to troubleshoot 99% of infrastructure problems:

Layer	Name	What It Handles	Analogy
L4	Transport	How data is sent (Reliably vs Fast)	Certified mail receipt vs a postcard
L3	Network	Where data is going globally (IPs)	Mailing address on the envelope
L2	Data Link	Who receives it locally (MACs)	Shouting someone's name inside a room
L1	Physical	The actual medium (Cables, Radio Waves)	The asphalt roads and copper phone lines

🔀 Layer 2 vs. Layer 3: The Local Street vs. The Global Highway

The most common point of confusion for beginners is distinguishing between Layer 2 (Local) and Layer 3 (Global). Let's break down the two distinct identities every machine on a network possesses.

🆔 The MAC Address (Layer 2) — The Birth Certificate

Every network interface card (NIC) — whether the Wi-Fi chip in your phone or the ethernet port on a server — comes with a Media Access Control (MAC) address burned into its physical hardware at the factory.

Format: 00:1A:2B:3C:4D:5E (Hexadecimal)
Rule: It never changes, no matter what network you plug it into. It uniquely identifies that specific piece of hardware globally.

🌐 The IP Address (Layer 3) — The Mailing Address

An Internet Protocol (IP) address is logical, not physical. It is assigned dynamically based on where your computer is currently connected.

Format: 192.168.1.50 (IPv4)
Rule: If you take your laptop from home to a coffee shop, your MAC address stays the same, but your IP changes completely.

🔌 Hardware in Action: Switches vs. Routers

Network Switch (Layer 2)

A switch connects devices together inside the same room or building to form a Local Area Network (LAN). It only cares about MAC addresses. When a packet arrives, the switch checks its internal MAC Address Table and shoots the data down the exact physical copper cable connected to that specific device. It does not understand internet routing.

Router (Layer 3)

A router connects entirely different networks together (like connecting your home LAN to the global Internet WAN). Routers only care about IP addresses and determine the best highway paths to hop across the globe.

🗣️ How Local Devices Talk: Meet ARP

If a switch only understands MAC addresses, but your application only knows the target's IP address, how does your computer know which physical cable to send data across?

It uses ARP (Address Resolution Protocol). Think of ARP as a local roll call.

🏢 The ARP Conversation:

1. Your Laptop shouts to the whole room:
"Hey! Who has the IP address 192.168.1.1? Tell me your MAC address!"
(This is called an ARP Broadcast).

2. The Target Device (Your Gateway Router) replies:
"That's me! My physical MAC address is 00:1A:2B:3C:4D:5E."
(This is a Unicast Response).

3. Your Laptop saves this to its temporary ARP Cache memory so it doesn't have to shout every time it wants to send a packet.

🔬 Hands-On Lab: Interrogating Your Local Network

Let's drop out of theory and look at your actual machine's networking stack using the Command Line Interface. Open your terminal (Linux/macOS) or Command Prompt/PowerShell (Windows).

Task 1 — Find Your Local Identity

# On Linux / macOS
ip addr show   # (Or 'ifconfig' on older systems)

# On Windows (Command Prompt)
ipconfig /all

🔍 Look for: Your active interface (like eth0 or wlan0). Note your IPv4 Address (usually starting with 192.168.X.X or 10.X.X.X) and your "Physical Address" or "ethernet" identifier (the MAC address).

Task 2 — Inspect Your Local ARP Cache

arp -a

🔍 Look for: This displays a structural map of local IP addresses mapped directly to the physical hardware MAC addresses of your home devices or server neighbors. Every device your computer has recently talked to on your local network will appear here.

Task 3 — Trace the Packet Highway

# On Linux / macOS
traceroute google.com

# On Windows
tracert google.com

🔍 Look for: Watch the output build line by line. Hop 1 is your internal private gateway router. Hops 2–5 belong to your local ISP. Subsequent hops trace across global internet exchange points directly into Google's core data center fabric. Each hop is a router making a forwarding decision!

💡 Key Takeaways

✅ Networking is just a high-speed game of telephone between a client and a server. The OSI model is just a blueprint to organize the chaos.
✅ MAC addresses are permanent (birth certificate), IP addresses are temporary (mailing address based on location).
✅ Switches connect devices on the same LAN using MAC addresses. Routers connect different networks using IP addresses.
✅ ARP is how your computer finds the MAC address for a known IP on the local network — it shouts, listens for a reply, and caches the result.
✅ traceroute/tracert shows every router hop your data takes across the internet, from your home router to Google's front door.

← Home Next: Week 2 →

Week 2

☁️ Cloud Foundations & Subnet Math

Why Can't You Just Connect Everything to Everything?

Last week we unpacked how a single packet travels from a laptop to a web server. We learned about MAC addresses, IP addresses, switches, routers, and ARP. Now we take that same mental model and apply it to the cloud — specifically, how AWS builds virtual networks that behave exactly like the physical ones you just learned about. Cloud networking is not magic; it is just software pretending to be a switch, a router, and a cable. This week, you design a Virtual Private Cloud (VPC), master the art of subnet math, and deploy your first AWS resources.

🎯 Learning Objectives

• Create an AWS VPC from scratch — your own private neighborhood in the cloud
• Master CIDR notation and subnet math to divide IP space precisely
• Design public vs private subnets across multiple Availability Zones
• Understand Internet Gateways, Route Tables, and how traffic flows out to the internet
• Distinguish Security Groups (stateful firewall) from NACLs (stateless firewall)
• Launch an EC2 instance into your VPC and verify connectivity with the AWS CLI

🏠 What is a Virtual Private Cloud (VPC)?

Imagine you are the owner of an apartment complex. You own the land (the AWS Region — e.g., us-east-1 in Virginia), and you decide to build a fenced-in neighborhood on it. That fenced-in neighborhood is a VPC. Nothing gets in or out without passing through a gate that you control.

In physical networking, your neighborhood is your Local Area Network (LAN). In AWS, your LAN is a VPC. It is a logically isolated section of the AWS cloud where you launch your resources. Think of it as your own private slice of the internet that runs on AWS's physical cables, but no one else can see inside it.

💡 Key Insight: A VPC is regional — it lives inside one AWS Region (like us-east-1). You cannot stretch a VPC across regions. But you can stretch subnets across Availability Zones (AZs) within a region for high availability.

🌍 VPC Core Components

🗺️

IP CIDR Block

The address range for your entire VPC, e.g. 10.0.0.0/16 (65,536 addresses)

🔀

Subnets

Divisions of your VPC CIDR, each in one AZ. Public or private.

🚪

Internet Gateway

The front door — allows public internet traffic into your VPC

🗺️

Route Tables

Maps that tell traffic where to go — like street signs at every intersection

🧮 CIDR Notation & Subnet Math

CIDR (Classless Inter-Domain Routing) is the way we tell the world how many IP addresses our network needs. Instead of saying "I need 50 IPs," we write 10.0.1.0/26 — a shorthand that means "64 addresses starting at 10.0.1.0."

The /26 part is called the prefix length. It tells us how many bits in the address are fixed (the network portion) versus available for hosts. The bigger the number after the slash, the smaller the network. Think of it like pizza slices: /16 is a large pizza (65,536 addresses), /24 is a personal pizza (256 addresses), and /30 is a single slice (4 addresses).

📐 CIDR Quick Reference

CIDR	Subnet Mask	Total IPs	Usable (AWS)	Use Case
10.0.0.0/16	255.255.0.0	65,536	65,531	Entire VPC
10.0.0.0/24	255.255.255.0	256	251	General subnet
10.0.1.0/26	255.255.255.192	64	59	Small subnet
10.0.0.0/28	255.255.255.240	16	11	Tiny (LB endpoints)
10.0.0.0/30	255.255.255.252	4	2	Point-to-point link

AWS reserves 5 IPs per subnet (network, gateway, 2 AWS reserved, broadcast). A /24 gives you 251 usable addresses, not 254.

⚡ Pro Tip: Use the CIDR Calculator below to practice. Try dividing 10.0.0.0/16 into 4 equal subnets. What CIDR do you use? That is right — 10.0.0.0/18, 10.0.64.0/18, 10.0.128.0/18, 10.0.192.0/18. Each gets 16,384 addresses.

🧮 CIDR Calculator

CIDR Block

Enter a CIDR block and click Calculate.

🛡️ Security Groups vs Network ACLs

AWS gives us two layers of security to control traffic in our VPC. Think of them like building security:

SG

Security Group

The bouncer at the door of each individual apartment. They remember who they let in, and they let that person leave and re-enter freely.

✓ Stateful — return traffic is automatically allowed

✓ Applies to specific resources (EC2, RDS, ELB)

✓ Allow rules only (no explicit deny)

✓ Evaluated as a whole — all rules evaluated before decision

⚠ Cannot block specific IPs — use NACLs for that

NACL

Network ACL

The security guard at the building entrance gate. They check every person coming in and out against a list, and have no memory of who passed before.

✓ Stateless — must allow traffic both ways explicitly

✓ Applies to entire subnets

✓ Supports Allow and Deny rules

✓ Rules evaluated in order (lowest number first)

✓ Can block specific IP addresses (like DDoS mitigation)

💡 Memory Aid: Security Groups = Smart (remembers state) • NACLs = No memory (stateless, needs explicit return rules). In practice, you use SGs 90% of the time and NACLs for broad-stroke subnet filtering.

🖥️ AWS CLI Lab: Build Your First VPC

Now we put theory into practice. You will use the AWS CLI (Command Line Interface) to create a VPC, subnets, an Internet Gateway, and route tables — all from your terminal. This is the foundation of every cloud architecture you will ever build.

Step 1: Create the VPC

~$

aws ec2 create-vpc --cidr-block 10.0.0.0/16 --region us-east-1
# Response includes: VpcId: vpc-0a1b2c3d4e5f6g7h8

Step 2: Create Subnets (one public, one private)

~$

# Replace VpcId with your actual VPC ID
aws ec2 create-subnet --vpc-id vpc-0a1b2c3d4e5f6g7h8   --cidr-block 10.0.1.0/24 --availability-zone us-east-1a
# → SubnetId: subnet-aaa

aws ec2 create-subnet --vpc-id vpc-0a1b2c3d4e5f6g7h8   --cidr-block 10.0.2.0/24 --availability-zone us-east-1b
# → SubnetId: subnet-bbb

Step 3: Attach Internet Gateway

~$

aws ec2 create-internet-gateway --region us-east-1
# → InternetGatewayId: igw-xxx

aws ec2 attach-internet-gateway   --vpc-id vpc-0a1b2c3d4e5f6g7h8   --internet-gateway-id igw-xxx

Step 4: Route Table — Public Subnet → Internet

~$

# Create route table
aws ec2 create-route-table --vpc-id vpc-0a1b2c3d4e5f6g7h8
# → RouteTableId: rtb-xxx

# Add route to internet via IGW
aws ec2 create-route --route-table-id rtb-xxx   --destination-cidr-block 0.0.0.0/0   --gateway-id igw-xxx

# Associate with public subnet
aws ec2 associate-route-table   --route-table-id rtb-xxx   --subnet-id subnet-aaa

💡 What Just Happened? Your public subnet (10.0.1.0/24) now has a path to the internet via the Internet Gateway. Your private subnet (10.0.2.0/24) has no IGW route — it is truly isolated. Any EC2 instance in the private subnet cannot reach the internet (or be reached from it) without a NAT Gateway (which we cover in Week 4).

← Week 1 Next: Week 3 →

Week 3

⚖️ High Availability, Load Balancing & Compute Scale

What Happens When One Server Isn't Enough?

Last week we built a VPC with public and private subnets. We launched an EC2 instance and connected to it via SSH. But what happens when that one instance gets overwhelmed with traffic? What happens if the physical server it runs on fails? This week we learn how to distribute load across multiple servers and build systems that survive failures automatically. Think of it like a restaurant kitchen: if you only have one chef, the restaurant closes when they get sick. But with four chefs in two kitchens, and a smart hostess seating customers at the shortest line, the restaurant keeps running even during dinner rush.

🎯 Learning Objectives

• Understand the three types of load balancers: ALB (smart), NLB (fast), GLB (secure)
• Configure Target Groups and Health Checks for automatic failure detection
• Deploy an Application Load Balancer across multiple Availability Zones
• Set up Auto Scaling Groups with Launch Templates and scaling policies
• Design for Multi-AZ resilience — survive an entire data center failure

🔄 The Load Balancer: A Friendly Receptionist

A load balancer is like a receptionist at a busy office building. If everyone barged into any random office, some rooms would be overcrowded while others sat empty. The receptionist makes sure visitors are spread evenly across available offices.

In technical terms, a load balancer sits in front of your servers and distributes incoming traffic across them. Users connect to the load balancer's DNS name, not to individual servers. This gives us three superpowers: Fault Tolerance (if a server dies, traffic goes elsewhere), Scalability (add more servers behind the LB seamlessly), and Maintenance (take a server offline for updates without downtime).

🏢 Three Types of Receptionists (Load Balancers)

L7

Application LB (ALB)

The smart receptionist who reads your appointment slip. They look at the URL path (/api vs /images) and direct you to the right specialist. Best for web apps and APIs.

✓ Reads HTTP headers & paths

✓ SSL termination

✓ Path-based routing

✓ Sticky sessions

L4

Network LB (NLB)

The express lane receptionist. They don't read your slip — they just look at which door you came through (IP + port) and send you to the right place instantly. Blazing fast, millions of requests per second.

✓ Ultra-low latency

✓ Static IP support

✓ Preserves client IP

✓ TCP/UDP traffic

L7

Gateway LB (GLB)

The security checkpoint receptionist. They don't decide where you go — they just scan you and pass you to a security appliance (firewall, IDS/IPS) for inspection before you proceed.

✓ Transparent appliance chains

✓ GENEVE protocol

✓ Third-party firewall integration

✓ Traffic mirroring

🎯 Target Groups & Health Checks

A load balancer doesn't just magically know which servers are healthy. You define a Target Group — a logical grouping of your servers — and the load balancer pings each server periodically to check if it is alive. This is called a Health Check.

Imagine the receptionist calling each office every 30 seconds. If Dr. Smith's office picks up, they are healthy. If no one answers after 3 tries, they are marked "unhealthy" and no more patients are sent there. When they start answering again, patients are routed back.

🏥 Health Check Configuration

Setting	Typical Value	Explanation
Protocol	HTTP	Check via web request
Path	/health	Endpoint the server exposes for health
Interval	30 seconds	How often to check
Threshold	2 healthy / 10 unhealthy	How many checks pass/fail before status changes
Timeout	5 seconds	How long to wait for a response

📈 Auto Scaling Groups: The Self-Adjusting Server Fleet

A load balancer distributes traffic across servers — but what if all servers are overloaded? You need more servers. Auto Scaling Groups (ASGs) solve this by automatically adding or removing servers based on demand. Think of it like a restaurant that brings in extra chefs when the dinner line gets long, and sends them home after the rush.

📋 Three ASG Configurations

Launch Template

The recipe card: which AMI, instance type, security group, and user data script to use when launching new instances.

Min / Desired / Max

Min=2 (always at least 2 servers), Desired=4 (target number), Max=10 (never exceed this).

Scaling Policies

Rules that trigger scaling: e.g., "Add 2 servers when average CPU > 70% for 5 minutes."

🏗️ Multi-AZ Architecture

🌐 Route 53 DNS → ALB

▼

us-east-1a

Web Server 1

Web Server 2

us-east-1b

Web Server 3

Web Server 4

If AZ us-east-1a fails, the ALB sends all traffic to us-east-1b. Auto Scaling replaces lost capacity automatically.

⚡ Key Insight: Always deploy across at least 2 Availability Zones. An AZ is a physical data center (or group of buildings). If you have 4 servers all in us-east-1a and that AZ has a power outage, your entire app goes down. Spread them across us-east-1a and us-east-1b — if one AZ fails, the other still serves traffic.

← Week 2 Next: Week 4 →

Week 4

🚪 Home Gateways, NAT & Network Isolation

How Does a Private Server Download Updates Without a Public IP?

In Week 2 we built a VPC with public and private subnets. We attached an Internet Gateway to the public subnet so our web servers could be reached from the internet. But what about our private servers — databases, backend APIs, application servers — that should never be directly exposed to the internet? They still need to download security updates and install packages. How? The answer is Network Address Translation (NAT). This week, we uncover how NAT works, the difference between the NAT your home router does and the NAT you need in the cloud, and why the phrase "double NAT" should make you nervous.

🎯 Learning Objectives

• Understand RFC 1918 private IP ranges and why they exist
• Master NAT: how many private devices share one public IP
• Understand the "Home Gateway" triple-play: NAT + DHCP + DNS
• Deploy an AWS NAT Gateway and understand its $97/month cost
• Understand Double NAT and why travel routers are a workaround
• Configure a cheap EC2 NAT instance as an alternative to managed NAT

🏠 RFC 1918 — The Private IP Addresses You Already Use

Look at your own home network. Your laptop, phone, and smart TV all have IP addresses like 192.168.1.101. These are private IP addresses, defined by RFC 1918. They cannot be routed on the public internet — they only work inside your own private network.

📋 RFC 1918 Private IP Ranges

Range	CIDR	Size	Common Use
10.0.0.0 - 10.255.255.255	10.0.0.0/8	16.7M	Enterprise / AWS VPCs
172.16.0.0 - 172.31.255.255	172.16.0.0/12	1M	AWS VPC default range
192.168.0.0 - 192.168.255.255	192.168.0.0/16	65,536	Home networks

These ranges are reserved for private use. If a router on the internet sees a packet destined for 192.168.1.1, it drops it — it has no idea where that network is.

🔄 NAT: How Many Devices Share One Public IP?

Every device in your house has a private IP like 192.168.1.101. When you visit a website, that website doesn't know about 192.168.1.101 — it only sees your public IP address (e.g., 73.45.12.89). How? NAT.

Your home router does NAT. When your laptop sends a packet to google.com, the router rewrites the "from" address (your laptop's private IP) to the router's public IP. It creates a mapping in a table so when the response comes back, it knows to forward it back to the right laptop. Without NAT, you would need a public IP for every device — and we ran out of IPv4 addresses years ago.

🔄 How NAT Works (Step by Step)

Step 1: Laptop wants to visit Google.com

Laptop IP: 192.168.1.101:44321 → Google IP: 142.250.80.46:80

Step 2: Router intercepts and rewrites

Router changes source IP to its own public IP and picks a new port: 73.45.12.89:55001. It saves: 192.168.1.101:44321 ↔ 73.45.12.89:55001 in its NAT table.

Step 3: Google sends response

Response arrives at 73.45.12.89:55001. Router looks up its NAT table, finds the mapping, and forwards to 192.168.1.101:44321.

🏡 The Home Gateway Triple-Play: NAT + DHCP + DNS

Your home router (whether it is a $50 TP-Link or an ISP-provided gateway) actually does three completely different jobs that are bundled into one box. As a systems architect, you need to understand each one separately because in the cloud and in enterprise environments, they are always separate services.

🔄

1. NAT

Converts private IPs to public IPs. Without it, your devices can't reach the internet. In AWS, the NAT Gateway does this for private subnets.

📋

2. DHCP

Dynamic Host Configuration Protocol — automatically assigns IP addresses to devices when they join the network. In AWS, VPC has built-in DHCP.

📖

3. DNS

Translates domain names like google.com into IP addresses. In the cloud, you use Route 53 (AWS) or Cloud DNS (GCP) — separate services from NAT.

💡 Key Insight: Your home router bundles NAT + DHCP + DNS into one box. In the cloud, they are separate services: NAT Gateway, VPC DHCP options, and Route 53. When designing infrastructure, keep them separate — it makes troubleshooting, scaling, and replacing components much easier.

☁️ AWS NAT Gateway vs Cheap NAT Instance

AWS offers a managed NAT Gateway that handles all the NAT complexity for you. It is reliable, scales automatically, and requires zero maintenance. But it costs ~$97/month (including data processing fees). For a lab or startup, that is steep.

The alternative: run a tiny EC2 NAT instance (a cheap t4g.nano) with a script that does NAT. Cost: ~$3-5/month. You trade some reliability for massive savings. In production environments with >$10k/month infrastructure, the managed NAT Gateway is worth it. In your home lab, the NAT instance wins.

💸 AWS Managed NAT Gateway

• ~$97/month (3 AZs, includes data processing)
• Fully managed — AWS handles failover, patching, scaling
• Automatic high availability per AZ
• One per AZ required — multiplies cost across AZs
• Bandwidth scales to 45 Gbps

🚀 EC2 NAT Instance (t4g.nano)

• ~$3-5/month
• Self-managed — you patch, monitor, and fail over
• Single point of failure unless you script failover
• One instance can serve all AZs (with proper routing)
• Limited by instance bandwidth (~500 Mbps for t4g.nano)

🔀 Double NAT & the Travel Router Solution

Sometimes you have NAT happening twice. Picture this: you are in a hotel room. The hotel gives you one public IP for your room via their router (first NAT). You plug in your travel router (second NAT) to share that connection among your laptop, phone, and tablet. Now your traffic goes through two layers of NAT before reaching the internet. This is "Double NAT."

Double NAT causes problems for online gaming, VPN connections, and peer-to-peer apps because the inner router's NAT table is hidden from the outer router. A travel router solves this by acting as a bridge or using VPN passthrough to collapse the two NATs into one.

⚡ Real-World Application: In the cloud, "Double NAT" happens when you have a NAT Gateway in a VPC and then another NAT in a connected VPC (via peering). Traffic from VPC A → VPC B → Internet goes through two NATs, breaking many protocols. The solution: use Transit Gateway or direct VPC peering with proper route tables to avoid dual NAT.

← Week 3 Next: Week 5 →

Week 6

🔀 Virtual Routing & Advanced Layer 2 Segmentation

Splitting One Physical Network into Many Virtual Networks

Last week we built a Proxmox hypervisor with a Linux bridge (vmbr0) connecting all our VMs to the physical network. But there is a problem: all VMs are on the same flat network. That means any VM can talk to any other VM. Your database server and your public web server are on the same layer 2 domain — a security nightmare. This week we solve that with VLANs (Virtual LANs). We will split our single physical network into multiple isolated virtual networks, deploy a virtual firewall (OPNsense) to route between them, and apply the same principles you learned in AWS (Security Groups, route tables, subnet isolation) to your own hardware.

🎯 Learning Objectives

• Understand IEEE 802.1Q VLAN tagging and trunk vs access ports
• Enable VLAN-aware bridging in Proxmox to support multiple VLANs
• Deploy OPNsense as a virtualized firewall/router in Proxmox
• Configure firewall rules for inter-VLAN routing (allow what's needed, deny by default)
• Design a multi-VLAN network topology similar to AWS subnet isolation

📡 VLAN Fundamentals

A VLAN (Virtual LAN) is a way to split a single physical network switch into multiple isolated virtual switches. Devices on different VLANs cannot talk to each other directly — they need a router to pass traffic between them. Think of it like an office building: the physical building is one switch, but different companies on different floors are separate VLANs. Company A on floor 3 cannot walk into Company B's office on floor 5 without passing through the lobby (the router).

🏷️ 802.1Q Tagging

The IEEE 802.1Q standard inserts a 4-byte tag into the Ethernet frame header. This tag contains the VLAN ID (VID), allowing switches to identify which VLAN a frame belongs to.

Dst MAC Src MAC 802.1Q Tag EtherType Payload

↑ The 802.1Q tag contains TPID (0x8100) + PCP + DEI + 12-bit VID (0-4095)

🔌 Port Types

Access Port

Assigned to ONE VLAN. Strips tags on egress. Used for end devices (PCs, printers, servers).

Trunk Port

Carries MULTIPLE VLANs simultaneously. Preserves 802.1Q tags. Used between switches, routers, and hypervisors.

🛡️ OPNsense — The Virtual Firewall/Router

OPNsense is a free, open-source firewall/router based on FreeBSD. It is the open-source equivalent of pfSense but with a more modern web interface and better security defaults. In our architecture, OPNsense will:

Route traffic between our VLANs (inter-VLAN routing)
Provide DHCP to each VLAN subnet
NAT traffic from private VLANs to the internet
Filter traffic with stateful firewall rules
Serve as the default gateway for all VLANs

⚡ Parallel to AWS: OPNsense is your virtual router + firewall + NAT device all in one. In AWS terms, it combines the Internet Gateway, Route Tables, NAT Gateway, Network ACLs, and Security Groups into a single software appliance that you control completely.

1

Download OPNsense ISO

Download the DVD ISO (amd64) from opnsense.org/download. Upload it to Proxmox.

2

Create VM: 2 CPU, 2GB RAM, 16GB disk, 2 NICs

NIC 1 on vmbr0 (WAN — internet facing), NIC 2 on vmbr1 (LAN — internal). Set machine type to q35.

3

Install OPNsense & Assign Interfaces

Boot and login as installer / opnsense. Run guided installer, select ZFS. After reboot, assign WAN to the vmbr0 NIC and LAN to the vmbr1 NIC.

4

Access Web UI

From a device on the LAN, browse to https://192.168.1.1. Login: root / opnsense. Complete setup wizard.

🌉 VLAN-Aware Bridging in Proxmox

To support VLANs, we need to tell the Linux bridge to be "VLAN-aware." This transforms vmbr0 from a simple switch into a trunk port that can carry multiple VLANs simultaneously.

/etc/network/interfaces — VLAN-Aware Configuration

auto lo
iface lo inet loopback

auto enp1s0
iface enp1s0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 10.0.10.2/24
    gateway 10.0.10.1
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes     # ← Enable this
    bridge-vids 2-4094        # ← Allow VLANs 2 through 4094

💡 How It Works: With bridge-vlan-aware yes, vmbr0 becomes a trunk port. Each VM or container's virtual NIC can be assigned a specific VLAN tag (e.g., tag=20). The bridge will tag outgoing frames and strip tags on incoming frames, isolating traffic between VLANs at Layer 2.

🔥 Firewall Rules & Inter-VLAN Routing

By default, OPNsense blocks all traffic between VLANs. This is the "deny by default" security principle. You create explicit allow rules to permit specific traffic between specific VLANs. This is exactly like NACLs in AWS — stateless packet filtering at the subnet boundary.

🏗️ Example: Homelab VLAN Design

VLAN	CIDR	Purpose	Internet Access
VLAN 10	10.0.10.0/24	Management (Proxmox, OPNsense)	Yes (for updates)
VLAN 20	10.0.20.0/24	Servers (Web apps, databases)	Via NAT
VLAN 30	10.0.30.0/24	DMZ (Public-facing apps)	Yes (selected ports)
VLAN 40	10.0.40.0/24	IoT (Smart devices, isolated)	Yes (isolated only)

🔥 Example OPNsense Firewall Rules

Rule	Source	Dest	Port	Action
Admin SSH	VLAN 10	VLAN 20	22/TCP	ALLOW
Web Access	VLAN 10	VLAN 20	80,443/TCP	ALLOW
DMZ Ingress	WAN	VLAN 30	80,443/TCP	ALLOW
IoT Isolation	VLAN 40	Any	Any	DENY
IoT Internet	VLAN 40	WAN	Any	ALLOW

← Week 5 Next: Week 7 →

Week 7

🌐 Edge Traffic, Public DNS & Capstone Integration

Putting It All Together: From Private VPCs to Public-Facing Services

You have built cloud VPCs with subnets and security groups (Week 2). You have scaled them with load balancers and auto scaling (Week 3). You have understood how NAT connects private networks to the internet (Week 4). You have built a bare-metal hypervisor with virtual switching (Week 5). And you have segmented your network with VLANs and a virtual firewall (Week 6). Now we bring everything together. This week, we expose your internal services to the public internet securely using Cloudflare Tunnels, configure DNS so users can reach your services by name, and integrate all six previous weeks into a final capstone architecture.

🎯 Learning Objectives

• Deploy Cloudflare Tunnel (cloudflared) for secure, no-open-port public access
• Understand DNS record types: A, AAAA, CNAME, and when to use each
• Configure split-horizon DNS for internal vs external resolution
• Design and document the full-stack architecture spanning cloud to bare-metal
• Complete the capstone project integrating all 7 weeks of learning

🔒 Cloudflare Tunnels — Expose Services Without Opening Ports

Traditionally, to expose a web service to the internet, you would open a port on your firewall (e.g., port 80 for HTTP, 443 for HTTPS) and forward traffic to your internal server. This is called Port Forwarding. It works, but it is risky: every open port is a potential attack surface.

Cloudflare Tunnel (formerly Argo Tunnel) eliminates the need for open ports entirely. Instead of opening a firewall hole, you install a small daemon called cloudflared on your internal server. This daemon creates an outbound-only encrypted tunnel to Cloudflare's edge network. Users connect to your service through Cloudflare, which proxies the traffic through the tunnel to your server — without any inbound firewall rule needed.

🏗️ Cloudflare Tunnel Architecture

🌍 User's Browser

▼ HTTPS

☁️ Cloudflare Edge
(DDoS protection, CDN, SSL)

▼ Encrypted Tunnel

🚇 cloudflared Tunnel
(Outbound-only connection, no open ports)

▼

🖥️ Internal Service
(Your app on localhost:8080)

Deploy Cloudflare Tunnel

1. Download cloudflared

curl -L https://github.com/cloudflare/cloudflared/releases/latest/... -o cloudflared
sudo install cloudflared /usr/local/bin/

2. Authenticate with Cloudflare

cloudflared tunnel login

3. Create and run a tunnel

cloudflared tunnel create my-tunnel
cloudflared tunnel run --url http://localhost:8080

📖 DNS — The Phonebook of the Internet

DNS (Domain Name System) translates human-readable domain names like app.yourlab.com into IP addresses that computers understand. Think of it as the internet's phonebook.

📋 Key DNS Record Types

Record	Maps	Example	When to Use
A	Domain → IPv4	lab.com → 73.45.12.89	For most web services
AAAA	Domain → IPv6	lab.com → 2001:db8::1	For IPv6-enabled services
CNAME	Domain → Domain	app.lab.com → lab.com	Aliasing subdomains

🔀 Split-Horizon DNS

Here is a common problem: You host app.yourlab.com on a server inside your home network. You set up a Cloudflare Tunnel so the public internet can reach it. The DNS record points to Cloudflare's proxy IP. This works great for users on the internet.

But what about you — sitting inside your home network? When you try to access app.yourlab.com from your laptop on the same LAN, your request goes out to the public internet (hairpin NAT), hits Cloudflare, comes back through the tunnel, and reaches your server. This is inefficient and may break.

Split-horizon DNS solves this. Your internal DNS server returns a private IP (10.0.20.x) for app.yourlab.com when queried from inside your network, while the public DNS returns Cloudflare's proxy IP for external queries. Same domain name, different answers depending on where you ask from.

🏗️ Capstone: Full Architecture Integration

Your final project integrates everything from all 7 weeks into one complete architecture. The diagram below shows how cloud VPCs and on-premise Proxmox infrastructure work together through secure tunnels and DNS.

🗺️ Full Stack Architecture

Cloud + On-Premise Integration via Cloudflare Tunnel

🌍 Users (Internet)

▼ Route 53 DNS

☁️ Cloudflare Edge (DDoS + SSL + Tunnel)

☁️ AWS Cloud

Week 2-3: VPC + ALB + ASG

Public Subnet → ALB → Target Group

Private Subnet → NAT Gateway

🖥️ On-Premise

Week 5-7: Proxmox + VLANs + OPNsense

VLAN 10: Mgmt | VLAN 20: Servers

OPNsense FW | cloudflared Tunnel

Both clouds and on-premise use identical concepts: subnets, routing, firewalls, NAT — just implemented differently.

🎉

Congratulations!

You have completed the Systems Architect Academy. You now have the knowledge to design, deploy, and manage infrastructure spanning cloud-native AWS environments to bare-metal homelabs with enterprise-grade networking. From VPCs and subnet math to OPNsense firewalls and Cloudflare tunnels — you can architect it all.

📜 Next: Certifications

• AWS Solutions Architect Associate
• HashiCorp Terraform Associate
• CompTIA Network+
• Linux Foundation Sysadmin (LFCS)

🚀 Advanced Topics

• Kubernetes (K3s on Proxmox)
• GitOps with ArgoCD/Flux
• Observability (Prometheus + Grafana)
• Multi-site VPN with WireGuard

← Week 6 Back to Home →

AWS SAA-C03 30% of Exam

🛡️ Domain 1: Design Secure Architectures

Identity, Access, and Infrastructure Security — the foundation of every AWS solution.

Security is the #1 priority on the AWS SAA exam and in real-world architecture. Domain 1 is the heaviest-weighted section at 30% of your score. It covers three task statements: securing access to AWS resources (IAM, federation, SCPs), securing workloads and applications (VPC, WAF, Shield), and data security controls (encryption, KMS, backups). Master this domain and you've already cornered nearly a third of the exam.

🎯 Domain 1 Objectives

• 1.1: Design secure access to AWS resources — IAM, federation, SCPs, least privilege
• 1.2: Design secure workloads and applications — VPC security, WAF, Shield, Secrets Manager
• 1.3: Determine appropriate data security controls — encryption at rest/transit, KMS, backups

Task 1.1: Design Secure Access to AWS Resources

Access controls, identity management, federation, and the shared responsibility model.

🔐 The AWS Shared Responsibility Model

This is the single most important concept on the entire exam. AWS secures of the cloud; you secure in the cloud. Memorize the boundary line.

AWS Responsible ("of the Cloud")	Customer Responsible ("in the Cloud")
Physical security of data centers	IAM users, groups, roles, and policies
Hardware, networking, and hypervisors	Customer data encryption at rest and in transit
Managed service security (RDS, S3, DynamoDB)	OS patching (EC2), app config, network ACLs
Global infrastructure (Regions, AZs, Edge)	Security group rules, WAF rules, firewall configs

🧠 Exam Tip: For managed services like RDS, S3, Lambda — AWS handles the underlying infrastructure. For EC2 (IaaS), you're responsible for everything from the OS up. The question will describe a service and ask who's responsible for what.

👤 IAM — Identity and Access Management

IAM is AWS's identity service. It's global (not region-specific) and free. Everything in AWS security starts here.

👤 IAM Users

Represents a person or service that needs access. Has permanent credentials (password, access keys). One user per human.

👥 IAM Groups

A collection of users with shared permissions. Not a real identity — can't log in. Attach policies to groups, not individuals.

🎭 IAM Roles

An identity without permanent credentials. Assumed temporarily by users, apps, or AWS services. Uses STS to issue temporary tokens.

📜 IAM Policies

JSON documents that define permissions. Attached to users, groups, or roles. Two types: managed (AWS or customer) and inline.

📝 IAM Policy Document Structure

JSON

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "192.168.1.0/24"
        }
      }
    }
  ]
}

⚖️ Policy Evaluation Logic

AWS evaluates ALL policies that apply to a request. The default is Deny. An explicit Deny always wins over any Allow. Memorize this order:

Is there an explicit Deny? → Deny
Is there an explicit Allow? → Allow
Neither? → Deny by default (implicit deny)

🧠 Exam Tip: An explicit Deny in an SCP, a permissions boundary, and an identity-based policy all result in Deny. Deny is absolute.

🎯 Principle of Least Privilege

Grant only the minimum permissions needed to perform a task. Start with a Deny-all baseline and add only the specific Actions and Resources required. Use IAM Access Analyzer to identify overly permissive policies.

🔐 Multi-Factor Authentication (MFA)

Required for root user (best practice). Also recommended for all IAM users. Supported devices: virtual MFA (Google Authenticator, Authy), U2F security key (YubiKey), hardware TOTP token, SMS MFA (less secure — avoid).

🔄 Cross-Account Access with Roles & STS

To grant a user in Account A access to Account B: create an IAM Role in Account B with a trust policy that allows Account A's users to assume it. The user calls sts:AssumeRole to get temporary credentials. Never share long-term access keys across accounts.

🏢 AWS IAM Identity Center (fka AWS SSO)

Centralized access management for multiple AWS accounts and business applications. One login → access to all assigned accounts. Integrates with your existing identity source (Active Directory, Okta, Azure AD) via SAML 2.0 or SCIM. Replaces the need to create IAM users in every account.

🏛️ AWS Organizations & Service Control Policies (SCPs)

AWS Organizations lets you consolidate multiple AWS accounts into a single hierarchy with a management account (formerly "master account") and member accounts organized into Organizational Units (OUs).

SCPs are JSON policies applied at the OU or account level that restrict what IAM users and roles can do — even if the account's own IAM policies allow it. SCPs do NOT grant permissions; they set a permission guardrail.

SCP Example — Deny Config Changes Outside Us-East-1

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Deny",
    "Action": "ec2:*",
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": "us-east-1"
      }
    }
  }
}

🧠 Exam Tip: SCPs affect all principals in the account — including the root user of member accounts. They do not affect the management account. SCPs alone cannot grant access — they only set boundaries.

🏗️ AWS Control Tower

Sets up and governs a secure, multi-account AWS environment based on AWS best practices. Automates account provisioning, applies guardrails (preventive SCPs + detective compliance rules), and provides a dashboard for visibility. Built on top of AWS Organizations.

🔗 Federation — Letting External Identities Access AWS

Federation lets users log in with their existing corporate credentials (Active Directory, Okta, Azure AD) instead of creating IAM users. The user authenticates with your IdP, which issues a SAML assertion or OIDC token. AWS STS validates it and returns temporary credentials.

Federation Type	Use Case
SAML 2.0	Enterprise SSO (Microsoft AD FS, Okta, Ping, Shibboleth). Users get an AWS console URL.
OIDC / Web Identity	Mobile/web apps with Google, Facebook, Amazon, or Cognito. Users get temporary AWS creds via Cognito Identity Pools.
AD Connector	Proxy to redirect AD auth requests to your on-premise directory (no cached credentials in AWS).
AWS Managed Microsoft AD	Full AD running in AWS, managed by AWS. Join EC2 instances to domain, use group policies.

🌍 AWS Global Infrastructure

Know these definitions cold:

Region: A geographic area with 2+ AZs. Choose based on latency, compliance, cost, and service availability.
Availability Zone (AZ): One or more discrete data centers with independent power, cooling, and networking. Isolated from other AZ failures.
Edge Location: A CloudFront cache point. NOT an AZ — no compute by default, just caching.
Local Zone: Extends a Region closer to end users for latency-sensitive apps.
Wavelength Zone: Embed AWS compute at 5G network edge (telco providers).

Task 1.2: Design Secure Workloads and Applications

VPC security, network segmentation, application firewalls, and external connectivity.

🌐 VPC Architecture & Security Components

A Virtual Private Cloud (VPC) is your private network in AWS. It's regional and isolated by default. You control IP addressing, subnets, routing, and security.

🌞 Public Subnet

Has a route to an Internet Gateway (IGW) in its route table. Resources get public IPs. For load balancers, bastion hosts, NAT Gateways.

🌚 Private Subnet

No direct route to IGW. Resources use a NAT Gateway (in public subnet) for outbound internet access. For databases, app servers, internal services.

🛡️ Security Groups (SGs) vs Network ACLs (NACLs)

This is a guaranteed exam question. Know every difference:

Feature	Security Group	Network ACL
Level	Instance (ENI) level	Subnet level
State	Stateful — return traffic is auto-allowed	Stateless — return traffic must be explicitly allowed
Rules	Allow rules only (no deny)	Allow and Deny rules (numbered)
Evaluation	All rules evaluated together	Rules evaluated in order (lowest number first)
Default	Deny all inbound / Allow all outbound	Default NACL: Allow all inbound/outbound. Custom: Deny all
Association	Attach to ENI (multiple SGs per ENI)	Attach to subnet (one NACL per subnet)

🧠 Exam Tip: If a question mentions "stateless" or "ephemeral ports" — it's a NACL. If it mentions "stateful" or "return traffic auto-allowed" — it's a Security Group. NACLs are the second line of defense (first line at the subnet level, SGs at the instance level).

🗺️ Route Tables

Each subnet must be associated with one route table. Routes determine where traffic goes. Key routes: 0.0.0.0/0 → IGW (public), 0.0.0.0/0 → NAT (private outbound). The main route table applies to subnets not explicitly associated.

🚪 NAT Gateway vs NAT Instance

NAT Gateway (managed): Highly available, auto-scaled, up to 45 Gbps, no patching. NAT Instance (EC2): You manage it, cheaper for small workloads, can be used as a bastion host. NAT Gateways live in public subnets; private subnets route to them.

🧱 Network Segmentation Strategy

Design your VPC with tiers of subnets: web (public), app (private), database (private, restricted). Use security groups as firewalls between tiers — web SG allows 443 from 0.0.0.0/0, app SG allows only from web SG, db SG allows only from app SG on port 3306/5432. This is the 3-tier architecture pattern.

🛡️ AWS WAF — Web Application Firewall

Protects your web apps from common web exploits. Deployed on CloudFront, ALB, API Gateway, or AppSync. Not on EC2 directly.

• SQL injection — blocks malicious DB queries hidden in form fields
• Cross-site scripting (XSS) — blocks script injection attacks
• IP reputation lists — blocks known bad actors
• Rate-based rules — blocks DDoS by limiting requests per IP
• Geo-match — blocks traffic from specific countries
• Managed rule groups — AWS- or Marketplace-provided rule sets

🧠 Exam Tip: WAF = Layer 7 (application). Shield Advanced = Layer 3/4 DDoS protection. Shield Standard = free, always-on DDoS protection for all AWS customers.

🛡️ AWS Shield

Shield Standard (free): Always-on network/transport layer DDoS protection for all AWS customers. Detects and mitigates common attacks (SYN floods, UDP floods).

Shield Advanced ($3,000/month): Enhanced DDoS protection. Includes DDoS cost protection (AWS refunds scaling costs during an attack), 24/7 DRT (DDoS Response Team), and integration with WAF for L7 attacks.

🔑 AWS Secrets Manager

Securely stores, rotates, and manages database credentials, API keys, and other secrets. Automatic rotation with built-in integration for RDS, Redshift, DocumentDB. More expensive than SSM Parameter Store but has mandatory rotation capability. Exam loves this: "Rotate DB credentials automatically" → Secrets Manager.

👤 Amazon Cognito

Provides user sign-up, sign-in, and access control for web and mobile apps. Two components: User Pools (sign-in, user directory, social sign-in) and Identity Pools (grants temporary AWS credentials to authenticated users). Scales to millions of users.

🔍 Amazon GuardDuty

Threat detection service that continuously monitors for malicious activity. Uses ML, anomaly detection, and threat intelligence feeds. Analyzes CloudTrail logs, VPC Flow Logs, and DNS logs. Generates findings with severity levels. Not a firewall — it detects, doesn't block.

📋 Amazon Macie

Data classification service that uses ML to discover, classify, and protect sensitive data in S3. Automatically identifies PII (names, SSNs, credit card numbers), PHI, and financial data. Generates alerts when sensitive data is exposed or at risk.

🔌 External Connectivity: VPN vs Direct Connect

Feature	AWS Site-to-Site VPN	AWS Direct Connect
Connection	Over the public internet (IPsec encrypted)	Dedicated physical fiber line (private)
Bandwidth	Up to ~1.25 Gbps per tunnel	50 Mbps to 100 Gbps
Latency	Variable (internet)	Consistent, low latency
Security	Encrypted (IPsec)	Private — no encryption by default (add VPN for encryption)
Setup Time	Minutes	Weeks (fiber provisioning)
Cost	Low	High (dedicated line)

🧠 Exam Tip: Need consistent low latency or high bandwidth? → Direct Connect. Need a quick, encrypted connection on a budget? → VPN. Need both encryption AND Direct Connect? → Direct Connect + VPN (IPsec over the private line).

🔗 VPC Endpoints (Gateway)

Allow private subnet access to S3 and DynamoDB without a NAT Gateway or IGW. Uses a gateway endpoint in the route table. Free — no hourly charge. Automatically scales.

🔗 VPC Endpoints (Interface / PrivateLink)

Allow private access to any AWS service (SQS, SNS, Kinesis, API Gateway, etc.) or your own app via PrivateLink. Uses an ENI with a private IP. Paid per hour + data processed. Think: "Private connection to an AWS service without going through the internet."

Task 1.3: Determine Appropriate Data Security Controls

Encryption, key management, backups, data lifecycle, and compliance.

🔑 AWS KMS — Key Management Service

KMS is the central service for encryption key management in AWS. It creates, manages, and rotates encryption keys. Integrated with most AWS services (S3, EBS, RDS, Lambda, etc.).

🔑 AWS Managed Keys

AWS creates and manages them. Free. Named aws/<service> (e.g., aws/s3). Cannot view key material, rotate automatically every 3 years.

📋 Customer Managed Keys (CMK)

You create and manage them. $1/month per key + $0.03 per 10,000 API calls. You control key policies, rotation, and aliases. Automatic rotation (yearly) can be enabled.

🔐 CloudHSM

Dedicated hardware security module — FIPS 140-2 Level 3. You control the keys entirely. No automatic rotation. For regulatory/compliance requirements that demand dedicated HSM hardware. Expensive ($1.40+/hour per HSM).

🧠 Exam Tip: KMS = shared infrastructure (multi-tenant, FIPS 140-2 Level 2). CloudHSM = dedicated hardware (Level 3). If the question says "FIPS 140-2 Level 3" or "dedicated HSM" → CloudHSM. If it says "managed key rotation" or "cost-effective" → KMS.

💾 Encryption at Rest — By Service

Service	Encryption Options
S3	SSE-S3 (AES-256, AWS-managed), SSE-KMS (KMS-managed), SSE-C (customer-provided key), client-side encryption
EBS	EBS encryption (uses KMS — default now enabled per region). Cannot be disabled after creation.
RDS	At-rest encryption via KMS. Encrypts underlying EBS volumes + automated backups. Can only be enabled at creation time.
DynamoDB	Default encryption (AWS-owned key), KMS-managed, or customer-managed CMK. Can be changed anytime.
SQS/SNS	Server-side encryption (SSE) with KMS. Encrypts messages at rest.

📡 Encryption in Transit

Data moving between your users, your VPC, and AWS services must be encrypted using TLS/SSL.

• AWS Certificate Manager (ACM) — provisions, manages, and deploys public/private TLS certificates. Automatic renewal. Integrates with CloudFront, ALB, API Gateway. Cannot use ACM certificates on EC2 directly — must export or use a different tool.
• ELB & CloudFront — terminate TLS at the load balancer / edge, then forward to backend over HTTP (internal).
• Application endpoint — if the app runs on EC2, install the certificate on the instance or use ALB to terminate TLS.

📜 Key Policies & Access Control

KMS keys are controlled by key policies (resource-based) and IAM policies. A key policy can grant access to other AWS accounts (cross-account). Use grant for temporary, fine-grained KMS access without changing the key policy. KMS conditions: kms:ViaService restricts key usage to specific AWS services.

🔄 Key Rotation & Certificate Renewal

KMS automatic rotation: Enabled for CMKs — rotates yearly, keeps previous key material for decryption. Manual rotation: Create a new key, update alias, update apps. ACM automatic renewal: Managed certificates renew automatically. Secrets Manager rotation: Automatically rotates DB credentials on a schedule you define.

💿 Data Backups & Replication

Data protection is a security control. Know these patterns:

• S3 Versioning: Protects against accidental deletion. Combined with MFA Delete for extra protection.
• S3 Cross-Region Replication (CRR): Async replication to another region for compliance, latency, or DR.
• S3 Same-Region Replication (SRR): Async replication within the same region for log aggregation or data protection.
• RDS automated backups: Point-in-time recovery (PITR) within retention period (1-35 days).
• RDS manual snapshots: User-initiated, retained until deleted. Used for long-term backups.
• AWS Backup: Centralized backup service for multiple AWS services. Supports cross-region and cross-account backup copies.

📦 S3 Lifecycle Policies

Automate data management: Transition objects between tiers (Standard → Standard-IA → Glacier → Deep Archive) and Expire (delete) objects after a specified time. Abort incomplete multipart uploads after N days to clean up failed uploads.

🏷️ Data Retention & Classification

Use S3 object tags and S3 object lock (WORM — Write Once Read Many) for compliance. Macie discovers and classifies sensitive data. IAM policies + S3 bucket policies enforce access controls. S3 access logs and CloudTrail for audit trail.

📋 Compliance Alignment

AWS services are audited against compliance frameworks — you don't need to configure compliance, you need to use the right services to meet requirements. Key frameworks: HIPAA (healthcare — requires BAA), PCI DSS (credit cards), SOC 1/2/3 (general controls), GDPR (EU data privacy), FedRAMP (US government). AWS Artifact provides on-demand access to AWS compliance reports and agreements.

📋 Domain 1 — Key Services Cheat Sheet

Service	Category	What It Does	Exam Trigger
IAM	Access	Users, groups, roles, policies	"Least privilege" / "Cross-account"
IAM Identity Center	Access	Centralized SSO for multi-account	"Single sign-on" / "Multiple accounts"
AWS Organizations	Governance	Multi-account management with SCPs	"Restrict member accounts"
Control Tower	Governance	Automated multi-account setup + guardrails	"Set up new secure environment"
STS	Access	Temporary credentials via AssumeRole	"Temporary access" / "Federation"
Security Groups	Network	Instance-level stateful firewall	"Stateful" / "Allow rules only"
NACLs	Network	Subnet-level stateless firewall	"Stateless" / "Ephemeral ports"
AWS WAF	App Security	L7 web app firewall (SQLi, XSS)	"SQL injection" / "Rate limiting"
AWS Shield	Network	DDoS protection (Standard free, Advanced paid)	"DDoS" / "SYN flood"
Secrets Manager	Security	Secret storage with auto-rotation	"Rotate DB credentials"
Cognito	Identity	User sign-up/sign-in for apps	"Mobile/web app auth"
GuardDuty	Detection	Threat detection (ML + threat intel)	"Monitor for threats" / "Anomaly"
Macie	Data	Sensitive data discovery in S3	"PII" / "Classify data"
KMS	Encryption	Key management + encryption	"Encrypt at rest" / "Key rotation"
CloudHSM	Encryption	Dedicated HSM (FIPS 140-2 L3)	"Dedicated HSM" / "Level 3"
ACM	Encryption	TLS certificate management + auto-renewal	"TLS" / "HTTPS" / "Certificate"
VPC Endpoints	Network	Private AWS service access	"Private access without NAT/IGW"
Direct Connect	Network	Dedicated fiber to AWS	"Low latency" / "Consistent bandwidth"

📝 Sample Exam Questions

QUESTION 1

A company wants to securely store and automatically rotate database credentials for their RDS instances. Which AWS service should they use?

A) AWS Systems Manager Parameter Store

B) AWS Secrets Manager

C) AWS KMS

D) IAM Roles

✅ B) AWS Secrets Manager

Secrets Manager has built-in automatic rotation for RDS, Redshift, and DocumentDB. SSM Parameter Store can store secrets too but lacks native rotation. KMS manages keys, not credentials. IAM Roles can't store DB passwords.

QUESTION 2

A security engineer needs to design a VPC with a web application tier that can receive traffic from the internet and a database tier that cannot. The database must be able to download security patches from the internet. What is the MOST secure and cost-effective architecture?

A) Both tiers in public subnets with Security Groups restricting database access

B) Web tier in public subnet, database in private subnet with a NAT Gateway in the public subnet

C) Both tiers in private subnets with a NAT Gateway

D) Web tier in public subnet, database in public subnet with NACL restrictions

✅ B) Web tier in public subnet, database in private subnet with a NAT Gateway in the public subnet

The web tier needs direct internet access (public subnet + IGW). The database must be isolated (private subnet — no direct inbound from internet) but still needs outbound internet for patches → NAT Gateway.

QUESTION 3

A company uses AWS Organizations with 15 accounts. The security team needs to prevent all member accounts from using specific EC2 instance types. What should they do?

A) Create an IAM policy denying those instance types and apply it to each account

B) Use a Service Control Policy (SCP) to deny the ec2:RunInstances action with a condition on the instance type

C) Use AWS Config to detect and terminate non-compliant instances

D) Create a CloudFormation StackSet with a deny policy for all accounts

✅ B) Use a Service Control Policy (SCP) to deny the ec2:RunInstances action with a condition on the instance type

SCPs are the correct tool for restricting what member accounts can do — they apply to all principals including root. IAM policies can't prevent the root user from taking actions. Config is detective (reactive), not preventive.

QUESTION 4

A company needs to encrypt data at rest in S3 using a customer-managed key with automatic annual rotation. Which solution meets these requirements?

A) SSE-S3 with default encryption

B) SSE-KMS with a customer-managed key (CMK) and automatic rotation enabled

C) SSE-C with a customer-provided key

D) Client-side encryption with a customer-managed key

✅ B) SSE-KMS with a customer-managed key (CMK) and automatic rotation enabled

SSE-S3 is AWS-managed (no customer control). SSE-C uses your key but no automatic rotation. Only SSE-KMS with a CMK supports customer control + automatic annual rotation.

QUESTION 5

A solutions architect is designing a multi-tier web application. The application tier needs to send messages to an SQS queue. The SQS queue and the application are in the same VPC. The architect wants to minimize data transfer costs and ensure traffic does not leave the AWS network. How should they configure this?

A) Place the application in a public subnet with a public IP

B) Create a VPC Gateway Endpoint for SQS

C) Create a VPC Interface Endpoint (PrivateLink) for SQS

D) Use a NAT Gateway in the private subnet

✅ C) Create a VPC Interface Endpoint (PrivateLink) for SQS

Gateway Endpoints only support S3 and DynamoDB. SQS uses Interface Endpoints (PrivateLink), which provide private connectivity via an ENI with a private IP. Remember: Gateway = S3 & DynamoDB only. Interface = everything else.

🏆 Domain 1 — Exam Day Cheat Sheet

🔑 Must-Know Facts

• Explicit Deny always wins over Allow
• SGs are stateful; NACLs are stateless
• SGs have allow rules only; NACLs have allow + deny
• SCPs set permission boundaries, never grant
• KMS = FIPS 140-2 L2; CloudHSM = L3
• Secrets Manager rotates creds; Parameter Store doesn't

🎯 Common Exam Traps

• "IAM policies for cross-account" → Roles (not users)
• "Encrypt existing RDS instance" → Create snapshot, copy encrypted, restore (can't enable later)
• "Protect root user" → MFA + no access keys
• "Private subnet internet access" → NAT Gateway (in public subnet)
• "S3 private access without NAT" → Gateway Endpoint
• "DDoS protection" → Shield + WAF + CloudFront + Route53

✅ Domain 1 Complete

This covers 30% of the SAA-C03 exam. Review the cheat sheet, work through the sample questions, and use the chat assistant to test yourself on any topic.

← Back to Home

📊 Your Progress

📚 Course Syllabus

Core Networking Fundamentals

Cloud Foundations & Subnet Math

HA, Load Balancing & Compute Scale

Home Gateways, NAT & Isolation

Bare-Metal Hypervisors & Proxmox

Virtual Routing & VLANs

Edge Traffic, DNS & Capstone

🎯 What You'll Learn

📋 Prerequisites

📡 Core Networking Fundamentals

🎯 Learning Objectives

🏗️ The Core Ecosystem: What Happens When You Type a URL?

🔀 Layer 2 vs. Layer 3: The Local Street vs. The Global Highway

🆔 The MAC Address (Layer 2) — The Birth Certificate

🌐 The IP Address (Layer 3) — The Mailing Address

🔌 Hardware in Action: Switches vs. Routers

Network Switch (Layer 2)

Router (Layer 3)

🗣️ How Local Devices Talk: Meet ARP

🔬 Hands-On Lab: Interrogating Your Local Network

💡 Key Takeaways

✅ Self-Assessment

☁️ Cloud Foundations & Subnet Math

🎯 Learning Objectives

🏠 What is a Virtual Private Cloud (VPC)?

🌍 VPC Core Components

IP CIDR Block

Subnets

Internet Gateway

Route Tables

🧮 CIDR Notation & Subnet Math

📐 CIDR Quick Reference

🧮 CIDR Calculator

🛡️ Security Groups vs Network ACLs

Security Group

Network ACL

🖥️ AWS CLI Lab: Build Your First VPC

✅ Self-Assessment

⚖️ High Availability, Load Balancing & Compute Scale

🎯 Learning Objectives

🔄 The Load Balancer: A Friendly Receptionist

🏢 Three Types of Receptionists (Load Balancers)

Application LB (ALB)

Network LB (NLB)

Gateway LB (GLB)

🎯 Target Groups & Health Checks

🏥 Health Check Configuration

📈 Auto Scaling Groups: The Self-Adjusting Server Fleet

📋 Three ASG Configurations

🏗️ Multi-AZ Architecture

✅ Self-Assessment

🚪 Home Gateways, NAT & Network Isolation

🎯 Learning Objectives

🏠 RFC 1918 — The Private IP Addresses You Already Use

📋 RFC 1918 Private IP Ranges

🔄 NAT: How Many Devices Share One Public IP?

🔄 How NAT Works (Step by Step)

🏡 The Home Gateway Triple-Play: NAT + DHCP + DNS

1. NAT

2. DHCP

3. DNS

☁️ AWS NAT Gateway vs Cheap NAT Instance

💸 AWS Managed NAT Gateway

🚀 EC2 NAT Instance (t4g.nano)

🔀 Double NAT & the Travel Router Solution

✅ Self-Assessment

🖥️ Bare-Metal Hypervisors & Virtual Switching

🎯 Learning Objectives

🔲 Type 1 vs Type 2 Hypervisors

Type 1 — Bare-Metal

Type 2 — Hosted

📦 Proxmox VE Installation

Download Proxmox VE ISO

Create Bootable USB

Install on Bare Metal

Access Web Management UI

🌉 The Linux Bridge (vmbr0) — Virtual Switch

🔲 Creating VMs and LXC Containers