The question this answers
Which cloud constructs sit between the internet and my workload, and what does each one actually decide?
The team has an API and a PostgreSQL database. Users must reach the API from the internet; nothing should be able to reach the database except the API. Both sentences are network requirements before they are anything else.
A single reachability model: internet → public entry point → virtual network → public subnet → private subnet → database, with a named construct owning each hop and a named failure when it is wrong.
The path, and who owns each hop
Cloud networking is composition, not new physics. The addresses are still IP addresses, the routes are still longest-prefix matches, the connections are still TCP, and the Computer Networking domain teaches all of that properly. What a provider adds is a set of *software-defined* constructs that decide, per packet, whether those fundamentals get a chance to operate: a virtual network that owns an address range, subnets that carve it up, route tables that pick a next hop, gateways that connect to the outside, and firewalls that filter.
The most useful mental model is a chain where every link can independently say no. A request from a user reaches a load balancer because DNS resolved to it, its security group allows 443 from anywhere, its subnet has a route to an internet gateway, and that gateway is attached. It then reaches the application because the application's security group allows the load balancer specifically, the route between subnets exists implicitly as a local route, and the application is actually listening. It reaches the database because the database's security group allows the application's security group on 5432 and nothing else.
Every troubleshooting session in this module is the same exercise: walk the chain and find the link that says no. Which is why the signature symptom matters — a *hang* usually means a routing or firewall drop, while an immediate *connection refused* usually means the packet arrived and nothing was listening. That single distinction resolves a large fraction of real incidents. See Security Groups: The Stateful Firewall and Route Tables.
What this module owns, and what it hands off
The division of labour is worth stating explicitly, because cloud networking material routinely re-teaches subnetting badly. Everything about how an address range is divided, how a router picks a route, how a TCP connection is established and how NAT rewrites a packet is taught in the Computer Networking domain, and this module assumes it.
What is genuinely specific to cloud is that each of these things is now a billed, limited, API-managed resource with its own availability characteristics — and that the boundaries they draw are the primary security control in most cloud architectures. A route table is not a router you rack; it is an object with a quota, attached to a subnet, changed by a deploy pipeline, and audited when something goes wrong.
Five things must agree, and only one of them is a firewall
The recurring lab in this module — "it should be reachable and it is not" — is nearly always one row of the table below. Learning the table is more valuable than learning any individual construct, because it converts an open-ended debugging session into a five-item checklist that can be walked in order.
Note the last column. The symptom is the diagnostic: a routing or firewall drop produces silence and then a timeout, because nothing sends a rejection. A packet that arrives at a host with no listener produces an immediate connection refused. If you are getting refused, the network is fine and the problem is the process; if you are hanging, stop looking at the application.
| Requirement | Construct that decides it | Typical mistake | Symptom when wrong |
|---|---|---|---|
| A name resolves to the right address | DNS record and its TTL | Record still points at the old load balancer. | Works for some users, fails for others, resolves over minutes. |
| A route exists to the destination | Route table attached to the source subnet | No 0.0.0.0/0 entry, or it points at the wrong target. | Hang, then timeout. Nothing is logged anywhere. |
| The resource has a usable address | Public IP assignment, or a NAT for egress | Instance in a public subnet with no public address. | Hang. The instance can be reached from inside and from nowhere else. |
| A firewall permits the traffic | Security group (stateful) and network ACL (stateless) | Group allows the CIDR but not the referenced group; ACL missing the return range. | Hang. With an ACL, often works one direction only. |
| Something is listening on the port | The process, and its bind address | Bound to 127.0.0.1 instead of 0.0.0.0. | Immediate connection refused — which proves the network is fine. |
Key points
- Cloud networking composes the fundamentals taught elsewhere; what is new is that every construct is a billed, limited, API-managed object.
- Reachability is a chain in which five independent things must all agree, and any one of them can silently refuse.
- A hang means a route or firewall dropped the packet; an immediate connection refused means the packet arrived and nothing was listening.
- The virtual network boundary is the primary security control in most cloud architectures, not an addressing convenience.
- A public load balancer on 443 is the design; a public database on 5432 is the finding. Exposure is judged in context.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • A virtual network reserves a private address range inside a region and isolates it from every other tenant by default.
- • Subnets divide that range and pin resources to an availability zone; each subnet is governed by exactly one route table.
- • Route tables map destination prefixes to targets — local, an internet gateway, a NAT device, a peering connection or a transit hub.
- • Gateways attach the network to something outside it; without an attachment and a route, the outside does not exist.
- • Security groups filter statefully per resource, and network ACLs filter statelessly per subnet, and both must permit the traffic.
- • Own the address plan before the first subnet exists — the range is effectively permanent once workloads run in it.
- • Own route-table changes as reviewed infrastructure code; a hand-edited route is the classic cause of an outage nobody can attribute.
- • Own the mapping from tier to subnet, so "where does this workload go" is a rule rather than a per-deployment decision.
- • Own flow logs and their retention: they are the only record of what actually traversed the network.
- • Own the exposure review — periodically enumerate everything with a public address and justify each one.
- • A missing route: connections hang until timeout, with nothing logged on either side.
- • A firewall rule referencing a CIDR that changed, so traffic that used to work stops after an unrelated subnet resize.
- • Address exhaustion in a subnet, which presents as a deployment failing to place new instances rather than as a network error.
- • A stateless ACL permitting the request and dropping the response, producing one-directional connectivity that looks like packet loss.
- • DNS pointing at a decommissioned endpoint, which fails progressively as caches expire rather than all at once.
- • The first hard limit is usually address space: a subnet sized /28 for a pilot cannot host the fleet the pilot became.
- • Quotas on route-table entries, security-group rules and peering connections bite in large environments long before bandwidth does.
- • Cross-zone and cross-region traffic scales in cost as much as in latency — data transfer is metered per gigabyte in most directions.
- • Constructs that terminate connections — load balancers, NAT devices, proxies — have their own concurrency ceilings that scale separately from your fleet.
- • Network position is the first control: a resource with no route to the internet cannot be reached from it regardless of its software.
- • It is a layer, not a substitute for authentication. A database in a private subnet with a weak password is still a database with a weak password. See Public Exposure, Read With Context.
- • Default-deny is the correct posture inbound; the harder discipline is default-deny *outbound*, which most environments never adopt.
- • Flow logs and gateway logs are the evidence base for any exfiltration or intrusion investigation, and they must exist before the incident.
- • Most of the constructs — virtual networks, subnets, route tables, security groups — cost nothing themselves.
- • The things that move or terminate bytes cost money: NAT devices, load balancers, gateways, and every gigabyte that crosses a zone, region or the internet boundary.
- • Data transfer out to the internet is the classic surprise, and traffic to provider services over a NAT rather than a private endpoint is the classic avoidable one. See Egress: Moving Data Costs Money, Not Just Storing It.
- • Reliability multiplies the fixed items: per-zone NAT devices and multi-zone load balancers are the cost of not having a single point of failure.
- • Flow logs with accept/reject decisions — the fastest way to prove which link in the chain refused.
- • Load balancer target health and gateway error counts, which separate "the entry point is broken" from "the targets are".
- • Available addresses per subnet, watched before it reaches zero rather than during the failed deploy.
- • The signal that lies: an application health check that never leaves the virtual network. It stays green through a total loss of internet egress.
- • The provider's default network with a managed platform on top, for a small team with one application — a hand-designed virtual network is real work and buys nothing at that size.
- • A platform-as-a-service that owns the networking entirely, when the requirement is "run this container and give me a URL" and there is nothing private to reach.
- • A single public subnet with strict security groups, for a stateless service with no private data — the public/private split is worth its complexity only when there is something to keep private.
- • Provider-managed private connectivity instead of designing peering topologies by hand, once there is more than one network to join. See Private Connectivity.
- • Buys a strong, cheap isolation boundary; costs an address plan you cannot easily change and a set of constructs every engineer must understand to debug anything.
- • Buys defence in depth; costs debugging difficulty, because five independent components can each fail silently and identically.
- • Buys precise control; costs the risk that control is exercised by hand, out of band, and forgotten. See Drift: When the File and Reality Disagree.
What people believe, and what is true
Cloud networking is a new kind of networking.
It is the same IP, routing and TCP, exposed as API-managed objects with quotas and bills. What changes is who configures them and how fast they change.
Private subnet means secure.
It means unreachable from the internet by default. It says nothing about credentials, authorization or lateral movement from a compromised neighbour.
If the packet is not arriving, it is a firewall.
It is a firewall, a route, a missing address, a DNS answer or a process bound to localhost. The symptom tells you which family: hang versus refused.