CloudBridge — before & after

The full project: a public site (ifailedats.me) on AWS, plus a private encrypted tunnel joining my home network to the cloud. The Before/After switch changes only the part that was rebuilt — how the site is served inside AWS. Everything else (home, VPN, DNS, load balancer) stays the same. Tap any box for details.

Updated Sunday, July 12, 2026 — HTTPS live

focus a path · or flip Before/After above
YOUR HOME AWS CLOUD THE INTERNET the open public network VPC · 10.50.0.0/16 Security Group 💻 My Mac control only · wired to UniFi 🛡️ UniFi Gateway my real router · firewall ON builds the VPN · 192.168.2.x 📡 Fios gateway ISP box · DMZ standing aside 192.168.1.x 🌍 Any visitor no tunnel needed 🏷️ domain ifailedats.me 📖 Route 53 DNS · address book 🚪 Load Balancer 80 → 8080 80/443 → 30080 🖥️ EC2 node · k3s "the PC" · t3.small 🌐 Web server :8080 · on OS serves the page itself "Hello Pod" single process 📦 5 client pods just poll & log every 10s 🔀 K8s Service NodePort 30080 · load-balances pods 5 nginx pods — THE website nginx nginx nginx nginx nginx 🪣 S3 + IAM role stores page · no passwords 🔗 Virtual Priv. Gateway · AWS tunnel end 🔒 VPN tunnel encrypted · UniFi ⇄ AWS
home / private / pods public access AWS internal old standalone / ISP

Concepts & decisions (the "why")

Pros & cons — the two serving designs

◀ Before

A standalone server serves the page; the 5 pods just poll it and log "Hello Pod."

Pros
  • Dead simple — one process serves everything, easy to picture.
  • Good for learning the pieces separately (a server, plus pods as clients).
Cons
  • Single point of failure — the whole site rode on one process on one box.
  • Kubernetes wasn't really doing its job; it babysat pods that only printed text.
  • Two overlapping moving parts (server + pollers) for no real payoff.
  • No load spreading or self-healing for the actual website.

After ▶

The 5 pods each run nginx and serve the site, load-balanced by a Service on NodePort 30080.

Pros
  • Real redundancy — 5 pods serve; if one dies the others keep going and k8s replaces it.
  • Kubernetes finally earns its keep: self-healing + scaling the real web servers.
  • One clear job — the pods are the website.
  • Scale up or down by changing the replica count.
Cons
  • More concepts to hold: Service, NodePort, init containers, target group.
  • Slightly heavier startup — each pod pulls from S3 before it can serve.
  • Still one EC2 node underneath; true high-availability would need multiple nodes.
Bottom line: the "after" design is what Kubernetes is built for — the pods do the serving, so the platform's self-healing and load-spreading actually protect the website. "Before" was a useful stepping stone, but it left the real work on one fragile process while the pods just watched. Everything outside AWS — home, double-NAT, DMZ, the VPN tunnel — is identical in both.