AWS Infrastructure in just 5-minutes

A simple, funny, and no-jargon guide to understanding AWS networking zones

When you start learning AWS, there’s this moment where you stare at the diagram, eyes half open, and ask yourself:
“Why does this look like a badly wired switchboard from the 90s?”

Then you hear about things like VPCs, public subnets, private IPs, Internet Gateways… and somewhere deep inside, your brain whispers:

“I miss the old days of using USB drives.”

But worry not, this article is here to explain how AWS separates your services into three main zones — public, private, and the good old Internet — using simple words and slightly irritated nerd logic.


First Things First: What does “Public” or “Private” even mean in AWS?

It does not mean:

  • Public = anyone can access it

  • Private = only you can use it

In AWS, public vs private is about network access — specifically, can this thing talk to the Internet or not? That’s it.

Now let’s meet the three zones.


1. “Internet” Zone – The Internet world

This is the Internet you already know — Gmail, YouTube, news, random websites.

  • If you're at home and you try to access something in AWS (like an S3 file), your request travels through this public zone first.

  • It uses the Internet as the “road” to reach AWS.

This zone doesn’t belong to AWS — it’s just the usual Internet.

Now most of you fellas confuse Internet being the Public Zone but that is not the case. Public Zone lies in between the Internet and Private Zone.


2. “AWS Public” Zone – AWS Stuff That’s Reachable from the Internet

This is where AWS keeps services that are meant to be accessed from the outside.
They’re not exposed to the whole world by default, but they can be, if configured that way.

  • Example: Amazon S3

    • You can upload files and access them using a public link (if permissions allow).

    • Even though it’s a public service, by default, no one else can access your files unless you say so. (Yes, AWS is strict like that.)

  • Example: EC2 instances with public IPs

    • If your EC2 server has a public IP, it lives in this public zone.

    • It connects to the Internet using something called an Internet Gateway (IGW).

    • IGW acts like the front door. Without it, your EC2 is like a shop with no entrance.

Note: Public here doesn’t mean insecure. It means accessible from the Internet, if allowed.


3. “AWS Private” Zone – The Secret Basement with No Windows

This is where AWS keeps services inside a VPC (Virtual Private Cloud). Think of a VPC like a fenced-off area with its own internal roads.

  • These services have no Internet access unless you explicitly allow it.

  • Example: EC2 instances without public IPs (living in private subnets)

  • These are great for internal stuff — like backend servers, databases, or anything that shouldn’t be exposed to the outside world.

How do they talk to the Internet then?

  • Use Internet Gateways or NAT Gateways.

VPC – The Boundary Wall of Your Cloud Neighborhood

Let’s talk a bit more about the VPC (Virtual Private Cloud) — the place where most of your AWS services live.

  • It’s your private network inside AWS.

  • It exists in a specific region (like us-east-1, ap-south-1, etc.).

  • You control everything here: IP ranges, subnets, firewalls, etc.

  • It’s isolated from other VPCs and AWS accounts unless you connect them manually.

There are two types:

  • Default VPC – Comes pre-configured with every AWS account. Has a fixed IP range: 172.31.0.0/16. Less flexible.

  • Custom VPC – You build it your way. Choose your own IPs, subnets, etc. This is what you’ll use in real-world projects.

Each region has Availability Zones (AZs), like ap-south-1a, 1b, 1c. These are separate data centers that are connected with high-speed links but are isolated from failures. You should spread your resources across AZs to stay safe if one goes down.


AWS Regions – The Global Real Estate

  • AWS has data centers all over the world.

  • Each region is a group of data centers, usually with 3 or more Availability Zones.

  • You pick a region based on:

    • Where your users are (less delay)

    • What laws apply (data privacy)

    • What services are available (not all services are everywhere)

    • Cost (prices vary by region)

Fun fact: Even though AWS is global, most services are region-specific. You mess up one region? Doesn’t affect others. Unless you’re using globally-scoped services like IAM or Route53 — those can haunt you everywhere.


Edge Locations – Because Speed Matters

Edge locations are like delivery boys waiting closer to your house.

  • Used by services like CloudFront (AWS CDN) to deliver content faster.

  • These are small, super-fast servers spread across the globe — 400+ of them.

  • They cache your content (images, videos, etc.) so users don’t have to load it from far-away regions.

That’s how you get to stream the movies on Netflix so fast.


How Strong Is Your Setup?

Let’s quickly look at resilience:

  • Global Resilience – Services like IAM or Route53. Rarely go down. If they do, it’s apocalypse time.

  • Region Resilience – Services like VPC. They stay up unless the whole region dies (which is rare).

  • AZ Resilience – Some services are only strong within a single AZ. If that zone has issues, you're in trouble unless you’ve spread things out.


Bonus: Default VPC Magic

Every AWS region gives you one default VPC:

  • IP range: 172.31.0.0/16

  • Each AZ gets a subnet with /20 range

  • Comes with:

    • Internet Gateway

    • Security Group (stateful firewall)

    • Network ACL (stateless firewall)

Any resource like our boy EC2 launched in default VPC gets a public IP by birth.

So even though it's called "private" by name, the default setup is pretty public-ready.


Once you get this mental model, everything else in AWS starts to make sense. Kind of.

There’s more articles that are interesting this related to AWS if you wanna learn but not yet part of this series:

A Deep Dive into AWS Load Balancers: CLB, ALB, NLB, and GWLB

The Sticky Mess of Load Balancer Stickiness

10
Subscribe to my newsletter

Read articles from Nitesh Chaturvedi directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Nitesh Chaturvedi
Nitesh Chaturvedi