Cloud networking is the design of virtual network paths, addressing, routing, security, and traffic distribution that connect applications and infrastructure inside a cloud environment.
For small teams, good cloud networking starts with four questions: what must be public, what should remain private, how internal services communicate, and how administrators reach production safely. Build from those boundaries before adding extra gateways, routes, or traffic-distribution layers.
Raff Technologies workloads can combine public VM connectivity with VPC private networking, Site-to-Site VPN, and security controls so application, database, worker, and administrative traffic do not all share the same public path.
A useful rule is:
Expose the smallest useful public edge, keep internal services private by default, and add network layers only when they solve a real reachability, isolation, capacity, or recovery problem.
Cloud networking: quick answer
A practical cloud network usually contains several traffic classes:
| Traffic class | Typical path | Examples |
|---|---|---|
| Public inbound | Internet → public edge | Website, API, webhook |
| Private east-west | Service → service | App → database, worker → queue |
| Controlled outbound | Private resource → internet | Package updates, external APIs |
| Administrative | Operator → infrastructure | VPN, bastion, restricted SSH/RDP |
| Cross-network | Office/customer network → cloud | Site-to-site VPN |
Do not treat the whole environment as one trusted network. Public and private reachability should be explicit, and private paths still need authentication, authorization, firewall policy, patching, and encryption where appropriate.
What is cloud networking?
Cloud networking is the architecture that determines how cloud resources reach users, one another, external services, and administrators.
It includes:
- public and private IP addressing;
- VPCs and private network boundaries;
- routing;
- NAT and outbound connectivity;
- DNS;
- firewall and security policy;
- administrative access;
- traffic distribution;
- VPN and cross-network connectivity;
- monitoring and recovery of network dependencies.
The network should describe intended application relationships rather than simply connect every server to every other server.
The cloud networking architecture starts with five boundaries
Before choosing subnets, routes, NAT, or load balancing, define the boundaries the workload actually needs.
| Boundary | Question | Typical result |
|---|---|---|
| Public edge | Which services must external users reach? | HTTPS website/API |
| Private application path | Which services communicate internally? | VPC/private network |
| Data boundary | Who may reach databases, caches, queues? | Private source-restricted access |
| Administrative path | How do operators reach production? | VPN, bastion, restricted admin path |
| External/private connectivity | Which other networks must connect? | Site-to-site VPN or other controlled link |
Every added network component should solve one of these questions. Complexity without a clear boundary usually creates more configuration to maintain without improving the architecture.
Public and private networking serve different roles
Public networking is for services that outside users or systems must reach. Private networking is for communication that should remain inside controlled infrastructure paths.
A common production pattern is:
Internet ↓ HTTPS Public application edge ↓ private VPC Application services ↓ private VPC Database / cache / queue / workers
This keeps the user-facing service reachable while reducing direct exposure of stateful and internal components.
Use Public vs Private Networking for the detailed decision framework.
VPC networking creates the internal service boundary
A Virtual Private Cloud is a logically isolated private network for cloud resources.
A VPC becomes useful when:
- an application has more than one server;
- a database or cache should not be public;
- workers need private application access;
- Windows and Linux servers must communicate internally;
- administrators need private reachability;
- several service roles need repeatable firewall relationships.
A simple architecture can start with:
Public application VM ↓ private VPC Database VM Worker VM Internal service
The goal is not to create many subnets immediately. Start with the simplest private boundary that keeps internal services off unnecessary public paths, then add segmentation when trust, ownership, routing, or failure behavior genuinely differs.
CIDR planning matters before networks need to connect
Private address ranges become important when a VPC may later connect to:
- an office network;
- VPN clients;
- another environment;
- a customer network;
- another cloud;
- another private network.
Avoid overlapping CIDR ranges between networks that may need routing between them later. Overlap can make VPN or inter-network connectivity difficult or require translation and redesign.
The address plan should be documented even for small environments so later expansion does not depend on guessing which ranges are already in use.
Routing creates paths; it does not grant permission
A route tells traffic where to go. It does not decide whether the source should be allowed to use the destination service.
Think of the path as layers:
Route exists ↓ Firewall permits source/port ↓ Service authenticates caller ↓ Application authorizes action
A broad route can coexist with narrow firewall rules. A broad route plus broad permissions creates unnecessary lateral movement paths.
For VPC CIDR planning, private service-to-service reachability, and network policy boundaries, read VPC Architecture for Multi-VM Applications.
Use Cloud Firewall Best Practices for the service-to-service policy model.
NAT provides outbound access without requiring public inbound access
Private resources may still need the internet for:
- package repositories;
- external APIs;
- license services;
- software updates;
- email providers;
- monitoring endpoints.
A NAT or gateway pattern allows outbound connectivity without making the private server directly reachable from unsolicited public traffic.
Private VM ↓ outbound Gateway / NAT path ↓ Internet
NAT changes routing and address translation. It does not replace firewall rules, credential controls, application authorization, or outbound governance.
DNS keeps internal service names stable
Private services are easier to operate when applications use stable service names instead of hard-coded IP addresses.
Examples:
db.production.internal cache.production.internal api.internal
Internal DNS helps with server replacement and environment separation, but DNS itself becomes part of application availability. Recovery testing should confirm that expected names still resolve after a service is rebuilt.
Private VPC name resolution is different from the authoritative public DNS records used by websites and APIs. For public records, TTL, migration, and failover decisions, read DNS for Cloud Applications.
Firewalls should express service relationships
Good network policy reflects which service roles need to communicate.
| Source | Destination | Typical allowed traffic |
|---|---|---|
| Internet | Public edge | HTTPS/required public service |
| Public edge | App server | Application port only |
| App server | Database | Required database port |
| App server | Cache/queue | Required internal service port |
| Worker | Queue/database | Required worker paths |
| Admin path | Servers | Approved SSH/RDP/admin ports |
| Monitoring | Workloads | Health/metrics endpoints |
Private networking does not mean every private source should reach every private destination. Production, staging, CI/CD, monitoring, and customer environments may need different rules.
Load balancing is a traffic-distribution pattern, not a requirement for every cloud network
A load balancer or other traffic-distribution layer becomes useful when one application node should no longer define capacity, maintenance, deployment safety, or availability.
Internet ↓ Traffic-distribution layer ↓ App VM 1 App VM 2 App VM 3 ↓ private network Database / cache / workers
Add this layer when:
- one application VM cannot safely handle peak traffic;
- one-node failure creates unacceptable downtime;
- backends can serve requests interchangeably;
- deployments should drain and replace nodes safely;
- maintenance should not require a total outage.
Do not use load balancing to hide a database bottleneck, local application state, missing shared storage, or poor queries.
Raff's managed Load Balancer product is not currently a dependency this guide assumes is live. If you plan to use a managed traffic-distribution service, verify current product availability first. The architecture principles remain the same whether the traffic layer is managed or self-operated.
Use Load Balancing Explained or Reverse Proxy vs Load Balancer for the deeper design choice.
Administrative networking should be separate from user traffic
SSH, RDP, database administration, and management dashboards should not automatically use the same public path as customer traffic.
Common options include:
| Model | Good fit | Main trade-off |
|---|---|---|
| Restricted public SSH | Simple Linux environments | Public management endpoint remains |
| Bastion host | Controlled server administration | Gateway becomes critical infrastructure |
| VPN | Multiple private protocols/resources | Requires peer and route management |
| Site-to-site VPN | Office/customer network to cloud | Network-level trust must be scoped carefully |
For production systems, prefer private or tightly restricted administration as the number of users, servers, Windows systems, and customer workloads grows.
Use Bastion Host vs VPN vs Public SSH and Private vs Public Admin Access for the access decision.
Windows RDP benefits from private network design
Windows Server environments often need RDP, file shares, databases, line-of-business applications, or management tools that should not all be directly public.
A cleaner pattern is:
Administrator / user ↓ restricted VPN/private path Windows VM ↓ private VPC Database / internal service
Raff Windows VM can participate in the same VPC-based architecture as Linux workloads. Keep named Windows users, least-privilege Administrator membership, current patches, and Network Level Authentication where supported as separate controls.
Databases and stateful services should normally stay private
Databases, caches, queues, and internal storage services are rarely improved by direct public exposure.
Prefer source-restricted private paths from the application or approved administration network.
If the team does not want to operate the database host and recovery lifecycle itself, Raff provides Managed Databases for PostgreSQL, MySQL, Valkey, ClickHouse, and Kafka.
Site-to-site VPN extends the private boundary
Some workloads need connectivity between Raff infrastructure and an office, customer network, or another approved network.
Office / customer network ↓ Site-to-Site VPN Raff network ↓ private VPC paths VMs / internal services
For CIDR planning, return routes, IPsec/WireGuard choices, DNS, and tunnel recovery, use Site-to-Site VPN Architecture: Hybrid Cloud Guide.
The private Raff VPC itself has no separate VPC charge, but the VPN gateway and each site tunnel are billed separately. Check the current gateway and tunnel rates on Raff's dedicated Site-to-Site VPN product page before budgeting; the general VM pricing table is not the VPN price source.
Network observability belongs in application monitoring
Compute can be healthy while the application is unreachable because of:
- DNS failures;
- incorrect routes;
- firewall changes;
- broken VPN paths;
- inaccessible public endpoints;
- backend connection failures;
- overlapping address ranges;
- incorrect traffic-distribution configuration.
Monitor the path customers and administrators actually use rather than only VM CPU and memory.
Recovery plans must include the network
A restored VM is not a restored service if the expected network path is missing.
Recovery testing should confirm:
- The VM or replacement service is attached to the correct private network.
- Required DNS names resolve.
- Firewall rules allow the intended sources and ports.
- The application can reach its database and other dependencies.
- Public endpoints reach the correct backend.
- VPN or cross-network routes work where required.
- Administrator access is available through the documented path.
Use Cloud Snapshots vs Backups for the recovery-copy side of the design.
How Raff VPC fits the architecture
Raff VPC is the current private-networking foundation for Raff workloads.
Current networking facts relevant to this guide are:
- VPC traffic is private and unmetered;
- VPC itself has no separate VPC charge;
- Raff VM public traffic uses 1 Gbps on Cost-Optimized or 3 Gbps on General Purpose, CPU-Optimized and Windows, depending on the family;
- VM public traffic is unmetered with no VM egress fee;
- Site-to-Site VPN provides network-to-network private connectivity.
A practical Raff architecture can grow in stages:
Stage 1 Public Raff VM → application Stage 2 Public application edge ↓ Raff VPC → private database / worker / internal service Stage 3 Traffic-distribution layer ↓ Private application nodes ↓ Private database / cache / workers Stage 4 Site-to-site or remote-access VPN → only when another network or administrator path must join
Use Raff Cloud Servers for compute, VPC for private communication, Security for the surrounding security surface, Site-to-Site VPN for cross-network connectivity, and Data Protection for VM recovery planning.
