Internet-Free Infrastructure: How Two Servers Talk Without Using the Internet

Tue, 25 Aug 2026 17:21:06 +0000

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

Database Queries

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.

Coder Legion - Recent posts tagged subnet