Public networking makes a service reachable through internet-routable addresses. Private networking keeps communication on internal addresses between trusted cloud resources. A production architecture should expose only the components that users or external systems must reach and keep databases, caches, workers, internal APIs, and management paths private by default.
The goal is not to eliminate public traffic. It is to create clear trust boundaries between public entry points and internal service communication.
Public and private traffic
Public traffic uses internet-routable endpoints. Examples include websites, public APIs, webhook receivers, and a load balancer’s frontend.
Private traffic uses internal addresses inside a private cloud network. Examples include application-to-database connections, service-to-service calls, cache traffic, monitoring, and internal administration.
| Traffic type | Typical direction | Examples |
|---|---|---|
| Public | North-south | Users to website, mobile app to API, third-party webhook |
| Private | East-west | App to database, worker to queue, app to cache |
| Controlled outbound | Internal to internet | Package updates, external APIs, email delivery |
North-south and east-west describe direction, not trust by themselves. Every path still needs authentication, encryption where required, and firewall policy.
What should be public?
Keep a component public only when an external user or system must connect directly.
Common public endpoints include:
- website or API edge
- load balancer
- reverse proxy
- webhook receiver
- VPN gateway
- tightly controlled bastion host
A public endpoint should have only the required ports open and should be protected with appropriate TLS, authentication, rate controls, patching, and monitoring.
What should remain private?
Private-by-default components usually include:
- PostgreSQL, MySQL, and other databases
- Redis and cache services
- message queues
- worker nodes
- internal APIs
- monitoring and logging systems
- CI/CD runners
- admin dashboards
- storage backends
- application servers behind a public load balancer
Private networking reduces direct internet exposure, but it is not a replacement for credentials, encryption, patching, or least-privilege rules.
Public edge, private backend
A common production pattern is:
Internet users ↓ Public load balancer or reverse proxy ↓ Private application servers ↓ Private database, cache, and queue
This design creates one controlled public entry layer while keeping the data plane private.
Benefits include:
- smaller public attack surface
- clearer firewall rules
- easier service segmentation
- simpler backend replacement
- reduced accidental database exposure
Private IPs do not automatically create isolation
Placing resources on one private network only creates reachability. Security still depends on policy.
A flat private network can allow more communication than intended. Apply least privilege by defining:
- which source can reach which destination
- exact protocol and port
- administrative access path
- environment boundaries
- outbound internet requirements
For example, an application server may need TCP access to PostgreSQL, but a CI runner may not. A monitoring system may need metrics access, but it should not automatically receive database credentials.
NAT and outbound internet access
Private resources often need outbound internet access for updates, package repositories, external APIs, or telemetry without accepting unsolicited inbound traffic.
A NAT gateway or managed gateway can provide this pattern:
Private VM ↓ outbound connection NAT gateway ↓ Public internet
NAT changes address translation and inbound reachability. It does not provide application authentication or complete firewall policy by itself.
Review:
- whether outbound access is required
- which destinations or ports are necessary
- whether fixed egress IPs are needed
- logging and monitoring requirements
- dependency on the gateway as a failure point
Private networking and DNS
Private services should use stable private names where possible rather than hard-coded addresses.
Private DNS or internal naming helps with:
- backend replacement
- environment separation
- service discovery
- readable configuration
DNS does not replace health checks or failover logic. It is one part of how services find each other.
Administrative access
Avoid exposing SSH, RDP, and management dashboards on every server.
Safer patterns include:
- VPN access
- bastion host
- zero-trust access proxy
- source-IP-restricted admin endpoint
- temporary just-in-time access
| Pattern | Strength | Trade-off |
|---|---|---|
| Public SSH/RDP on each server | Simple | Largest exposed admin surface |
| Bastion host | Central entry point | Bastion must be hardened and monitored |
| VPN | Private admin reachability | Requires client and access management |
| Zero-trust proxy | Identity-aware control | Additional platform and policy complexity |
Use separate administrative paths from normal user traffic.
Environment segmentation
Development, staging, and production should not share unrestricted access merely because they belong to the same company.
Separate environments through private networks, subnets, firewall rules, accounts, or a combination of controls.
The goal is to prevent:
- staging services reaching production databases
- test credentials working in production
- compromised development systems moving laterally
- accidental use of production data
Segmentation should reflect trust and failure impact, not only organizational convenience.
Firewall boundaries
A useful firewall model starts with deny-by-default and adds explicit flows.
| Source | Destination | Allowed flow |
|---|---|---|
| Internet | Load balancer | HTTPS only |
| Load balancer | App servers | Application port and health checks |
| App servers | Database | Database port only |
| App servers | Cache | Cache port only |
| Admin network | Private servers | Required management ports |
| Monitoring | Servers | Metrics and health endpoints |
Document these flows. Unclear firewall rules become difficult to audit and easy to over-expand.
Encryption on private networks
Private routing lowers exposure but does not always remove the need for encryption.
Use TLS or protocol-native encryption when:
- compliance requires it
- credentials or sensitive data cross service boundaries
- multiple tenants or trust zones share infrastructure
- the network path is not fully controlled
- application policy requires end-to-end protection
For lower-risk traffic inside a tightly controlled network, teams may make a different decision. That should be an explicit risk choice, not an assumption that “private means encrypted.”
Performance and reliability
Private networking can reduce unnecessary public routing and make internal traffic easier to reason about. It can also support higher-bandwidth service communication without public egress billing, depending on the provider.
However, performance depends on architecture, region, network implementation, and workload. Do not assume that private networking automatically fixes latency.
Also review shared dependencies:
- gateway availability
- DNS availability
- routing configuration
- firewall changes
- overlapping address ranges
- cross-region connectivity
A private network can become a critical dependency and should be monitored accordingly.
Decision framework
Use this order for each component:
- Identify who must connect to it.
- Determine whether direct internet access is necessary.
- Keep it private when only internal systems need access.
- Define exact source, destination, protocol, and port rules.
- Decide how private resources reach external services.
- Separate user traffic from administrative access.
- Segment production from lower-trust environments.
- Decide where encryption is required.
- Document DNS, routing, gateway, and firewall dependencies.
- Test failure and recovery paths.
A simple default remains useful:
If only your own infrastructure needs to reach a service, keep it private.
How this applies on Raff
Raff Private Cloud Networks provide isolated networking for supported Raff resources. The current product page describes free private networks, managed gateway functions such as NAT, DNS, and DHCP, and unmetered private traffic on the internal network.
A practical Raff design can use:
- a public load balancer or reverse proxy
- private application VMs
- private database and cache services
- cloud firewall rules between tiers
- managed gateway services for required outbound access
- snapshots and backups for recovery
Use the live product page for current regions, limits, gateway behavior, and supported resources. The previous guide’s hourly-billing statement has been removed because Raff Cloud Server positioning should not be described that way.
Public vs private decision matrix
| Component | Public by default? | Recommended pattern |
|---|---|---|
| Website frontend | Yes | Public HTTPS edge |
| Load balancer | Yes | Public frontend, private backends |
| Application server | No | Private behind edge |
| Database | No | Private, limited to approved clients |
| Cache or queue | No | Private only |
| Webhook receiver | Yes | Public endpoint, private downstream processing |
| Monitoring | No | Private or tightly controlled access |
| Bastion/VPN gateway | Sometimes | Public but strongly restricted |
| CI/CD runner | No | Private with controlled outbound access |
:::cluster
Conclusion
Public networking is for services that external users or systems must reach. Private networking is the safer default for internal services and data paths.
Expose a narrow public edge, keep stateful and operational services private, control east-west traffic with explicit firewall rules, and design NAT, DNS, encryption, and administrative access as part of the same security boundary.