Imagine you're building a SaaS platform.
Nothing unusual.
A web application.
A PostgreSQL database.
A Redis cache.
Everything runs in the cloud.
The architecture looks something like this:
Users
↓
Application Server
↓
PostgreSQL
Simple.
A user sends a request.
The application queries the database.
The database responds.
The application returns data.
Feature shipped.
Customers happy.
Everyone moves on.
For a while.
The Question Nobody Asks
Most engineers focus on:
Application Logic
or
Database Queries
or
API Design
But infrastructure engineers eventually ask a different question:
How does the application server actually reach the database server?
Not conceptually.
Literally.
How does one machine know where another machine is?
How does a packet travel from one server to another?
And perhaps the most surprising question:
If both servers live in the cloud, why doesn't their communication go through the Internet?
The Common Misconception
Many people imagine cloud infrastructure like this:
Application Server
↓
Internet
↓
Database Server
It seems reasonable.
After all, both servers exist somewhere inside AWS, Azure, or Google Cloud.
Surely the traffic goes through the Internet.
Right?
Actually, no.
In most production systems, internal communication never touches the public Internet.
Instead, it looks like this:
Application Server
↓
Private Network
↓
Database Server
No public Internet.
No ISP.
No external routers.
No public IP addresses.
Just private infrastructure.
This distinction matters because it changes everything about:
- Security
- Performance
- Reliability
- Cost
- Scalability
To understand why, we need to start with the first building block.
The VPC.
The Cloud Is A Giant City
Imagine AWS as a massive country.
Inside that country:
Netflix
Airbnb
Stripe
Shopify
Your Startup
Thousands of Others
All of them are running servers.
All of them are storing data.
All of them are deploying applications.
Now imagine there were no boundaries.
No isolation.
No separation.
Every server could see every other server.
That would be a security nightmare.
Cloud providers solve this problem using something called a:
Virtual Private Cloud
(VPC)
Think of a VPC as:
Your own private city
inside a giant country.
The cloud provider owns the country.
You own the city.
Inside that city:
- Your servers can communicate
- Your databases can communicate
- Your caches can communicate
- Other companies cannot access them
The first thing cloud infrastructure gives you is not a server.
It's a private network.
Why Infrastructure Starts With A Network
New engineers often think infrastructure begins here:
EC2 Instance
Virtual Machine
Server
It doesn't.
Infrastructure usually begins here:
VPC
Because servers without networks are useless.
Imagine buying a house.
But there are:
No roads
No addresses
No transportation
The house exists.
But nobody can reach it.
Servers have the same problem.
Before machines can communicate, they need a network.
The VPC creates that network.
The Next Problem
Suppose your company grows.
Now you have:
Application Servers
Database Servers
Redis
Background Workers
Message Queues
Monitoring Systems
Admin Tools
Everything lives inside one VPC.
At first this sounds convenient.
Until security enters the conversation.
Should a database be reachable from everywhere?
Probably not.
Should every server have Internet access?
Probably not.
Should internal systems be exposed publicly?
Definitely not.
This is where subnets appear.
Subnets Are Neighborhoods
If a VPC is a city:
VPC = City
Then:
Subnet = Neighborhood
A company might create:
VPC
│
├── Public Subnet
│
├── Application Subnet
│
└── Database Subnet
Each subnet serves a purpose.
For example:
Public Subnet
Load Balancer
Private Application Subnet
App Server 1
App Server 2
App Server 3
Private Database Subnet
PostgreSQL
Redis
Notice something important.
The database sits deeper inside the infrastructure.
Further away from the Internet.
This is intentional.
Because good infrastructure is built around reducing exposure.
The Database Doesn't Need The Internet
Many founders are surprised by this.
A database usually doesn't need users.
A database needs applications.
That's a completely different requirement.
Consider:
Customer
↓
Application
↓
Database
The customer never talks directly to PostgreSQL.
Only the application does.
So exposing the database publicly creates risk without creating value.
This is why production databases often live in private subnets.
The database can still be reached.
But only by trusted systems.
Every Server Gets A Private Address
Now imagine an application server wants to reach PostgreSQL.
How does it find the database?
The same way you find a building.
Addresses.
Every server receives an IP address.
Example:
Application
10.0.1.10
Database
10.0.2.20
These are private IP addresses.
Not public ones.
Nobody on the Internet can reach them.
But machines inside the VPC can.
Now the application knows:
Database
10.0.2.20
Problem solved?
Not quite.
Knowing an address isn't enough.
Knowing The Address Doesn't Create A Path
Imagine someone gives you:
221B Baker Street
Great.
You know the destination.
But how do you get there?
You need roads.
Networks have the same problem.
An IP address tells you:
Where
But not:
How
That responsibility belongs to routing.
Routing Is The GPS Of The Cloud
Every network contains routing rules.
These rules answer one question:
Where should this packet go next?
A route table might contain:
Destination Target
10.0.0.0/16 Local
Meaning:
Any traffic
inside this VPC
stays inside this VPC
Now imagine:
Application
10.0.1.10
sending a request to:
Database
10.0.2.20
The network checks the routing table.
Destination?
10.0.2.20
Result:
Inside VPC
Therefore:
Deliver Locally
The packet never leaves the cloud network.
The Internet is never involved.
The communication happens entirely inside private infrastructure.
The Request's Actual Journey
When the application queries PostgreSQL:
SELECT * FROM users;
What really happens is:
Application
↓
Private IP
↓
Route Table
↓
Database Subnet
↓
Database Server
No Internet.
No DNS lookup to the public Internet.
No external networking providers.
Just internal routing.
This is why internal communication is usually:
- Faster
- More secure
- More predictable
- Less exposed to external failures
Why This Matters To Founders
At first glance this sounds like technical trivia.
It's not.
Because infrastructure decisions directly affect business outcomes.
Imagine two architectures.
Architecture A
Application
↓
Internet
↓
Database
Architecture B
Application
↓
Private Network
↓
Database
The second architecture provides:
- Better security
- Lower attack surface
- Lower latency
- Fewer compliance concerns
- Better scalability
The customer never notices.
But the company benefits every day.
This is one of the reasons mature SaaS platforms invest heavily in infrastructure design.
Not because customers ask for VPCs.
Because customers expect reliability.
The Most Important Lesson
When most people think about cloud infrastructure, they think about servers.
Experienced engineers think about networks.
Because before applications communicate:
Networks must exist.
Before databases respond:
Routes must exist.
Before systems scale:
Infrastructure boundaries must exist.
The Internet is only one network.
Most production systems spend far more time communicating inside private networks than across the public Internet.
And understanding that idea is the first step toward understanding modern cloud infrastructure.
Frequently Asked Questions
What is a VPC?
A Virtual Private Cloud (VPC) is an isolated private network inside a cloud provider where your infrastructure resources can communicate securely.
What is a subnet?
A subnet is a smaller network segment inside a VPC used to organize and isolate infrastructure resources.
Why do servers use private IP addresses?
Private IP addresses allow internal communication without exposing systems directly to the public Internet.
Does traffic between servers always go through the Internet?
No.
In most cloud architectures, communication between internal services stays inside the provider's private network.
What is a route table?
A route table contains rules that determine where network traffic should be sent.
Why are databases usually placed in private subnets?
Because databases typically only need to communicate with application servers, not with public users.
Key Takeaways
- Most production server-to-server communication never touches the public Internet.
- A VPC creates an isolated private network inside the cloud.
- Subnets divide a network into smaller security and operational boundaries.
- Servers communicate using private IP addresses.
- Route tables determine how packets travel through the network.
- Security starts with network design, not application code.
- Cloud infrastructure is fundamentally a networking problem before it becomes a server problem.
- Understanding VPCs, subnets, private IPs, and routes is the foundation of modern cloud architecture.
If you found this article useful, share it with fellow software engineers, founders, backend developers, cloud engineers, and infrastructure enthusiasts exploring how modern systems communicate behind the scenes.
About the Author
Anik Sikder is a Software Engineer specializing in Backend Systems, SaaS Architecture, Cloud Infrastructure, Python, Django, FastAPI, distributed systems, and scalable software engineering.
He writes about system design, networking, distributed systems, cloud computing, software architecture, infrastructure engineering, and modern production systems.
