Module 2 — Networking, DNS, HTTPS & Application Architecture
Goal: connect what you already know (OSI 1–3) to what web systems need (3–7): IP/subnets in the cloud, DNS end-to-end, TLS/HTTPS, load balancing, and the 3-tier architecture you'll build in the capstone.
A field engineer can move fast here — this module is a bridge, not a beginner class.
2.1 OSI recap — but pointed at the web
| Layer | Telecoms life | Cloud life | Tools you'll use |
|---|---|---|---|
| 1 Physical | your old job | AWS's problem now | — |
| 2 Data link | Ethernet, VLANs | VPC is "virtual layer 2/3" | — |
| 3 Network | IP, routing | VPCs, subnets, route tables, NAT GW | ip, traceroute |
| 4 Transport | TCP/UDP ports | Security groups, load balancers | ss, nc, curl |
| 5–6 Session/Pres. | — | TLS lives here | openssl |
| 7 Application | signalling protocols | HTTP, DNS, gRPC | curl, dig |
Key reframe: a security group is a per-server firewall ruleset at layer 3/4; an application load balancer is layer 7 kit (it reads HTTP); a network load balancer is layer 4 (it forwards TCP and doesn't care what's inside).
Lab 2.1 — Dissect a connection
On lab-box:
traceroute 1.1.1.1 # count the hops out of AWS
ss -tn state established # your own SSH session at layer 4
sudo tcpdump -i any port 22 -c 20 -nn # watch your own keystrokes as packets
nc -zv example.com 443 # layer-4 reachability test
nc -zv example.com 8443 # closed port — compare the failure mode
Discussion: how does nc -zv compare to a loopback test on a circuit?
2.2 IP addressing & subnetting in the VPC
Recap CIDR: /24 = 256 addresses, /16 = 65,536. AWS reserves 5 per subnet.
The lab environment you're inside right now:
VPC 10.42.0.0/16
└── public subnet 10.42.1.0/24 → route 0.0.0.0/0 → Internet Gateway
├── lab-box (private 10.42.1.x + public IP)
└── monitor-box (private 10.42.1.x + public IP)
ip a # find your private IP — matches the diagram?
curl -s ifconfig.me; echo # your public IP (NAT'd by AWS)
ip route # default gateway = the subnet's ".1"
Private vs public IP here is exactly NAT as you know it from CPE routers — AWS does 1:1 NAT between the instance's private address and its public one.
2.3 DNS — the full journey
Theory (draw it): stub resolver → recursive resolver → root → TLD (.net) →
authoritative (Route 53) → answer, with TTL caching at every step.
Record types you'll actually use: A, AAAA, CNAME, ALIAS (Route 53 special),
MX, TXT (SPF/DKIM/DMARC live here), NS, SOA.
Lab 2.3 — Interrogate real DNS
Use the instructor's production domain (a real Route 53 zone):
dig ratib.elhindi.net # the A/ALIAS answer
dig ratib.elhindi.net +short
dig ratib.elhindi.net +trace # THE money command: watch root→TLD→R53
dig NS elhindi.net +short # who's authoritative? (awsdns servers)
dig TXT elhindi.net +short # SPF etc — email deliverability records
dig CNAME www.ratib.elhindi.net +short
time dig ratib.elhindi.net # then run again — spot the cache
Instructor show/tell: open Route 53 in the console; show the hosted zone that just answered those queries; show the ALIAS record pointing at CloudFront.
2.4 HTTP and HTTPS/TLS
HTTP theory in 15 minutes: request line, headers, status codes (2xx/3xx/4xx/5xx), methods (GET/POST/PUT/DELETE), statelessness, cookies.
TLS theory: certificates bind a name to a public key, signed by a CA the client already trusts; the handshake negotiates a session key; SNI lets one IP serve many certificates. Certificates expire — a classic outage cause (and a classic alert you'll build in module 7).
Lab 2.4 — curl and openssl as test sets
curl -v http://example.com 2>&1 | head -30 # raw HTTP, see every header
curl -I https://ratib.elhindi.net # response headers only
curl -sI https://ratib.elhindi.net | grep -iE 'server|via|x-cache' # CloudFront fingerprints
curl -s -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n' https://ratib.elhindi.net
openssl s_client -connect ratib.elhindi.net:443 -servername ratib.elhindi.net </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
Checkpoint: who issued the certificate, and when does it expire? Where does TLS
sit in the OSI stack? What does the x-cache: Hit from cloudfront header mean?
Lab 2.4b — Serve your own site
mkdir ~/www && echo "<h1>Served from lab-box by $(whoami)</h1>" > ~/www/index.html
cd ~/www && python3 -m http.server 8080
# From your laptop browser: http://<lab_box_public_ip>:8080 → blocked. Why?
The security group doesn't allow 8080. Instructor opens it live in the console (or better: adds it in Terraform and applies — foreshadowing module 4). Reload — it works. This is the lesson: in cloud, "the firewall" is three lines of code.
2.5 Three-tier architecture & application design
The canonical pattern, and what each tier is for:
[Client/browser]
│ HTTPS
[Tier 1: Presentation] CDN / static frontend / load balancer (CloudFront, ALB, nginx)
│
[Tier 2: Application] business logic, APIs, stateless! (EC2, containers, Lambda)
│
[Tier 3: Data] state lives here and only here (RDS, DynamoDB, S3)
Design principles to internalise now (they drive modules 4–8):
- Statelessness in tier 2 → any instance can serve any request → horizontal scaling and zero-downtime deploys become possible.
- Scale out, not up: ten small boxes behind a load balancer beat one giant box — same reasoning as diverse routing/protection paths in transmission.
- Failure domains: AZs are like geographically separate exchanges; spread tiers across at least two.
- Caching layers (CDN, in-memory) absorb read traffic before it reaches expensive tiers.
- Decoupling with queues: bursty traffic smoothed like a traffic shaper.
Instructor show/tell: map your production PWA onto the model — CloudFront (tier 1) → S3 origin (static tier 2/3 collapsed). Discuss why a static PWA can collapse the tiers, and what would force them apart (user accounts? server-side rendering? a DB?).
Design exercise (whiteboard, no computer)
"Design a system for engineers in the field to submit job-completion photos: 2,000 engineers, bursty at end-of-day, photos must be kept 7 years, managers view a dashboard." Student proposes tiers, storage, scaling, failure handling. There's no single right answer — argue trade-offs. Revisit this design after module 7; it will have improved dramatically.