What Is Amazon VPC? Cloud Networking in Plain English

Amazon VPC — Virtual Private Cloud — is your own private network inside AWS: the fenced-off patch of the cloud where your servers, databases, and everything else you build actually lives. Every EC2 instance you have ever launched was standing inside a VPC, whether you noticed or not. And that is the first surprise: you already have one. Every AWS account ships with a working, internet-connected default VPC in every region, free, and genuinely fine for learning and small projects. The second surprise is the expensive one: the "proper" custom network most tutorials walk you into contains the single most common surprise charge in AWS networking — the NAT Gateway, a component that bills about $32 a month per gateway, plus data, from the moment it exists, even if nothing ever uses it. This post is stop 13 of our learn-AWS-free series: what a VPC actually is, what the default one already gives you, which pieces are free, and exactly where the meter hides.

Jake learned the price of "doing it properly" on his shop's inventory app. A tutorial had told him, in bold letters, never to use the default VPC for anything real — so he rebuilt the tutorial's diagram faithfully: a custom VPC, public and private subnets across two availability zones, and a NAT Gateway in each zone so the private half could download updates. The app worked beautifully. It had six users, all family. Then the first full month's bill arrived: about $68 of it was network — two NAT Gateways at ~$32.85 each, metering away around the clock — while the compute actually running his app cost less than $4. Nothing was misconfigured, nothing was hacked, and almost nothing was used. The gateways bill for existing, not for working. He deleted them, moved the app to a public subnet locked down with security groups, added a free S3 gateway endpoint, and the next bill was under $5. The tutorial wasn't wrong for a company; it was wrong for Jake.

Ethan: "It's a gated housing colony. The VPC is the compound wall — your plot of land with your own street plan. Subnets are the streets inside. The internet gateway is the main gate, and it's free, because a gate is just an opening. The security group is each house's own door lock. And the NAT Gateway? That's the colony's private courier — the fellow houses on the inner streets send out to fetch things, because those houses never open onto the main gate. Here's the thing about the courier: he's salaried. Thirty-two dollars a month whether anybody sends him shopping or not. Most beginners hire him because the brochure showed him standing there. Fire the courier until the inner streets actually need him."

What a VPC actually is (and what the P really means)

In the EC2 post we established that a cloud "computer" is a slice of a machine you can't point at. A VPC is the same trick applied to a network: there is no cable, no router in a cupboard, no switch with blinking lights that is yours. A VPC is a set of rules — an IP address range you claim, subnets you draw, route tables that say where traffic may flow — enforced in software across AWS's real network, which you share with millions of other customers. The "Private" in the name is logical, not physical: your packets travel the same fibers as everyone else's, but the rules make your network unreachable from theirs, and theirs from yours. That isolation is genuinely strong — it is the same mechanism AWS itself banks on — but it is worth saying plainly, because "private cloud" sounds like hardware and it is actually arithmetic.

Why should a beginner care about networking at all? Because it answers the two questions every first project eventually asks: "why can't I reach my server?" and "why could the whole internet reach my database?" Both answers live in the VPC. Everything you place in AWS — an EC2 instance, an RDS database, most serious architectures — sits in a subnet of some VPC, and the VPC's rules decide who can knock on its door.

One confusion to clear before it costs you a search rabbit hole: a VPC is not a VPS. A VPS — virtual private server — is a rented computer; on AWS that role is played by EC2, or by Lightsail, AWS's fixed-price beginner bundle. A VPC is the network those computers stand in. One letter apart, completely different products — and yes, your Lightsail or EC2 machine is standing inside a VPC right now.

The network you already own: the default VPC

Open the VPC console in any region of a fresh AWS account and there it is: a VPC named default, with the address range 172.31.0.0/16, one subnet per availability zone, an internet gateway already attached, and a setting that hands every new instance a public IP automatically. It is the reason your very first EC2 instance "just worked" — AWS quietly placed it on this pre-built network. The default VPC is deliberately tuned for convenience: everything launched into it can reach the internet and (if its security group allows) be reached from it.

Tutorials love to sneer at the default VPC, and for a company running customer data, they have a point — you want private subnets and deliberate design. But for learning, weekend projects, and most things this series builds, the honest advice is the opposite of the sneer: the default VPC plus a strict security group is a perfectly respectable setup, and it costs exactly nothing extra. The security group — not the network diagram — is what actually stands between your instance and the internet's port scanners. A beautiful three-tier VPC with a sloppy security group is less safe than the default VPC with a tight one. Deleted yours years ago? The console can recreate a default VPC in one click; nothing is lost forever.

Your slice of addresses: CIDR without tears

A VPC begins with a block of private IP addresses written in CIDR notation — the /16 in 10.0.0.0/16. The number after the slash just says how big the block is, and it runs backwards: the bigger the number, the smaller the block. A /16 is 65,536 addresses — the largest a VPC allows — and a /28, the smallest, is 16. You then carve the VPC's block into subnets, each a smaller CIDR inside it, each living in exactly one availability zone. Two things nobody tells you until they bite: the addresses are private ranges (10.x, 172.16–31.x, 192.168.x — the same families your home router uses), so they can repeat across VPCs; and AWS reserves five addresses in every subnet — the first four and the last one — for its own plumbing. That "16-address" subnet actually hands you eleven. Plan a little generously: a VPC's main CIDR cannot be shrunk later, and re-plumbing a cramped network is genuine misery. For anything small, 10.0.0.0/16 for the VPC and /24 subnets (251 usable each) is the boring, correct answer.

Public vs private subnets: "public" is a route, not a checkbox

Here is the concept that unlocks the whole console. There is no "make this subnet public" switch anywhere in AWS. A subnet is public because of one line in its route table: a route that says "traffic bound for the internet (0.0.0.0/0), go to the internet gateway." A subnet whose route table has no such line is private — its machines simply have no road to the outside, no matter what IPs or security groups they have. That's the entire distinction. The internet gateway itself is the free, maintenance-free doorway you attach to a VPC; it does nothing until a route points at it and an instance has a public IP. Three ingredients, all required, for a machine to be reachable from the internet: a public IP on the instance, a route to an internet gateway in its subnet's route table, and a security group that allows the traffic. When you "can't SSH in," one of those three is missing — in practice it is the security group first, the route second.

Why would anyone want a subnet with no road out? Because the best place for a database is a room with no exterior doors. The classic pattern puts the web server in a public subnet and the database in a private one: the internet can reach the web server (on exactly one port), the web server can reach the database across the hall, and no port scanner on earth can even ask the database a question. Private subnets are a genuinely great idea — right up until something inside one needs to download a security patch. Enter the courier.

The NAT Gateway: the salaried courier on your bill

A NAT Gateway lets machines in private subnets make outbound connections — download updates, call external APIs — while still refusing all inbound ones. One-way glass. It is also, by a wide margin, the most common "where did this charge come from?" line on beginner bills, for three compounding reasons: it bills hourly from creation (about $0.045/hour — roughly $32.85 a month in US regions as of this writing) whether any traffic flows or not; it adds $0.045 per GB processed on top; and it has no free tier at all. Multiply by the "one per availability zone" that production tutorials correctly recommend, and Jake's $68 idle month assembles itself. To be fair to the courier: for a real company, ~$33/month for managed, never-patched, auto-scaling outbound access is cheap. The trap is not the price — it is that tutorials install it into weekend projects that could have lived happily in a public subnet, or needed no internet at all.

If a tutorial already walked you into one, stopping the meter takes two minutes:

1. VPC console → NAT gateways. Check every region you have ever touched — the list is per-region, and forgotten regions are where gateways go to bill quietly.
2. Delete the gateway(s) your project does not actively need. Instances in private subnets lose outbound internet, nothing else; your data and instances are untouched.
3. Release the Elastic IP each gateway was holding (Elastic IPs page). An unattached public IPv4 keeps billing ~$3.65/month on its own until released.
4. If the private things only needed S3 or DynamoDB, add a gateway endpoint instead — a free private tunnel to those two services, no courier required.

Security groups vs NACLs: the door lock and the street barrier

Two different fences guard your machines, and beginners mix them up constantly. The security group is the one you will actually live with: it wraps each instance like a door lock, and it is stateful — if you let a request in, the reply is automatically allowed back out, no matching outbound rule needed. Its strangest property: security group rules can only allow. There is no deny rule, no block list — anything not explicitly allowed is silently refused, which is also why a brand-new instance ignores your SSH attempts until you add the rule. The network ACL guards the whole subnet like a barrier at the end of the street, is stateless (replies need their own explicit rule — the classic gotcha), and can deny, which makes it the right tool for exactly one common job: banning a specific abusive IP address. The honest guidance for almost everyone: do your real security in security groups, leave the default NACL alone (it allows everything and lets the security groups decide), and remember it exists for the day you need to ban someone at the street level.

What a VPC costs: the free list and the meter list

The VPC itself — the network, subnets, route tables, internet gateway, security groups, NACLs — costs nothing. You can design the most elaborate paper network in the world for free. The money hides in a handful of add-ons and in data movement, and one 2024 change moved a line onto everyone's bill: since February 2024, every public IPv4 address costs ~$0.005/hour (about $3.65/month) — including the one your running instance is using. (New accounts get 750 free IPv4-hours a month for the first 12 months; after that, it is real money that IPv4 scarcity put there.) US-region prices as of this writing:

Read the table once and the pattern appears: the network is free; crossing its edges is not. If a surprise charge does land, the billing post's budget alarms are how you hear about it in days instead of at month-end.

The free hands-on: read your default VPC like a floor plan

This series' rule: thirty seconds in the console beats thirty minutes of reading. Today's exercise costs nothing and creates nothing — it is purely a guided tour of the network you already own:

1. Open the VPC console (search "VPC" in the top bar) and click Your VPCs. Find the one marked default — note its CIDR, 172.31.0.0/16.
2. Click Subnets. Count them — one per availability zone in your region, each a /20 slice of the block, each in a different zone. That "one per zone" is your first taste of high-availability thinking.
3. Click Route tables, open the default VPC's table, and find the row 0.0.0.0/0 → igw-.... You are looking at the exact line that makes every default subnet public. Delete that one row (don't) and the whole VPC goes dark to the internet.
4. Click NAT gateways. The healthiest thing most readers will see here is an empty list — that emptiness is ~$33/month of not-courier. If it is not empty and you don't know why, the checklist in the NAT section above is yours.

When you actually need a custom VPC 

The decision, in words. Learning, experimenting, weekend project? Default VPC, tight security group, done — $0. Real users' data, or a database that must never face the internet? Build a custom VPC with public and private subnets — the design is still free, and drawing it yourself once will teach you more networking than any post can. Do the private machines need to reach out — OS updates, third-party APIs? Only now does the NAT Gateway earn its salary; budget it honestly (~$33/month, one per zone if uptime matters), check first whether a free S3/DynamoDB gateway endpoint covers the actual need, and delete it the day the need ends. A custom VPC also has ceilings worth knowing before you hit them: five VPCs per region by default (a quota bump away from more), the CIDR you pick is the CIDR you keep, and if two VPCs ever need to talk — yours and a friend's, staging and production — that is VPC peering, free within a region for the connection itself, a story for a later post.

And one boundary to keep your mental model clean: some services live in your VPC and some only visit. EC2 instances and RDS databases occupy your subnets and use your security groups. S3, DynamoDB, and SQS live outside in AWS's public service space — you reach them over the internet or through endpoints. Lambda runs outside by default and can be invited in when it needs to whisper to your private database. "Which side of my wall is this thing on?" is the question that untangles half of all VPC confusion.

FAQ — Amazon VPC in plain English

What is Amazon VPC in one sentence?

Your own private network inside AWS — an IP range you control, divided into subnets, with route tables and security rules deciding what can talk to what.

What is the full form of VPC?

Virtual Private Cloud. The meaning behind the name: a virtual (software-defined) network that behaves as if it were your private patch of the cloud, even though the hardware underneath is shared.

Is a VPC the same as a VPS?

No — one letter, different worlds. A VPS (virtual private server) is a rented computer; AWS sells that as EC2 or, in its simplest fixed-price form, Lightsail. A VPC is the network those computers live inside. If you were actually shopping for a cheap server, Lightsail is AWS's VPS answer.

Do I need to create a VPC before using AWS?

No. Every account has a default VPC in every region, internet-connected and ready. Your first EC2 instance already used it without asking you anything.

Is the default VPC safe enough to use?

For learning and small projects, yes — paired with a strict security group, which is what actually guards your instance. Production systems with sensitive data deserve a deliberate custom design with private subnets.

What makes a subnet "public"?

One route: 0.0.0.0/0 pointing at an internet gateway in the subnet's route table. There is no public/private switch — the route is the whole difference.

What is an internet gateway, and does it cost anything?

The doorway between your VPC and the internet — attached once per VPC, no maintenance, and completely free. It does nothing until a route points at it.

What is a NAT Gateway and why is everyone surprised by its bill?

It gives private subnets outbound-only internet access — and bills ~$0.045/hour (~$32.85/month) plus $0.045/GB from the moment it is created, traffic or not, with no free tier. It is the most common surprise charge in AWS networking.

How do I stop NAT Gateway charges?

Delete the gateway in every region you have used, then release its Elastic IP separately — an unattached public IPv4 keeps billing ~$3.65/month on its own. If the private machines only needed S3 or DynamoDB, a free gateway endpoint replaces the NAT entirely.

What is the difference between a security group and a network ACL?

Security group: per-instance, stateful, allow-only — your everyday tool. NACL: per-subnet, stateless, can deny — the street barrier you mostly leave at its permissive default.

Can I block a specific IP address with a security group?

No — security groups have no deny rules; they can only allow. Blocking a specific address is the network ACL's job: add a numbered deny rule on the subnet.

How much does a VPC cost?

The VPC, subnets, route tables, internet gateway, security groups, and NACLs are free. Money enters with NAT Gateways, public IPv4 addresses (~$3.65/month each), interface endpoints, and data leaving or crossing zones.

Why is AWS charging me for a public IPv4 address?

Since February 2024, every public IPv4 costs ~$0.005/hour — in use or not — because the world has run short of IPv4 addresses. New accounts get 750 free hours a month for the first year.

How many IP addresses do I actually get in a subnet?

The CIDR size minus five: AWS reserves the first four and the last address of every subnet for itself. A /24 gives 251 usable, a /28 just 11.

Is my VPC physically separate from other AWS customers?

No — the separation is logical, enforced in software on shared hardware and fibers. It is strong isolation (AWS itself depends on it), but it is rules, not private cables.

Can two VPCs talk to each other?

Yes — VPC peering connects two VPCs privately (their CIDRs must not overlap; same-region peering data is even free). Larger setups graduate to Transit Gateway, which is real money.

Do RDS and Lambda run inside my VPC?

RDS: yes — your database occupies your private subnets and security groups. Lambda: outside by default, and you connect it into your VPC only when it must reach private things like that database.

What comes after VPC in this series?

The graduation post: your first real AWS project, end to end — S3, Lambda, API Gateway, and DynamoDB from this series wired into one small thing that actually runs. Promised here, linked from the hub the day it lands.

Where to go next

A note on prices and promises. Written August 24, 2026; the numbers here — NAT Gateway at ~$0.045/hour + $0.045/GB, public IPv4 at ~$0.005/hour, the 100 GB monthly egress allowance, the five reserved addresses per subnet — were checked against AWS's own pricing pages on that date for US regions; other regions drift a little higher. This is stop 13 of the learn-AWS-free series: the series hub promised the network post, and here it is. The next promise is the fun one: your first real AWS project, end to end — the services from these thirteen stops wired into one small thing that actually runs. If a NAT Gateway ever billed you for a month of doing nothing, you were never careless — you were following the same tutorial as everyone else; Jake's $68 month is in this post so yours can stay under $5. Tell me what the network did to you through the contact page — the best stories in this series arrived that way.