Networking Fundamentals
Cloud Platform Fundamentals
Chapter 5 · Networking Fundamentals
Compute (Chapter 3) and storage (Chapter 4) are now covered — this chapter is about how everything actually talks to everything else, and to the outside world. It's arguably the single most support-relevant chapter in this course: "I can't connect to X" is probably the most common category of real cloud support ticket there is.
Regions & Availability Zones, Revisited
A quick recap from Chapters 1 and 4: regions are geographic areas, and availability zones (AZs) are isolated data centers within a region. For networking specifically, this matters because resources in the same region but different AZs still need connectivity between them — the provider's own backbone network handles that transparently. Latency naturally increases with geographic distance between regions, a real factor when placing resources relative to their users.
Virtual Networks — VPCs & VNets
A VPC (AWS/GCP) or VNet (Azure) is a private, logically isolated network you define within a region, with an IP address range you choose (a CIDR block). By default, it's isolated from every other customer's network — this is the foundational network security boundary everything else in this chapter builds on top of.
Subnets
A VPC/VNet is divided into smaller segments called subnets, typically one per availability zone. The most important distinction: a public subnet has a route to an internet gateway; a private subnet doesn't (or only routes outbound through a NAT gateway, covered below).
This split exists for a genuine architectural reason: web servers commonly sit in a public subnet, directly reachable from the internet, while databases sit in a private subnet, not directly reachable from the internet at all. A support ticket asking "why can't I reach my database directly from outside" is very often this exact pattern working correctly, by design — not a bug to fix.
Security Groups & Network ACLs — The Traffic Gatekeepers
| Security groups | Network ACLs | |
|---|---|---|
| Applies to | Individual instances/resources | An entire subnet |
| Stateful? | Yes — return traffic automatically allowed | No — return traffic must be explicitly allowed too |
| Rule types | Allow rules only (typically) | Both allow and deny rules |
A misconfigured security group blocking the wrong port is very likely the single most common real-world networking support issue there is. The practical debugging order: check the resource's security group inbound rules first, then the subnet's network ACL, then routing.
Routing & Gateways
- Route tables — direct traffic leaving a subnet to its correct destination.
- Internet gateway — provides a route to/from the public internet for a public subnet.
- NAT gateway — lets a private subnet reach the internet outbound only, without being directly reachable from it.
- VPC peering — connects two VPCs together directly.
- Transit gateway / hub-and-spoke — connects many VPCs through a central hub, rather than peering each pair individually.
This vocabulary is picked up again properly in Course 2's connectivity-troubleshooting chapter (cloud2-2).
Load Balancers
Revisiting Chapter 3's brief mention: a load balancer distributes incoming traffic across multiple backend instances, using health checks to route traffic only to instances currently reporting healthy — the exact same health-check mechanism Chapter 3 described for auto-scaling groups, working together with it.
| Layer | What it sees | AWS | Azure | GCP |
|---|---|---|---|---|
| Layer 4 (network) | Raw TCP/UDP connections | NLB | Load Balancer | Network LB |
| Layer 7 (application) | HTTP-aware — can route by URL path, host header, etc. | ALB | Application Gateway | HTTP(S) LB |
DNS in the Cloud
Route 53 (AWS), Azure DNS, and Cloud DNS (GCP) provide hosted DNS zones for your own domains, and are also commonly used for internal service discovery within a VPC. A genuinely frequent support scenario: a customer makes a DNS change and asks why it hasn't taken effect everywhere yet. The answer is almost always TTL (time to live) — a value on each DNS record controlling how long resolvers around the internet are allowed to cache it before checking again. A record with a one-hour TTL can take up to an hour to fully propagate to every resolver that had it cached, purely by design.
cloud2-2) builds directly on this exact sequence with a full worked flowchart.
Hands-On Exercises
Explain the difference between a security group and a network ACL — what each applies to, whether each is stateful, and specifically why "return traffic is automatically allowed" is true for one but not the other.
📄 View solutionA web server sitting in a public subnet cannot be reached on port 443 from the internet. List, in order, the checks you'd perform to diagnose this, and explain what each check rules out.
📄 View solutionExplain what TTL is, and why a DNS record change might not be visible to all users immediately after it's made.
📄 View solutionChapter 5 Quick Reference
- VPC/VNet — a private, isolated network within a region; subnets divide it, usually per AZ
- Public subnet (internet gateway route) vs. private subnet (no direct inbound route, often NAT for outbound) — databases-in-private/webservers-in-public is a deliberate pattern, not a bug
- Security groups (stateful, per-resource) vs. NACLs (stateless, per-subnet) — both must allow traffic; checking only one is a common mistake
- Route tables/internet gateway/NAT gateway/VPC peering/transit gateway — the routing vocabulary picked up again in
cloud2-2 - Load balancers use the same health checks as auto-scaling (Ch.3); Layer 4 (TCP) vs. Layer 7 (HTTP-aware)
- DNS TTL controls propagation delay — the standard explanation for "my DNS change hasn't taken effect everywhere yet"
- Practical troubleshooting order: security group → NACL → route table → DNS
- Next chapter: Identity & Access Management — IAM concepts across providers, least privilege, and MFA