“A private network” in the cloud context is one of three things: a VPC (Virtual Private Cloud) at the cloud provider, a service mesh (private networking between the team’s services on a managed platform), or a private connection (site-to-site VPN or Direct Connect between the team’s infrastructure and the cloud). Most blog posts and docs conflate the three, which is why the search results are confusing. The right answer depends on whether the team needs to isolate from the public internet, isolate between services, or isolate from the team’s office. Each one answers a different question, and the wrong one is a common source of over-engineering or under-engineering.
This post walks through the three meanings, the use cases, the right answer for a typical web app, and the cost reality that private networking is not free.
Table of contents
- The three meanings of “private network”
- The VPC: isolating from the public internet
- The service mesh: isolating between services
- The private connection: isolating from the team’s office
- The right answer for a typical web app
- The right answer for a regulated app
- The right answer for a hybrid app
- The cost reality
- FAQ
The three meanings of “private network”
The three meanings, in order of how often they come up:
- VPC (Virtual Private Cloud). A logically isolated section of the cloud provider’s network. The team launches resources (VMs, databases, load balancers) inside the VPC, the VPC has a CIDR block, the VPC has subnets, the VPC has routing tables. The resources are not reachable from the public internet unless the team explicitly exposes them.
- Service mesh (private networking between services). A platform feature (Render’s Private Network, Fly.io’s private network, Railway’s private networking) that allows the team’s services to talk to each other over a private network, not the public internet. The services have internal hostnames, the traffic does not leave the platform’s network.
- Private connection (site-to-site VPN, Direct Connect, ExpressRoute). A private connection between the team’s infrastructure (an office, a data center, an on-prem cluster) and the cloud. The connection is encrypted, the traffic does not go over the public internet.
The three are not interchangeable. The VPC is about isolation from the public internet. The service mesh is about isolation between services. The private connection is about isolation from the team’s office. Picking the wrong one is a common source of over-engineering (a team that needs a service mesh builds a VPC) or under-engineering (a team that needs a VPC uses a service mesh).
The VPC: isolating from the public internet
A VPC is the right answer when the team needs to run services that should not be reachable from the public internet. The use cases: a database that should not be exposed, an internal API that should not be exposed, a backend service that should not be exposed.
The standard pattern: the team’s resources are in the VPC, the resources have private IP addresses, the resources are not reachable from the public internet. The team’s frontend (or the team’s API gateway) is in a public subnet, the public subnet is reachable from the public internet, the public subnet routes to the private subnet through a load balancer or a NAT gateway.
The cost: a VPC is not free. The NAT gateway (the right answer for outbound internet from the VPC) is billed per hour and per GB. The load balancer (the right answer for inbound internet to the VPC) is billed per hour and per GB. The team’s VPC bill can be a meaningful line item on top of the resource costs.
The right answer for the team that needs a VPC: a managed Kubernetes cluster (EKS, GKE, AKS) inside a VPC, or a managed platform that provides a VPC abstraction (Render’s Private Network with VPC peering, Fly.io’s private network with VPC peering).
The service mesh: isolating between services
A service mesh is the right answer when the team needs the services on a managed platform to talk to each other privately. The use cases: a frontend talking to a backend API, a backend API talking to a database, a worker talking to a queue.
The standard pattern: the team’s services are on a managed platform, the platform provides a private network feature, the services have internal hostnames (api.internal, db.internal), the traffic between services stays on the platform’s private network. The public-facing services (the frontend, the API gateway) are on the public network, the internal services are on the private network.
The cost: a service mesh is usually included in the platform’s plan, or is a small add-on. The team’s bill for a service mesh is the platform’s plan plus a small monthly fee. The right answer for the team that needs a service mesh is a platform that provides one out of the box (Render, Fly.io, Railway, Vercel).
The right answer for the team that does not need a service mesh: a single-tenant deployment on a public network, with the team’s services talking to each other over the public network. The trade-off is the latency (a few milliseconds) and the security (the traffic is on the public network, but the traffic is encrypted with TLS).
The private connection: isolating from the team’s office
A private connection is the right answer when the team needs to connect the team’s on-prem infrastructure to the cloud. The use cases: an office network that needs to reach cloud resources, a legacy system that cannot be moved to the cloud, a hybrid architecture that spans on-prem and cloud.
The standard pattern: the team’s office has a VPN gateway, the cloud has a VPN gateway, the two gateways establish an encrypted tunnel, the traffic between the office and the cloud goes through the tunnel. The team that needs higher bandwidth and lower latency uses a dedicated connection (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect).
The cost: a site-to-site VPN is a few hundred dollars per month on each side. A dedicated connection is a few thousand dollars per month plus the cross-connect fees. The right answer for the team that needs a private connection is to start with the VPN and move to the dedicated connection when the bandwidth justifies the cost.
The right answer for the team that does not need a private connection: a public API with mutual TLS, or a public API with API keys. The trade-off is the latency (the traffic goes over the public internet) and the security (the traffic is encrypted with TLS, but the path is public).
The right answer for a typical web app
The right answer for a typical web app is the service mesh, on a managed platform. The pattern: the team’s frontend is on the public network (it’s a public website, after all), the team’s backend API and database are on the service mesh, the traffic between them is on the private network. The public-facing services are the only ones exposed to the public internet.
The standard implementation: a managed platform with a private network feature (Render, Fly.io, Railway, Vercel). The team provisions the platform, the platform provides the private network, the team deploys the services, the services use the internal hostnames to talk to each other.
The cost: the platform’s plan plus a small monthly fee for the private network feature. The team’s bill is the platform’s standard cost, plus a few dollars per month for the private network.
The right answer for a regulated app
The right answer for a regulated app is the VPC, on a managed Kubernetes cluster. The pattern: the team runs EKS, GKE, or AKS, the team configures the VPC, the team deploys the services inside the VPC, the team’s audit trail includes the VPC configuration.
The standard implementation: a managed Kubernetes cluster with a VPC, subnets, route tables, NAT gateways, and security groups. The team’s compliance team audits the VPC configuration, the audit includes the network isolation, the firewall rules, the logging, and the access controls.
The cost: the Kubernetes cluster plus the VPC plus the NAT gateway plus the load balancer. The team’s bill is a few hundred to a few thousand dollars per month, depending on the workload.
The right answer for the team that does not need a regulated setup: the service mesh on a managed platform. The trade-off is the audit trail (the managed platform’s audit trail is shorter than the VPC’s audit trail) and the customization (the VPC is more customizable than the service mesh).
The right answer for a hybrid app
The right answer for a hybrid app is the private connection, between the team’s on-prem and the cloud. The pattern: the team has an on-prem database, the team has a cloud frontend, the team needs the cloud frontend to reach the on-prem database. The private connection is the bridge.
The standard implementation: a site-to-site VPN between the team’s on-prem and the cloud, or a dedicated connection (Direct Connect, ExpressRoute, Interconnect) for higher bandwidth. The team’s on-prem database is reachable from the cloud over the private connection, the cloud frontend is reachable from the public internet.
The cost: the VPN on each side, plus the bandwidth. The team’s bill is a few hundred to a few thousand dollars per month, depending on the bandwidth and the connection type.
The right answer for the team that does not need a hybrid setup: a fully cloud-native app, with no on-prem dependencies. The trade-off is the migration cost (moving the on-prem database to the cloud) and the operational shape (the cloud database is managed, the on-prem database is not).
The cost reality
Private networking is not free. The three costs the team should model:
- VPC costs. The NAT gateway, the load balancer, and the data transfer are billed per hour and per GB. A typical NAT gateway is $0.045/hour ($32.40/month) plus $0.045/GB processed. A typical load balancer is $0.0225/hour ($16.20/month) plus $0.008/GB processed. A team with a small workload pays $50-100/month for the VPC plus the resources.
- Service mesh costs. The platform’s private network feature is usually $5-20/month on top of the plan. The team with a small workload pays the platform’s plan plus the small fee.
- Private connection costs. A site-to-site VPN is $0.05/hour ($36/month) per VPN on each side. A dedicated connection is $0.30/hour ($216/month) plus the cross-connect fees. The team with a small workload pays $100-500/month for the VPN on each side.
The team’s mental model: private networking is a security feature, and security features cost money. The right answer is to model the cost before the project ships, not after.
The RunxBuild hosting calculator is the right place to model the cost. Pick the runtime size, the database tier, the storage, the bandwidth, the private network feature, and the egress, and the calculator shows what the project actually costs at the team’s actual usage. The calculator also shows the comparison to RunxBuild’s pricing, which is the alternative the team should consider when the platform’s private networking is not the right fit.
Useful related references:
FAQ
What is a private network for cloud apps?
A “private network” in the cloud context is one of three things: a VPC (Virtual Private Cloud) at the cloud provider, a service mesh (private networking between the team’s services on a managed platform), or a private connection (site-to-site VPN or Direct Connect between the team’s infrastructure and the cloud). Each one answers a different question.
What is a VPC?
A VPC (Virtual Private Cloud) is a logically isolated section of the cloud provider’s network. The team launches resources inside the VPC, the resources have private IP addresses, the resources are not reachable from the public internet unless the team explicitly exposes them.
What is a service mesh?
A service mesh is a platform feature that allows the team’s services to talk to each other over a private network, not the public internet. The services have internal hostnames, the traffic does not leave the platform’s network.
What is a private connection?
A private connection is a dedicated link between the team’s on-prem infrastructure and the cloud. The connection is encrypted, the traffic does not go over the public internet. The standard implementations are site-to-site VPN (cheaper, lower bandwidth) and Direct Connect / ExpressRoute (more expensive, higher bandwidth).
When should I use a VPC?
When the team needs to run services that should not be reachable from the public internet, or when the team has a regulated workload that requires a specific network configuration. The right answer for a typical web app is the service mesh, not the VPC.
When should I use a service mesh?
When the team needs the services on a managed platform to talk to each other privately. The right answer for most teams is the platform’s built-in private network feature (Render, Fly.io, Railway, Vercel).
When should I use a private connection?
When the team has on-prem infrastructure that needs to reach the cloud, or when the team has a hybrid architecture that spans on-prem and cloud. The right answer is the site-to-site VPN, with the dedicated connection as a later upgrade when the bandwidth justifies the cost.
How much does private networking cost?
A VPC is $50-100/month plus the resources. A service mesh is $5-20/month on top of the platform plan. A private connection is $100-500/month per side. The cost is real, and the right answer is to model it before the project ships.