Cloud Networking Basics

Companies increasingly run their servers in a public cloud instead of their own data centre. The servers are virtual, and so is the network that connects them. The good news is that everything you have learned so far (IP addresses, subnets, gateways, NAT, firewalls) still applies. The cloud gives each piece a new name and lets you create it with a few clicks or a few lines of code.

What the cloud is

Cloud computing means renting computing resources (servers, storage, databases, networks) from a provider over the internet, on demand, and paying for what you use. The large public cloud providers include Amazon Web Services (AWS), Microsoft Azure and Google Cloud. Behind the scenes, the cloud is a set of huge data centres full of physical servers, and you rent virtual slices of them.

You will meet two more terms everywhere. A region is a geographic area where a provider has data centres (for example, "Frankfurt" or "US East"). Each region is split into availability zones (AZs): separate data centres, a few kilometres apart, with their own power and cooling. Placing copies of a service in two AZs keeps it running if one site fails.

Why cloud networking exists

Thousands of customers share the same physical data centres. Each one needs its own private network that:

• is isolated: no other customer can see or reach it;
• uses its own addresses: chosen by the customer, often from the same private ranges that other customers use;
• is controlled by the customer: which servers can reach the internet, which can talk to each other and which can reach the office.

No provider could rewire physical switches for every customer, so the network is software-defined. The provider's systems wrap (encapsulate) each customer's traffic so that it stays inside that customer's virtual network. The customer configures routes and firewalls through a web console or code.

The building blocks, and what each provider calls them

The rest of this lesson uses the general names: VPC, internet gateway, NAT gateway, security group and network ACL.

A VPC with public and private subnets

Here is one of the most common cloud designs, used behind countless websites: a web server that people can reach, and an application server and database that they can't.

The virtual private cloud (VPC)

A VPC (or VNet) is your own private network inside the cloud. When you create one, you give it an address range in CIDR notation, usually from the private (RFC 1918) ranges, for example, 10.0.0.0/16 (65,536 addresses). Every resource you create in the VPC gets an address from this range.

💡 Plan the range first. If the cloud network will ever connect to the office or to another VPC, its range must not overlap with theirs. If the office uses 192.168.0.0/16 and the VPC does too, routing between them breaks, because each side thinks the other's addresses are local. Changing a VPC's range later is difficult.

Subnets: public and private

You split the VPC into subnets, smaller ranges such as 10.0.1.0/24 and 10.0.2.0/24. In AWS, each subnet lives in one availability zone; in Azure and Google Cloud, a subnet covers a whole region. You put each resource in the subnet that matches how exposed it should be:

In each subnet, the cloud provides a virtual router at the first usable address (here 10.0.1.1 and 10.0.2.1). That is each VM's default gateway, handed out by the cloud's built-in DHCP service. Most clouds also reserve a few other addresses in each subnet, so a /24 gives slightly fewer than 254 usable addresses.

Route tables

A route table is a list of rules, each with a destination range and a target. Every subnet uses one route table. Like a router, the cloud chooses the most specific matching rule (the longest prefix) for each packet.

⚠️ The local route means that all subnets in a VPC can reach each other by default. To stop the web subnet from talking to the database subnet, you use security groups and network ACLs, not routes.

Public and private IP addresses in the cloud

Every VM gets a private IP address from its subnet and usually keeps it for as long as the VM exists. A VM in a public subnet can also be given a public IP address. There are usually two kinds: a temporary one that may change when the VM is stopped and started, and a fixed ("static" or "elastic") one that you reserve and keep.

This surprises many beginners: the public IP address is not configured on the VM. The VM only knows its private address. The internet gateway translates between the two, one-to-one, as packets pass through. It is the same idea as static NAT.

Learn more: How NAT and PAT Work

Internet gateway and NAT gateway

How traffic flows, step by step

Packet behaviour: what changes on the way

Flow 1, the customer's request and the reply:

Flow 3, the private app server going out through the NAT gateway:

The update server (192.0.2.80) only ever sees 203.0.113.40. The NAT gateway remembers the mapping, so the reply finds its way back to 10.0.2.20.

Security groups and network ACLs

The cloud gives you two built-in firewalls, at two different places:

💡 Least privilege: the web server's security group allows TCP 443 from anywhere. The app server's group allows TCP 8080 only from the web server's security group. The database's group allows TCP 5432 only from the app server's group. Even if an attacker takes over the web server, they can't reach the database directly. This is network segmentation in the cloud.

Hybrid connectivity: linking the cloud to the office

Most companies don't move everything at once. A hybrid network joins the on-premises network (the office or company data centre) with the cloud so that they work as one network.

Either way, the cloud's route table needs a route to the office range (192.168.0.0/16 → VPN gateway), and the office router needs a route back to 10.0.0.0/16. If you forget one direction, traffic goes out but the replies never return.

A real-world example

A small accounting firm moves its client portal to the cloud. The firm:

1. Creates a VPC, 10.0.0.0/16, which doesn't overlap the office's 192.168.0.0/16.
2. Creates public subnets in two availability zones for a load balancer and NAT gateways, and private subnets in both zones for the portal servers and the database.
3. Gives the load balancer the only public address that customers use; the portal servers have private IP addresses only.
4. Sets security groups: the load balancer allows TCP 443 from anywhere, the portal servers allow TCP 443 only from the load balancer, and the database allows TCP 5432 only from the portal servers.
5. Builds a site-to-site VPN so that staff can reach the admin pages, which are never exposed to the internet.

If one availability zone has a power failure, the load balancer sends all traffic to the servers in the other zone. This is the same redundancy idea as in a physical data centre, done in software.

What happens when it fails

Troubleshooting and useful commands

Cloud troubleshooting follows the same method, but the "cables and switches" are now configuration settings. Check these, in order:

1. The VM: Is it running? Does it have the correct private IP address? Is the service listening (ss -tulpn)? Is the OS firewall blocking it?
2. Security group: Is the port allowed from the right source?
3. Network ACL: Are both directions allowed, including the reply ports?
4. Route table: Does the subnet's route table have the route you expect (internet gateway, NAT gateway or VPN)?
5. Public IP and gateways: Does the resource have a public IP address? Is the internet gateway attached, and is the NAT gateway healthy?

Cloud providers also offer flow logs (a record of accepted and rejected connections) and reachability analysers, which trace a path through your configuration and tell you which rule blocks it.

$ ip -br addr; ip route
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens5             UP             10.0.1.10/24 fe80::ff:fe00:110/64
default via 10.0.1.1 dev ens5 proto dhcp src 10.0.1.10 metric 100
10.0.1.0/24 dev ens5 proto kernel scope link src 10.0.1.10 metric 100

$ nc -vz -w 5 10.0.2.20 8080
nc: connect to 10.0.2.20 port 8080 (tcp) timed out: Operation now in progress

$ nc -vz -w 5 10.0.2.20 8080
nc: connect to 10.0.2.20 port 8080 (tcp) failed: Connection refused

From outside, the Port Checker tests whether a public port is open, and What Is My IP shows the public address your traffic comes from, such as the NAT gateway's address.

Common mistakes

Check yourself

Related lessons

Cloud networking is built from ideas you already know. These lessons cover the building blocks, the physical data centres the cloud runs on, and the full end-to-end picture.

Learn more: Public and Private IP Addresses · Subnet Mask Basics · The Default Gateway · How NAT and PAT Work · Firewall Basics · VPN Basics · Data Centre Networking Basics · What Happens When You Open a Website?