VPCs and Private Networking Explained

# VPCs and Private Networking Explained

When you create resources in the cloud, they live inside a network. By default, leaving everything on the public internet is both insecure and unscalable. A Virtual Private Cloud (VPC) is your own logically isolated network within the cloud provider — your private slice where you control addressing, routing, and access. Understanding it is foundational to building secure systems.

What a VPC gives you

A VPC is a software-defined network scoped to your account and region. Inside it you get:

• A private IP address range (CIDR block), e.g. 10.0.0.0/16
• Subnets that partition that range
• Route tables that control where traffic goes
• Gateways that connect (or don't) to the internet
• Firewalls (security groups / network ACLs) controlling what's allowed

The whole point: you decide what's reachable from where. Your database should *not* be reachable from the public internet — a VPC is how you enforce that.

CIDR blocks and IP addressing

VPCs use private IP ranges defined by [RFC 1918](https://www.rfc-editor.org/rfc/rfc1918):

10.0.0.0/8        (10.0.0.0   – 10.255.255.255)
172.16.0.0/12     (172.16.0.0 – 172.31.255.255)
192.168.0.0/16    (192.168.0.0– 192.168.255.255)

The /16 notation is CIDR — the number says how many leading bits are fixed. 10.0.0.0/16 gives you 65,536 addresses. Plan your range with room to grow and *avoid overlaps* with networks you might later peer with — overlapping CIDRs make peering impossible.

Public vs private subnets

The central design pattern is splitting your VPC into tiers:

VPC 10.0.0.0/16
├── Public subnet  10.0.1.0/24   → load balancers, bastion
│      (route to Internet Gateway)
└── Private subnet 10.0.2.0/24   → app servers, databases
       (no direct internet route)

• A public subnet has a route to an Internet Gateway, so resources there can be reached from / reach the internet (your load balancer lives here).
• A private subnet has *no* direct internet route. Databases and app servers live here, unreachable from outside.

This is the load-balancer-in-front pattern: only the LB is exposed; it forwards to app servers in private subnets, which talk to databases in private subnets. An attacker on the internet can't even *address* your database.

NAT: outbound without inbound

But private resources often need *outbound* access — to pull packages, call third-party APIs, fetch updates — without being reachable *inbound*. That's a NAT Gateway: it sits in a public subnet and lets private resources initiate outbound connections while blocking unsolicited inbound traffic.

Private app  →  NAT Gateway (public subnet)  →  Internet
       (outbound OK; inbound blocked)

Note NAT gateways cost money and data-process charges, which surprises people; route only what needs internet through them.

Security groups vs network ACLs

Two firewall layers, often confused:

Security groups are the workhorse — stateful, attached to resources, allow-only. A common pattern: the database security group allows inbound 5432 *only from the app security group*, not from any IP. This is far better than IP whitelisting:

DB SG inbound: allow TCP 5432 from source = App-SG

Network ACLs are a coarser, stateless backstop at the subnet boundary. Most teams rely mainly on security groups and leave ACLs permissive.

Connecting VPCs and on-prem

Real systems span boundaries:

• VPC Peering — connect two VPCs privately (non-overlapping CIDRs required).
• Transit Gateway — hub-and-spoke connectivity for many VPCs.
• VPN / Direct Connect — link your VPC to on-premises networks.
• PrivateLink / private endpoints — reach a cloud service privately without traversing the internet.

The theme throughout: keep traffic on private paths whenever possible. Database traffic, internal service calls, and admin access should never ride the public internet if you can avoid it.

Design principles

• Least exposure. Only load balancers and bastions get public IPs. Everything else is private.
• Defense in depth. Subnet isolation + security groups + (optionally) ACLs layered together.
• Reference security groups, not IPs. Allow "the app tier," not "this IP," so it survives instance churn.
• Plan CIDRs up front to avoid painful re-addressing and peering conflicts later.
• Use VPC flow logs to audit and debug what's actually talking to what.

A worked example

A classic three-tier web app:

1. 1Internet → Internet Gateway → Public subnet with the load balancer.
2. 2Load balancer → App servers in a private subnet (security group allows traffic only from the LB).
3. 3App servers → Database in a private subnet (security group allows 5432 only from the app SG).
4. 4App servers → NAT Gateway for outbound API calls and package fetches.

Nothing but the load balancer is reachable from outside, yet everything that needs outbound access has it.

Networking on PandaStack

PandaStack runs on multi-region GKE with Kong ingress and Cloudflare DNS, applying exactly these principles for you. Your apps sit behind the ingress (the public front door) while managed databases (via KubeBlocks) stay on the private side — not exposed to the public internet — with firewall rules and DDoS protection at the edge and automatic SSL on your custom domains. You get the isolated-private-tier-behind-a-public-LB architecture without designing subnets, route tables, and NAT gateways by hand.

References

• [AWS — What is a VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
• [RFC 1918 — Private address allocation](https://www.rfc-editor.org/rfc/rfc1918)
• [Google Cloud — VPC overview](https://cloud.google.com/vpc/docs/vpc)
• [AWS — Security groups vs network ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/infrastructure-security.html)
• [Cloudflare — what is a VPC](https://www.cloudflare.com/learning/cloud/what-is-a-virtual-private-cloud/)

Want databases that stay off the public internet without designing a VPC yourself? PandaStack's free tier handles the networking. [Start at dashboard.pandastack.io](https://dashboard.pandastack.io).