Cloud Networking

This module does not re-teach IP, subnetting, routing or TCP — those live in the Networking domain. It teaches what a provider hands you on top of them, and why a packet needs five separate things to agree before it arrives.

Q · Which cloud constructs sit between the internet and my workload, and what does each one actually decide?

A logically isolated network you own inside someone else's data center: an address range, subnets, routes, gateways and firewall rules. Two of those decisions are effectively permanent, and one of them is made in the first five minutes.

Q · What exactly do I get when a provider gives me a "network", and which of its properties can I never change?

The difference is one line in a route table, not a property of the subnet. Which is why the useful question is not "is this subnet public" but "does this workload need a public address at all" — and for most workloads the answer is no.

Q · Which workloads need to be addressable from the internet, and what changes for the ones that do not?

Destination → target, evaluated by longest prefix match, attached to a subnet. Three columns and a handful of rows that decide whether anything in your network can reach anything at all — and whose failure mode is always a hang.

Q · When a packet leaves a workload, what decides where it goes next — and why does the wrong answer produce silence instead of an error?

The door between a virtual network and the internet — and only the door. Attaching one is necessary for reachability and nowhere near sufficient, which is why "it has an internet gateway and still cannot reach the internet" is the most reliable lab in this module.

Q · What does attaching an internet gateway actually give me, and what else has to be true before a packet arrives?

How a workload with no public address still reaches the internet — and why the component that grants it is a shared, metered, surprisingly fragile choke point.

Q · How does a workload in a private subnet call an external API without becoming reachable from the internet?

Source → protocol/port → destination, evaluated per resource, allow-only, and stateful — the reply to an allowed request is always permitted. The single most useful property is that a rule can name another group instead of an address range.

Q · What is allowed to reach this specific resource, and what is it allowed to reach in return?

Subnet-level, ordered, allow-and-deny, and stateless — which means the return traffic needs its own rule. That one word, stateless, is the entire lesson and the source of every incident this construct causes.

Q · When is a coarse, stateless, subnet-wide filter worth adding on top of stateful per-resource rules?

Peering, private endpoints, service endpoints and transit hubs — four ways to reach something without traversing the public internet. They exist for exposure reasons and they usually pay for themselves by taking traffic off the NAT meter.

Q · How does a private workload reach another network or a provider service without a path to the internet?

api.example.com → DNS → load balancer → application. In cloud, DNS is not just a lookup table: it is a routing layer with health checks, geography and weights — and a cache you do not control that makes every change slower than it looks.

Q · How do clients find my infrastructure, and what does DNS decide that a load balancer cannot?

The Architecture domain argues why you need one. This lesson is about running it: external versus internal, L4 versus L7, health checks that tell the truth, TLS termination, and target registration that has to keep up with a deploy.

Q · What does a load balancer own in a deployment, and which of its settings turns a rolling deploy into an outage?

User → edge → origin. From the deployment side a CDN is three things at once: a latency reduction, an origin shield that absorbs traffic your infrastructure never sees, and a cache-invalidation problem you now own.

Q · What changes in my infrastructure when an edge network sits in front of it?