Cloud Networking Basics: VPCs, Subnets, Firewalls, and Floating IPs
The network pieces behind every cloud server: VPCs and private networks, subnets and CIDR ranges, security groups and Cloud Firewalls, elastic and floating IPs, NAT gateways, and load balancers on AWS, Hetzner, and Vultr.
Every server you create in the cloud lands on a network the provider built for you, with an address, a route to the internet, and a set of rules about who can reach it. Most of the time you never look at that network until something cannot connect. This guide explains the pieces that matter on every provider: private networks and VPCs, subnets and address ranges, firewalls and security groups, public and floating IP addresses, and the gateways that join them. It names the equivalents on AWS, Hetzner, Vultr, and the other developer clouds so you can find them in the console.
Private networks and VPCs
A virtual private cloud, or VPC, is an isolated network inside the provider’s data center. Servers in the same VPC can talk to each other over private addresses that are not reachable from the internet, and traffic between them does not leave the provider’s backbone. On AWS a VPC is a first-class resource with its own address range, route tables, and gateways, and every EC2 instance must be launched into one. Google Cloud VPC networks are global and span regions, while Azure Virtual Networks are regional like AWS.
The developer clouds offer a simpler version of the same idea. Hetzner Cloud Networks let you attach servers in a project to a private range and add routes to subnets. Vultr VPC 2.0 gives each location a private network that servers join at creation or later. DigitalOcean VPC networks are per region and enabled by default for new Droplets. Linode VPCs and UpCloud SDN private networks fill the same role. In all cases the private interface carries a second address, usually from a 10.0.0.0/8 or similar RFC 1918 range, alongside the public one.
Use the private network for anything that should not be public: database connections, cache traffic, internal APIs, and backups between servers. It is faster, usually free of transfer charges, and removes a whole class of exposure.
Subnets, CIDR ranges, and availability zones
A VPC is carved into subnets, each a smaller address block written in CIDR notation such as 10.0.1.0/24. On AWS a subnet lives in exactly one availability zone, and the split between public subnets, which have a route to the internet gateway, and private subnets, which do not, is the foundation of most AWS network designs. Servers in a private subnet reach the internet for updates through a NAT gateway, which has its own hourly and per-gigabyte charge.
Plan address ranges before you create anything. Ranges cannot overlap if you ever want to connect two networks with peering or a VPN, and resizing a subnet after servers are in it is painful on every provider. A /16 for the VPC and /24 subnets per zone or role is a common and safe starting layout for a small deployment. Hetzner and Vultr let you define the range when you create the network; pick something that does not clash with your office or home network if you plan to connect through WireGuard later.
- VPC or network
- The isolated private network holding your servers
- Subnet
- A CIDR block inside the VPC, often tied to one zone
- Route table
- Rules that say where traffic for each destination goes
- Internet gateway
- The path from a public subnet to the internet
- NAT gateway
- Outbound-only internet access for private subnets
Firewalls and security groups
Provider firewalls filter traffic before it reaches the server’s network interface, which means a misconfigured host firewall inside the operating system does not expose you if the provider rule is right. AWS uses security groups, which are stateful allow lists attached to instances, plus network ACLs, which are stateless rules attached to subnets. Hetzner Cloud Firewalls, Vultr Firewall groups, DigitalOcean Cloud Firewalls, and Linode Cloud Firewalls all attach a rule set to one or more servers and default to denying inbound traffic that is not listed.
Write inbound rules by port and source. Allow SSH on port 22 from your own address or a bastion host only, allow 80 and 443 from anywhere for a web server, and allow database ports only from the private network range. Leave outbound open unless you have a reason to restrict it, and remember that a rule allowing 0.0.0.0/0 on a database port is the single most common cause of a compromised cloud server.
Public, elastic, and floating IP addresses
A server’s default public address is usually tied to that server and released when it is deleted. Providers therefore offer an address you own independently and can move between servers. AWS calls it an Elastic IP. Hetzner calls it a Floating IP, and Hetzner also offers Primary IPs that can be detached and reused. Vultr and DigitalOcean call it a Reserved IP, and Linode uses IP sharing and transfer for the same purpose.
The value is continuity. Point DNS at the floating address, and when you rebuild or replace the server behind it, the address moves and the DNS record does not change. This is the simplest form of failover: two servers, one floating IP, and a script or health check that reassigns the address when the active server stops responding. It is also how you avoid waiting for DNS caches to expire during a migration.
Floating and elastic addresses are typically billed whether or not they are attached, and some providers charge for the address itself even while in use. Release addresses you no longer need when you inventory an account. IPv6 is a separate consideration: most providers assign a /64 block to each server at no cost, and enabling it on the firewall and in the application is worth doing early.
| Concept | AWS | Hetzner | Vultr | DigitalOcean |
|---|---|---|---|---|
| Private network | VPC | Cloud Network | VPC 2.0 | VPC |
| Firewall | Security group, network ACL | Cloud Firewall | Firewall group | Cloud Firewall |
| Movable public IP | Elastic IP | Floating IP, Primary IP | Reserved IP | Reserved IP |
| Load balancer | ALB, NLB | Load Balancer | Load Balancer | Load Balancer |
| Outbound for private subnets | NAT gateway | Route via a NAT server | Public interface | Public interface |
Load balancers, DNS, and the edge
Once you have more than one server for a role, a load balancer takes the public address and spreads connections across the private addresses behind it. AWS offers Application Load Balancers for HTTP and Network Load Balancers for TCP. Hetzner, Vultr, DigitalOcean, and Linode each sell a managed load balancer that terminates TLS, runs health checks, and targets servers by label or private IP. Put servers behind the balancer on the private network and close their public ports entirely; the balancer becomes the only public entry point.
DNS is the last piece. Point records at the load balancer or floating IP, keep TTLs short during changes, and manage the zone either in the provider’s DNS service (Route 53, Hetzner DNS, Vultr DNS, DigitalOcean DNS) or a separate registrar. Managing DNS inside the same account you are handing over is convenient but creates one more thing to review during a transfer.
Where to go next
Accounts on the providers named in this guide are listed on the Buy Hetzner Accounts page, the Buy Vultr Account page, and the Buy AWS Accounts page. Server and vCPU labels on those listings restate the account’s limits; the network features described here are standard on each platform.
Related reading in the Cloud Library:
- Securing a VPS: firewalls, Fail2ban, and automatic updates
- Cloud regions and availability zones: how to choose a location
- Deploying your first cloud server: a practical checklist
Browse every guide in the Cloud Library, or compare two of these providers on the Hetzner vs DigitalOcean page.