A public network makes selected services reachable through internet-routable paths. A private network keeps service-to-service traffic on controlled internal paths that are not directly exposed to the public internet.
For cloud infrastructure, the practical rule is simple: keep the public edge as small as possible and use private networking for databases, caches, workers, internal APIs, backend nodes, and most administrative paths.
Raff Technologies supports this model with Raff VPC: expose only the VM or application endpoints that customers or external systems must reach, then keep internal service traffic on private network paths.
This guide is about cloud and server network architecture. It is not about the Windows desktop setting that labels a Wi-Fi or Ethernet connection as a “Public” or “Private” network profile.
Public where external reachability is required; private for internal communication unless there is a documented reason to expose it.
Public vs private network: quick comparison
| Area | Public network | Private network |
|---|---|---|
| Reachability | Internet-routable | Internal or controlled routes |
| Typical users | Customers, partners, public APIs | Applications, administrators, databases, internal services |
| Common examples | HTTPS website, public API, webhook endpoint | App-to-DB, worker-to-queue, cache, internal API |
| Public IP required | Usually at the exposed edge | Usually no |
| Main risk | Internet-facing attack surface | Excessive lateral access inside the environment |
| Authentication required | Yes | Yes |
| Firewall policy required | Yes | Yes |
| Encryption where appropriate | Yes | Yes |
A private IP address is not automatically secure, and a public IP address is not automatically insecure. The important difference is who can route traffic to the service. Security still depends on authentication, authorization, patching, firewall rules, segmentation, encryption where required, and operational controls.
What is a public network in cloud infrastructure?
A public network provides internet-routable connectivity for services that external users or systems need to reach.
Typical public endpoints include:
- websites;
- public APIs;
- webhook receivers;
- reverse proxies;
- VPN entry points;
- selected administration endpoints when a private access path is not practical.
Public does not mean “open every port.” A production web server may need HTTPS reachable from the internet while SSH, RDP, database ports, metrics, and application runtime ports remain private or source-restricted.
The public network should therefore be treated as an intentionally small edge, not the default path for every component.
What is a private network?
A private network lets approved infrastructure resources communicate through internal routes without requiring direct internet exposure for each service.
Typical private traffic includes:
- application-to-database connections;
- worker-to-queue communication;
- application-to-cache traffic;
- internal APIs;
- monitoring and metrics;
- cluster or service-to-service traffic;
- administration through VPN or bastion paths.
Private networking becomes more valuable as an application grows beyond one server. Once a team separates a database, adds workers, introduces a cache, or runs multiple application nodes, routing every internal connection through public addresses adds exposure and operational complexity without creating business value.
What is private networking in cloud computing?
In cloud infrastructure, private networking is the use of an isolated network or VPC to connect resources over private addressing and controlled internal routes.
A simple example is:
Internet ↓ HTTPS Public web/app endpoint ↓ private network Database Worker Cache Internal API
The application still has a public entry point, but the backend services do not need their own public service endpoints.
That separation improves architecture in three ways:
- Reachability is explicit. Only components that need internet access are exposed.
- Backend addressing is simpler. Internal services can communicate through stable private paths.
- Security policy becomes narrower. Firewall rules can describe which service roles may talk to which other roles.
Public network vs private network: what is the real difference?
The core difference is reachability, not trust.
Public path Internet → public endpoint → application Private path Application → private network → database/cache/worker
Use a public path when an outside client must initiate the connection. Use a private path when communication should stay between infrastructure components or approved administrators.
The decision should be made service by service.
| Component | Public by default? | Better default |
|---|---|---|
| Website | Yes | HTTPS public edge |
| Public API | Yes | Public endpoint with private downstream services |
| Webhook receiver | Yes | Public receiver, private backend |
| Application node behind an edge | Usually no | Private backend path |
| Database | No | Private and source-restricted |
| Cache | No | Private only |
| Queue | No | Private only |
| Monitoring dashboard | Usually no | Private or tightly restricted |
| CI/CD runner | Usually no | Private with controlled outbound access |
| SSH/RDP | Usually no for production | VPN, bastion, or tightly restricted source access |
A public edge with private backends is the common production pattern
Most multi-service applications do not need every server to be publicly reachable.
A cleaner pattern is:
Internet ↓ HTTPS Public application edge ↓ private network Application services ↓ private network Database / cache / workers
This reduces the number of services exposed directly to the internet and creates clearer boundaries between user-facing traffic and backend traffic.
It also makes future architecture changes easier. A database can move to another VM, a worker tier can be added, or multiple app nodes can be introduced without making every new component public.
For the broader scaling decision, see Single Server vs Multi-Server Architecture.
Private traffic does not mean trusted traffic
Private routing reduces public exposure. It does not create an implicit trust zone.
NIST SP 800-207 explicitly rejects the idea that network location alone should grant trust. A workload on a private network should still authenticate and authorize access to sensitive resources.
A compromised application VM should not automatically receive unrestricted access to:
- production databases;
- unrelated customer environments;
- backup systems;
- monitoring administration;
- internal management APIs;
- secrets infrastructure.
Use least privilege inside the private network:
- allow only the sources that need a database connection;
- limit service-to-service ports;
- separate production and non-production where appropriate;
- avoid broad address ranges when narrower rules are practical;
- remove stale rules when systems are retired;
- review IPv4 and IPv6 exposure consistently.
Use Cloud Firewall Best Practices for the rule model.
Public traffic, private traffic, north-south, and east-west traffic
These terms describe related but different concepts.
North-south traffic enters or leaves an environment. Examples include a customer reaching a public API or a private server calling an external payment provider.
East-west traffic moves between internal services. Examples include an app node connecting to a database, queue, worker, or cache.
Neither term defines trust by itself.
North-south inbound Internet → public API East-west private API → database North-south outbound Private worker → external email provider
Use traffic direction to understand the path. Apply authentication, authorization, firewall policy, and encryption separately.
What does NAT do for a private network?
A private server may still need outbound internet access for package repositories, external APIs, license checks, email providers, or software updates.
NAT can provide an outbound path without making that server directly reachable for unsolicited inbound internet connections.
Private VM ↓ outbound request NAT / gateway ↓ Internet
NAT is not an authorization system. It changes addressing and reachability. Firewall policy, application credentials, egress restrictions, and service authentication still matter.
Also ask whether every private workload needs broad outbound internet access. A database may need far less outbound connectivity than an application server.
Private DNS helps internal services avoid hard-coded addresses
Private services should not depend on hard-coded IP addresses where a stable internal name is more appropriate.
Examples:
db.production.internal cache.production.internal api.internal
Private DNS can simplify backend replacement and environment separation, but DNS itself becomes an operational dependency. A healthy service can still be unreachable if clients resolve the wrong address or cannot resolve the name at all.
Routing and firewall policy are different controls
A route tells traffic where to go. A firewall or security rule decides whether a source should be permitted to use that path.
Route exists ↓ Firewall permits source and port ↓ Service authenticates caller ↓ Application authorizes action
A private route should never be interpreted as blanket permission.
Administrative traffic should be separated from customer traffic
SSH, RDP, database administration, internal dashboards, and management interfaces should not automatically use the same public exposure model as customer-facing traffic.
Common patterns include:
| Pattern | Strength | Trade-off |
|---|---|---|
| Public SSH/RDP everywhere | Simple | Largest exposed admin surface |
| Source-IP restriction | Simple for stable operators | Depends on predictable source addresses |
| Bastion host | Centralized entry point | Bastion becomes a critical control |
| VPN | Private multi-resource access | Requires identity, peer, and route management |
| Identity-aware access | Strong identity boundary | More operational complexity |
For production systems, administration is usually easier to govern when it uses a separate controlled path.
Use Bastion Host vs VPN vs Public SSH or Private vs Public Admin Access for that decision.
Windows RDP is a strong case for controlled access
Windows business workloads may use RDP for administration or user access. Broad public RDP exposure is generally a poor production default.
A safer architecture is:
Administrator or user ↓ controlled VPN/private path Windows VM
Private networking does not replace Windows security controls. Named user accounts, Network Level Authentication where supported, current patches, least-privilege administration, and login monitoring still matter.
Raff Windows VM workloads can use VPC for internal application, database, and administrative paths.
Databases, caches, and queues should normally remain private
Stateful backend services are high-value targets and rarely benefit from direct internet exposure.
Prefer:
Public application ↓ private network Database / cache / queue
Restrict each backend to only the application or administrative roles that require access.
If a team does not want to manage the database server and its recovery lifecycle directly, Raff Managed Databases can separate database operations from the application VM.
Development, staging, and production should not share one flat trust zone
Private networking does not justify unrestricted access between environments.
Production usually needs stronger boundaries because it holds real user traffic, business data, and stricter recovery obligations.
Separate where appropriate:
- credentials;
- databases;
- network rules;
- administrative permissions;
- backup deletion rights;
- service accounts.
Use Staging vs Production vs Development Environments for the broader environment model.
Private networking does not automatically encrypt traffic
Private routing and encryption are separate controls.
Use TLS or protocol-native encryption when:
- credentials or sensitive data cross service boundaries;
- different trust zones communicate;
- policy or customer requirements require encryption in transit;
- the path extends beyond infrastructure you fully control;
- end-to-end application protection matters.
“Private” describes reachability. It does not inherently mean the payload is encrypted.
Site-to-site connectivity extends private networking beyond one VPC
Some teams need to connect cloud workloads to an office, customer network, MSP environment, or another approved network without exposing every internal service publicly.
A site-to-site VPN can create that network-to-network path:
Office / customer network ↓ site-to-site VPN Cloud private network ↓ Application / Windows VM / internal services
Do not hard-code VPN pricing or limits into an evergreen architecture guide. Those details can change. Use the current Raff VPC and pricing pages when a deployment depends on gateway, NAT, DNS, VPN, or network pricing details.
Monitor network dependencies, not only VM health
A healthy VM can still be unreachable because another network dependency is wrong.
Monitor or review:
- DNS resolution;
- private routes;
- firewall and security-rule changes;
- gateway or VPN availability;
- public endpoint health;
- backend reachability;
- administrative access paths;
- overlapping address ranges when networks are connected.
Recovery testing should also verify that restored workloads have the expected private-network attachment, DNS, routes, and permitted traffic paths.
How Raff VPC fits the model
Raff VPC is the private-networking layer for Raff workloads.
The current VPC product page includes the network, managed gateway, NAT, DNS/DHCP, security controls, and private traffic as part of the VPC model. Because network capabilities and limits can change, use the live VPC page as the product source of truth rather than copying every limit into this guide.
A practical architecture can evolve gradually:
Stage 1 Public Raff VM → application Stage 2 Public application edge ↓ Raff VPC → database / worker / internal service Stage 3 Traffic-distribution layer ↓ Private application nodes ↓ Private database / cache / workers
Use Raff Cloud Servers for self-managed compute, Raff VPC for private communication, Managed Databases when the data layer should have separate operational ownership, and Data Protection for current VM recovery options.
Raff VMs remain self-managed at the guest OS and application level. A VPC reduces unnecessary public exposure, but your team still owns guest firewall policy, service authentication, OS patching, application security, and the access rules inside the VM.