Picture your first week on the job. You launch a small server in the cloud, the console says it is running, and you try to connect to it. Nothing. The connection just hangs and times out. You double-check the password, restart the machine, and stare at the screen. The server is fine. What is missing is the plumbing around it: the network that decides whether anything is even allowed to find your machine. That plumbing is what we are unpacking today.

Here is the everyday picture. A VPC, which is short for Virtual Private Cloud, is like a gated housing society. The whole society sits behind one boundary wall and owns one block of street addresses. Inside, the society is divided into lanes, and each lane gets its own slice of those addresses. Those lanes are your subnets. The main gate that connects the society to the public road is the internet gateway. The guard standing at your individual front door, checking each visitor every single time, is the security group. And the watchman at the entrance to a whole lane, who waves people through by simple rules but never remembers a face, is the network ACL.

Hold that picture. Almost everything in cloud networking is a version of a gate, a lane, or a guard.

What a VPC actually is

A VPC is a private, isolated network that belongs only to you, running on top of the provider hardware. Other customers share the same physical machines and cables, but they cannot see inside your VPC and you cannot see into theirs. The boundary is enforced in software, which is why the word virtual sits in the name.

Every provider has this idea. AWS calls it a VPC. Google Cloud also calls it a VPC. Microsoft Azure calls it a Virtual Network, or VNet. The naming differs but the job is identical: give you a walled-off space where you place servers, databases and other resources, and where you control how traffic moves.

The CIDR block, in plain numbers

When you create a VPC, the first thing it asks for is a CIDR block, written like 10.0.0.0/16. CIDR is just a compact way to say how many addresses you want. The number after the slash tells you how many bits are locked as the network part. A smaller number means a bigger range. A /16 gives you about 65,000 addresses. A /24 gives you 256. A /28, the smallest a subnet can be on AWS, gives you 16.

Pick a private range, not a public one. The standard private ranges are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. That last one is why your home router hands out 192.168 addresses. Using a private range keeps your internal addresses from clashing with real internet addresses, and it gives you room to grow without renumbering everything later.

Subnets, and the public versus private split

A subnet is a slice of your VPC address block. You might split a /16 VPC into several /24 subnets, each holding 256 addresses. The reason to split at all is control. Different subnets can have different rules about what can reach the internet, and you can spread them across availability zones so a single data-center failure does not take everything down.

The words public and private describe behaviour, not a setting you tick. A subnet is public when its route table sends internet-bound traffic to an internet gateway. A subnet is private when it does not. That is the whole difference. Put your web servers in public subnets so users can reach them, and keep your databases in private subnets so they are never directly exposed.

Why a subnet lives in one zone on AWS

On AWS, each subnet sits inside exactly one availability zone. If you want your application to survive the loss of a zone, you create one subnet per zone and run copies of your servers in each. Azure handles this differently: a subnet there is regional and spans all the zones in the region, so the zone choice happens at the resource level instead. Google Cloud subnets are also regional. This is a real difference that trips people up when they move between providers, so it is worth knowing which model you are in before you design anything.

Gateways and routes: how traffic actually leaves

A route table is a short list of rules that says, for a given destination, send the traffic here. Every subnet is tied to one route table. The most important entry you will ever read looks like this: destination 0.0.0.0/0, target an internet gateway. That single line means anything not inside the VPC should go out to the open internet through the gateway. Remove it and the subnet goes dark to the outside world.

An internet gateway is the front door for two-way internet traffic. A server in a public subnet uses it to receive visitors and to reach out. But private subnets often still need to download updates or call an external API, without accepting any incoming connections. For that you use a NAT gateway, which lets traffic go out and come back, but never lets a stranger start a conversation. Think of NAT as a one-way turnstile: your people can leave and return, but outsiders cannot walk in.

Security groups versus network ACLs

Two firewalls guard your traffic, and freshers mix them up constantly. A security group wraps an individual resource, like a single server. It is stateful, which means if you allow a request in, the reply is automatically allowed back out. You only write allow rules; anything not allowed is denied. A network ACL guards a whole subnet. It is stateless, so it does not remember anything. If you allow traffic in, you must also write a separate rule to allow the response out, and it supports explicit deny rules too.

For day-to-day work you will live in security groups and rarely touch network ACLs. The default network ACL allows everything, which is usually fine, and most teams leave it that way and do their real control at the security-group level. Reach for network ACLs when you need a blunt, subnet-wide block, such as banning a range of addresses outright.

The same ideas across the three big providers

The concepts carry across AWS, Azure and Google Cloud almost one for one. Only the names and a few scoping rules change. Learn the model once and you can move between them.

One genuine design difference is worth keeping straight. A Google Cloud VPC is a global resource and its subnets are regional, so a single VPC can stretch across regions. An AWS VPC lives in one region. These are not better-or-worse facts, just different defaults you have to respect when you design.

One opinion: do not hand-build a VPC on day one

Plenty of tutorials tell beginners to build a custom multi-zone VPC from scratch immediately, complete with public and private subnets and a NAT gateway, as a rite of passage. I disagree for someone in their first weeks. Start in the default VPC that every account already has, and learn to read its route table and security groups first. Build the model in your head before you build the infrastructure with your hands.

There is also a money reason. A NAT gateway is billed by the hour from the moment it exists, on the order of a few cents per hour, which adds up to roughly 30 US dollars a month even if zero traffic flows through it. Freshers spin one up while following a guide, forget it, and get a surprise on the bill. Understand routing first, and add a NAT gateway only when you have a private subnet that genuinely needs outbound access. Check current pricing for your region before you commit, since rates vary.

FAQ

Is a subnet the same as a VLAN?
They are cousins, not twins. Both divide a network into smaller pieces, but a cloud subnet is defined by an IP address range inside your VPC, while a VLAN is a layer-2 segmentation technique from traditional networking. In the cloud you mostly think in subnets and route tables, and the provider handles the lower layers for you.

Can I change a VPC CIDR block after I create it?
You cannot shrink or replace the primary range, but you can add secondary CIDR blocks to a VPC if you run low on space. This is exactly why you should pick a roomy range like a /16 at the start. Resizing a live network is painful, so plan for growth up front.

Why does my brand-new instance have no internet access?
Usually one of three things: it is in a private subnet, its subnet route table has no path to an internet gateway, or it never received a public IP. Check those in order. The firewall rules are worth checking too, but they are rarely the first cause.

How many VPCs can I create?
AWS gives you a default soft limit of around five VPCs per region, and you can request an increase. The limit is generous for learning, and most small projects live happily inside a single VPC with several subnets.

Do I need to learn networking deeply to work in cloud?
You need the basics covered here, not a networking degree. CIDR, subnets, route tables, gateways and the two firewall types will carry you through your first year. You can go deeper on routing protocols and private connectivity later, when a real task pushes you there.

Cloud networking feels intimidating because the words arrive faster than the ideas. But strip away the names and it is a small set of moving parts: a private network, slices of addresses, a list of routes, and a couple of gateways and guards. Once you can sketch that on paper, the console stops being scary and starts being obvious. Open your free-tier account, find the default VPC, and trace one packet from a server to the internet and back. Do that once and Part 8 will feel like a natural next step.

References

• AWS: Subnet CIDR blocks and reserved addresses
• AWS: VPC CIDR blocks
• Microsoft Learn: Compare AWS and Azure networking

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts