Cloud Networking Guide: VPCs, Routing & Load Balancing

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, the objective is not to reproduce an enterprise network. It is to define which services are public, which remain private, how internal traffic moves, where internet access enters and leaves, and which controls prevent one workload from reaching another unnecessarily.

Raff Technologies supports more than 3,000 customers and 15,000 deployed VMs across cloud workloads. In our infrastructure reviews, networking problems usually appear when teams add a second or third service without revisiting the original one-VM assumptions: databases remain public, private CIDRs overlap with future VPN ranges, load-balanced backends still expose public ports, or nobody owns the route and firewall rules connecting the application tiers.

This guide maps the complete cloud networking decision. For deeper implementation and architecture choices, continue with Public vs Private Networking, Private Cloud Networks Explained, and Load Balancing Explained.

Cloud networking connects public, private, and service traffic

A cloud network normally has several traffic classes rather than one flat path.

A production design should expose the smallest practical public surface. Databases, caches, queues, workers, internal APIs, and monitoring systems normally belong on private paths unless an external system has a documented reason to reach them directly.

Private networking does not replace authentication, encryption, patching, or firewall policy. It creates a cleaner reachability boundary on which those controls can operate.

The decision framework starts with five network boundaries

Before choosing subnets, NAT, or a load balancer, define the boundaries the application actually needs.

Use a single public edge when one website or API serves users and its backend dependencies should remain private.

Use a VPC or private network as soon as several cloud resources need repeatable internal communication or a stateful service should not be internet-facing.

Add load balancing when one application server should no longer define capacity, availability, deployment safety, or maintenance behavior.

Add hybrid or site-to-site connectivity only when a real remote network, office, customer environment, or another cloud must communicate with private resources.

The architecture rule is simple: every new network layer should solve a defined reachability, isolation, capacity, or failure problem.

VPC networking creates the internal application boundary

A Virtual Private Cloud (VPC) is a logically isolated network where cloud resources communicate through private addresses and controlled network policy.

A small multi-VM application can start with:

Internet
  -> public application edge
       -> private VPC
          -> application VM
          -> database VM
          -> worker / cache

The private network becomes the default path for app-to-database, app-to-cache, worker-to-queue, monitoring, and other internal communication.

CIDR planning matters because private address space may later need to connect to:

• an office network;
• a VPN client range;
• another environment;
• another cloud provider;
• a customer network;
• a second region.

Avoid overlapping address ranges between networks that may need to communicate later. For the detailed VPC and CIDR framework, use Private Cloud Networks Explained.

A VPC does not need many subnets on day one. Start with the simplest boundary that gives the application enough isolation and room to grow. Add segmentation when routing, security, ownership, or availability genuinely differs between workload groups.

Routing, NAT, DNS, and DHCP make the private network usable

Private addressing is only one part of cloud networking. Resources also need a way to discover destinations and reach the networks they are allowed to use.

Routing defines the path

Routes determine where traffic for a destination should go. Typical route decisions include:

• local traffic inside the VPC;
• outbound internet traffic through a gateway;
• traffic to another VPC through peering;
• traffic to an office or remote network through a VPN;
• service traffic to managed internal endpoints.

Broad routing should not be treated as permission. A route makes a path possible; firewall or security policy decides whether a workload should use it.

NAT provides controlled outbound access

Private resources often need package repositories, external APIs, license servers, or other internet destinations without accepting unsolicited public inbound traffic.

A NAT pattern looks like:

Private VM
  -> gateway / NAT
     -> public internet

NAT changes address translation and inbound reachability. It does not replace application authentication, firewall policy, or outbound governance.

DNS keeps service configuration stable

Applications should use predictable service names where possible instead of scattering hard-coded IP addresses through configuration.

Internal names such as:

db.production.internal
cache.production.internal
api.internal

make server replacement and environment separation easier to manage.

DHCP simplifies private addressing

Managed DHCP can assign network settings to attached resources instead of requiring manual address configuration for every VM. The address plan still needs ownership and documentation even when assignment is automated.

Security groups and firewalls enforce service relationships

Cloud networking should express which services may communicate—not simply which IPs happen to exist.

A useful policy matrix is:

Avoid turning one private VPC into one large trusted zone. A compromised internal workload should not automatically gain access to every database, admin service, and environment.

Apply least privilege to east-west traffic and document exceptions. Production and staging should also not share unrestricted network access merely because both belong to the same organization.

For the detailed public/private boundary decision, use Public vs Private Networking.

Load balancing becomes the public traffic layer when one node is not enough

A load balancer provides one traffic entry point for several application backends.

Internet
  -> load balancer
     -> private App VM 1
     -> private App VM 2
     -> private App VM 3
        -> private database / cache / queue

Add this layer when:

• one application VM cannot safely handle peak traffic;
• one-node failure creates unacceptable downtime;
• deployments should drain and replace backends without stopping all traffic;
• maintenance should not require a full outage;
• backend nodes can serve requests interchangeably.

Do not use load balancing to hide a database bottleneck, local application state, missing shared storage, or poor query performance.

A reverse proxy and a load balancer can also overlap. One controls how requests reach applications; the other distributes traffic across a backend pool. For that architecture decision, use Reverse Proxy vs Load Balancer.

For L4/L7 routing, health checks, draining, and failure capacity, use Load Balancing Explained.

Peering, PrivateLink, and VPNs extend the private boundary

Not every private connection should be solved by giving resources public IP addresses.

Different connectivity mechanisms solve different problems:

Use peering when two cloud networks genuinely need direct private communication and their address plans are compatible.

Use private service endpoints when an application should reach a managed service without using a public data path.

Use site-to-site VPN when an office, customer network, or another infrastructure environment must join the private routing model.

Every connection expands the trust and routing graph. Record the CIDR ranges, owners, allowed services, firewall rules, monitoring, and failure behavior before adding the link.

Observability and recovery include the network layer

Applications can fail even when compute and databases are healthy if routes, DNS, gateways, health checks, or firewall rules are wrong.

Monitor network dependencies alongside the application:

• backend health;
• connection failures;
• DNS resolution errors;
• gateway availability;
• packet or connection drops where visible;
• latency between service tiers;
• public endpoint health;
• failed administrative access;
• changes to routes or security policy.

Network configuration also belongs in disaster recovery planning.

A restored VM may still be unusable if:

• it is not attached to the expected VPC;
• the private IP or DNS name changed unexpectedly;
• firewall rules no longer permit the application flow;
• the public edge points to the wrong backend;
• VPN or peering routes were not restored;
• monitoring cannot reach the recovered service.

Treat routes, DNS, firewall relationships, load-balancer configuration, and access paths as part of the application recovery inventory rather than as background infrastructure.

Raff VPC provides the private networking foundation

Raff VPC provides isolated private networking for Raff workloads. The current product page describes free VPCs with managed NAT, DNS, and DHCP, private traffic over a 25 Gbps unmetered internal network, stateful per-VM security groups, custom DNS, VPC peering, private service connectivity, audit logs, and API/CLI/Terraform access.

The current Raff VPC model supports private IPv4 CIDR ranges from /16 through /28. Separate isolated VPCs can use overlapping CIDRs, but networks that may later be connected through peering or VPN should still be planned to avoid overlap.

A practical Raff architecture can evolve in stages:

Stage 1
Public Raff VM
  -> application

Stage 2
Raff VPC
  -> public app VM
  -> private database / worker VM

Stage 3
Raff Load Balancer
  -> private application pool
  -> private database / cache / workers

Stage 4
Peering or VPN
  -> only when another network must join the architecture

Raff Load Balancers can become the traffic-distribution layer when the application is ready for multiple interchangeable backends. Raff VM provides the compute foundation for application, worker, utility, and self-hosted service roles.

The important sequence is to define the traffic boundary first, then add the networking product that solves that boundary.

Conclusion: cloud networking should make traffic boundaries explicit

Cloud networking is the architecture that determines how users, applications, databases, workers, managed services, and administrators reach one another.

Start with a narrow public edge and keep internal services private by default. Use a VPC for repeatable private communication, define routes and DNS deliberately, enforce service relationships with security groups or firewall rules, and add load balancing only when one application node should no longer define capacity or availability.

As the environment grows, extend the private boundary with peering, private service connectivity, or VPNs only when a real dependency requires them. Keep address plans, routes, access paths, monitoring, and recovery procedures documented so the network remains understandable under both normal operations and incidents.

Continue with Private Cloud Networks Explained for detailed VPC design or Load Balancing Explained when the application is ready for multiple backends.

Sources

• AWS: What Is Cloud Networking?
• RFC 1918: Address Allocation for Private Internets
• Raff VPC
• Raff Load Balancers
• Raff VM
• Product details last reviewed: 2026-08-11