Cloud networking

01

Your own network in the cloud: virtual networks and IP address ranges

A cloud data center runs servers for a huge number of customers side by side. Still, your servers should only talk to each other and stay separated from everyone else's. So the cloud gives each customer a logically isolated network, called a virtual network. The physical cables and switches are shared, but the addresses, routes and rules belong to you alone.

The first thing you decide when you create a virtual network is the range of IP addresses it will use (its address range). You usually pick it from the private address ranges, which are reserved so they're never used on the public internet. Any company or household can reuse these private addresses, which is exactly why they can't go straight out to the internet on their own (chapter 3 shows how they get out).

CIDR: reading the number after the slash

An IPv4 address is 32 bits long. 10.0.0.0/16 means "the first 16 bits (10.0) are fixed, and this network gets to use the remaining 16 bits." That gives you 2^16 = 65,536 addresses. The bigger the number after the /, the more bits are fixed and the smaller the range. This notation is called CIDR, and the range it describes is a CIDR block. Try changing the subnet size in the scene below.

You then split the virtual network's range into subnets. A subnet is a zone where you group servers that play the same role — say, a web tier that faces the internet and a database tier you keep hidden. Each subnet can get its own routes (chapter 2) and firewall rules (chapter 4).

You can't use every address in a subnet

In every subnet, the cloud reserves a few addresses for itself: the first address (the network address), the gateway that leads out of the subnet, DNS and so on. How many it reserves depends on the cloud provider. So even a /24 subnet gives you a little less than 256 addresses for your servers.

Go big from the start, and don't overlap

Address ranges are hard to change once they're created. Plan for more servers and services down the road, pick a generous range, and make sure it doesn't overlap with your corporate network or your other virtual networks. Here's the part that trips people up: if your office network uses 192.168.0.0/16 and your cloud network uses the same range, then when you try to connect them later, nothing can tell which side's 192.168.1.10 you mean — so the connection simply won't work (chapter 7).

You've split your range into subnets. But when a server in a subnet sends a packet, how does that packet know where to go?

02

Subnets and routing: what makes a subnet public or private

When a server sends a packet, the route table associated with its subnet decides where it goes. A route table is a list of lines that say "packets headed for this range go out through that door." Every virtual network starts with a default route that says "addresses inside the network are delivered inside the network," so subnets can talk to each other without any extra setup.

Destination       Next hop (where to send it)
10.0.0.0/16       Inside the network (local)
172.16.0.0/12     VPN connection → corporate network
0.0.0.0/0         Internet gateway

The route table looks for the line that matches the packet's destination address and sends it to that line's next hop. Say a web server sends a packet to a database server on the same network (10.0.2.15). 10.0.2.15 is inside 10.0.0.0/16, so it matches the first line. But 0.0.0.0/0 means "every address," so it matches the last line too.

When several lines match, the most specific one wins — the one with the bigger number after the /. This is called longest prefix match. A /16 is more specific than a /0, so this packet is delivered inside the network. A website on the internet (203.0.113.10), on the other hand, doesn't match the first two lines. It only matches 0.0.0.0/0, so it goes to the internet gateway. That's why 0.0.0.0/0 is called the default route: it's where any address that matches nothing else ends up. Try changing the destination and the subnet type in the scene below.

Public subnets and private subnets

A subnet with a route toward the internet (0.0.0.0/0 → internet) is called a public subnet, and one without it is a private subnet. Here's the part that trips people up: it's the route that decides, not the name you gave the subnet. And even in a public subnet, a server needs a public IP to talk to the internet directly. A server with only a private IP can't be reached from the internet, even if it sits in a public subnet.

A typical web service is laid out like this.

You've hidden your database and app servers in private subnets. But they still need security updates, and they need to reach the cloud's storage service. With no internet route, how do they get out?

03

Getting out of a private subnet: NAT and private endpoints

NAT (network address translation) acts on behalf of your private servers. When a server sends a packet to the internet, NAT swaps the packet's source address for its own public IP and sends it out. When the reply comes back, NAT remembers who made the request and hands the reply to the right server.

The key is direction. NAT only handles connections that start from the inside. A connection that starts from the outside is dropped, because NAT has no idea which server it's for. So when a question says "the servers must get updates but must not be reachable from the internet," the answer is NAT. If you do need to accept requests from the internet, you need a load balancer (chapter 5) or a public IP on the server.

You usually use NAT as a service the cloud manages for you. You can also turn a server of your own into a NAT instance, but if it goes down, the whole private subnet loses its way out — so high availability and upkeep are on you. Where a managed NAT lives (a single zone, or the whole region) depends on the provider.

Reaching cloud services without the internet: private endpoints

Managed cloud services like storage, queues and key management usually have public, internet-facing addresses. If a private server just calls them, the traffic goes out through NAT to the internet and comes back in. With a private endpoint, that trip stays inside your network. There are two kinds.

Now the packets know where to go. But just because there's a road doesn't mean you let anyone drive on it. You need a gatekeeper that decides which packets get in and which get blocked.