Cloud Networking — Connecting Safely

What you'll learn

• What a VPC is (your private cloud neighborhood)
• Subnets, security groups, and firewalls
• How traffic flows in and out safely
• The networking that keeps cloud apps secure

Your own gated neighborhood 🏘️

When you rent servers in a shared data center, you need your own private, isolated space — otherwise your database would sit on the open internet next to strangers. That private space is a VPC (Virtual Private Cloud): your own walled-off section of the cloud, like a gated neighborhood where only your buildings live.

Inside your VPC you organize things into subnets (streets within the neighborhood):

• Public subnet — has a door to the internet. Your web server lives here (users must reach it).
• Private subnet — no direct internet access. Your database lives here, hidden. It can only be reached by your web server inside the VPC, never directly from outside. This is a core security pattern: never expose your database to the internet.

Controlling who can talk to what, you use security groups — virtual firewalls wrapped around each server. A security group is a list of allow-rules:

Web server security group:
  ✅ allow port 443 (HTTPS) from anywhere    → users can load the site
  ✅ allow port 22 (SSH) from my office IP    → only I can log in
  ❌ everything else is denied by default

This is least privilege (from the security track) applied to networking: open only the exact ports you need, only to the sources that need them. The default-deny stance is what keeps attackers out.

Putting it together — a secure cloud app:

Internet → [public subnet: web server, ports 443 open]
                    ↓ (internal only)
           [private subnet: database, no internet access]

Master VPCs, subnets, and security groups and you can design cloud systems that are open where they must be and locked down everywhere else — which is exactly what a cloud engineer is paid to do.

Load balancers and CDNs: spreading and shortening the trip 🌐

Two more networking pieces round out a real cloud app: one spreads traffic across your servers, the other shortens the distance traffic has to travel at all.

A load balancer sits in front of multiple identical web servers and distributes incoming requests across them — like a host at a restaurant door directing guests to whichever table has room. Benefits stack up quickly:

• No single overloaded server — traffic spreads evenly.
• Survives a server crash — the load balancer stops sending traffic to a server that fails its health check, routing everyone else to the healthy ones instead. This is exactly the redundancy concept from cloud architecture, implemented at the network layer.
• Enables auto-scaling — add or remove servers behind it as demand changes, invisibly to users.

A CDN (Content Delivery Network) solves a different problem: physical distance. Without one, every user worldwide fetches your images and files from one origin server — slow for anyone far from it. A CDN caches copies of your static content on servers spread across the globe, so a user in Singapore gets served from a nearby CDN node instead of crossing the ocean to your origin server every time.

Together, a typical flow looks like: user → CDN (static files, cached nearby) → load balancer (spreads dynamic requests) → your servers in their VPC. Every piece you've learned in this lesson — VPC, subnets, security groups, load balancers, CDNs — is a real, named layer in almost every production web architecture you'll ever touch.

Real-world case study: The 2016 Dyn DNS attack 🔍

On October 21, 2016, attackers used a botnet of hijacked internet-of-things devices (compromised cameras, DVRs, and routers infected with the Mirai malware) to launch a massive DDoS attack against Dyn, a company providing DNS services — the "phone book" that translates website names into the IP addresses browsers actually connect to.

Because so many major sites relied on Dyn for DNS, the attack's effect spread far beyond Dyn itself: Twitter, Netflix, Reddit, Spotify, GitHub, and Amazon all became unreachable or badly degraded for large parts of the day across the US and Europe, even though none of their own servers were touched.

The attack is one of the clearest illustrations of why networking infrastructure — not just your own VPC and security groups, but shared services like DNS providers and CDNs — is a single point of failure if you rely on only one. It also demonstrated how ordinary consumer devices with poor security (default passwords never changed) can be hijacked at massive scale into a weapon against core internet infrastructure, reinforcing why the security-group discipline in this lesson (default-deny, minimum necessary access) matters at every layer, from a single server up to the entire internet's addressing system.

Summary

• A VPC is your isolated private network in the cloud
• Public subnets face the internet (web servers); private subnets stay hidden (databases)
• Security groups are per-server firewalls — allow only what's needed (least privilege)
• Never expose your database to the internet
• Load balancers spread traffic and survive server failures; CDNs shorten the distance to users
• The 2016 Dyn DNS attack shows how shared networking dependencies can be a single point of failure

Next: Infrastructure as Code — defining all this networking in code instead of clicking.