Cloud Networking Basics: VPCs, Subnets, Firewalls and Load Balancers

Cloud networking basics come down to a handful of building blocks: a private network (the VPC), the subnets inside it, the routes that decide where traffic goes, the firewalls that decide what is allowed, and the load balancers that spread requests across servers. Every major provider uses the same ideas under slightly different names. This guide builds a typical network step by step, so each piece has a clear job.

The mental model: follow a request #

Picture a user loading your web app. Their request arrives at a public load balancer, which forwards it to one of several application servers in private subnets. Those servers query a database in another private subnet, and when they need to download updates, they reach the internet through a NAT gateway. At every hop, a firewall rule decides whether the traffic is allowed.

Keep that path in mind as you read. Each section below adds one component to it.

Step 1: the VPC and its address range #

A Virtual Private Cloud (VPC) is an isolated network inside the provider’s infrastructure that belongs to your account. Nothing reaches resources in it unless you create a path. Azure calls it a virtual network (VNet), and Alibaba Cloud and most developer clouds use VPC.

When you create a VPC you assign it an IP address range in CIDR notation. Use private address space defined in RFC 1918: 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. The number after the slash is the prefix length; a smaller number means a bigger network. A /16 provides 65,536 addresses and a /24 provides 256.

Plan the range before you need it

The most common networking regret is an address range that overlaps with something else. If your VPC uses 10.0.0.0/16 and your office network, a partner’s network or a second VPC also uses it, you cannot connect them cleanly later with peering or a VPN. Keep a simple register of which ranges each environment uses, and give production, staging and development distinct, non-overlapping blocks.

Step 2: subnets, public and private #

A subnet is a slice of the VPC’s range, for example 10.0.1.0/24. Subnets let you group resources by role and apply different routing and security to each group.

The terms “public” and “private” describe routing, not a checkbox:

• A public subnet has a route to an internet gateway, so resources with public IP addresses in it can be reached from the internet.
• A private subnet has no direct route from the internet. Resources in it can only be reached from inside the network, or through a load balancer or bastion.

A standard layout has public subnets for load balancers and NAT gateways only, private subnets for application servers, and separate private subnets for databases. Spread each tier across at least two availability zones so that losing one data center does not take down the whole application.

Provider differences worth knowing

On AWS, a VPC spans a region and each subnet sits in one availability zone. On Google Cloud, a VPC network is global and each subnet belongs to one region. On Azure, a VNet is regional and its subnets can span zones. Providers also reserve a few addresses in every subnet (AWS and Azure reserve five, for example), so a /28 gives you fewer usable addresses than the math suggests.

Step 3: routing #

Each subnet is associated with a route table, a list of destination ranges and where to send matching traffic. Every route table includes a local route so resources within the VPC can talk to each other. You add routes for everything else:

• Internet gateway: a route for 0.0.0.0/0 pointing at the internet gateway makes a subnet public.
• NAT gateway: a route for 0.0.0.0/0 pointing at a NAT gateway lets private resources make outbound connections (to download packages or call external APIs) without accepting inbound ones.
• Peering, VPN or interconnect: routes for other networks’ ranges point at the relevant connection.

Step 4: firewalls #

Cloud firewalls come in two broad kinds, and the difference between them explains many confusing connectivity problems.

Stateful firewalls attached to resources

AWS security groups, Azure network security groups, Google Cloud VPC firewall rules and the cloud firewalls of most developer clouds are stateful. If you allow an inbound connection, the reply traffic is allowed automatically. You write rules for the direction the connection starts in, and that is it.

Good practice is to reference other groups or tags instead of IP addresses where possible. For example: the database group allows port 5432 only from the application group, and the application group allows port 8080 only from the load balancer group. The rules then stay correct as servers come and go.

Stateless network ACLs

AWS also offers network ACLs at the subnet level. These are stateless: return traffic must be allowed explicitly, including the ephemeral port range clients use for replies. They are useful as a coarse extra layer, for example to block a range across a whole subnet, but most teams do their day-to-day filtering with security groups.

Rules that prevent most incidents

1. Never open SSH (22) or RDP (3389) to 0.0.0.0/0. Restrict it to known addresses, or use the provider’s session manager or a bastion.
2. Never expose database ports to the internet. Databases belong in private subnets.
3. Default to deny, and add allow rules with a comment explaining why each exists.
4. Review rules periodically and remove ones nobody can explain.

Network rules are one part of a wider security posture; our cloud account security checklist covers identity, MFA and audit logs, which matter just as much.

Step 5: load balancers #

A load balancer receives traffic on a single address and distributes it across healthy backend servers. It runs health checks, removes failing servers from rotation, and is usually where TLS certificates live.

On AWS these are the Network Load Balancer and Application Load Balancer. Azure has Azure Load Balancer for layer 4 and Application Gateway for layer 7, and Google Cloud Load Balancing offers both, including global HTTP(S) load balancing. Developer clouds such as DigitalOcean, Hetzner and Linode offer simpler managed load balancers that cover the common cases well.

Place the load balancer in public subnets and keep the backend servers private. The backends then only need a firewall rule allowing traffic from the load balancer.

Step 6: connecting networks together #

As systems grow, networks need to reach each other:

• VPC peering connects two VPCs privately. On AWS, peering is not transitive: if A peers with B and B with C, A cannot reach C through B.
• Transit hubs such as AWS Transit Gateway or Azure Virtual WAN connect many networks through a central point.
• Site-to-site VPN links an office or data center to a VPC over an encrypted tunnel on the internet.
• Dedicated interconnects provide private physical links for high bandwidth or predictable latency.
• Private endpoints let resources reach provider services such as object storage without traversing the public internet.

The reference layout, assembled #

1. One VPC per environment with a planned, non-overlapping CIDR range.
2. Public subnets in two zones containing only the load balancer and NAT gateways.
3. Private application subnets in two zones, routing outbound traffic through NAT.
4. Private database subnets in two zones, with no internet route at all.
5. Stateful firewall rules chained by role: internet to load balancer, load balancer to app, app to database.
6. Administrative access through a managed session service, a VPN or a tightly restricted bastion.
7. Flow logs enabled so you can investigate unexpected traffic later.

The same design translates directly to other providers. Our Alibaba Cloud fundamentals guide shows how it maps onto VPCs and vSwitches, and the Hetzner Cloud setup guide applies it on a smaller, simpler platform. For provider summaries, see our AWS platform overview and Google Cloud platform overview.

For exact limits, reserved addresses and service names, rely on the official references: the AWS documentation, the Google Cloud documentation and Microsoft Learn for Azure.

Cloud networking: frequently asked questions #

What is the difference between a VPC and a subnet?

A VPC is your whole private network with its overall IP address range. Subnets are smaller ranges inside it, used to group resources by role and zone and to apply different routing and firewall rules to each group.

What makes a subnet public or private?

Routing. A public subnet has a route to an internet gateway, so resources with public IPs can be reached from the internet. A private subnet has no such route and uses a NAT gateway, if anything, for outbound access only.

Do I need a NAT gateway?

Only if resources in private subnets must start connections to the internet, for example to install updates or call external APIs. If they only talk to internal services or reach provider services through private endpoints, you may not need one.

Should I use security groups or network ACLs?

Use stateful security groups (or their equivalent) as your main control, because they are simpler and allow return traffic automatically. Add stateless network ACLs only when you need a coarse subnet-wide rule as an extra layer.