VPC architecture is the design of private addressing, routing, security boundaries, and service connectivity that lets multiple cloud resources communicate without exposing every component to the public internet.
For a multi-VM application, a good VPC design keeps the public edge small, moves databases and internal services onto private paths, assigns clear traffic rules between service roles, and leaves enough address space for future VPN or network connections.
Raff Technologies workloads can use VPC private networking so application VMs, databases, workers, Windows servers, and internal services do not need to communicate through public endpoints.
A practical rule is:
Design the VPC around application relationships, not around the number of servers.
VPC architecture: quick answer
A typical multi-tier application can start with this model:
Internet ↓ HTTPS Public application edge ↓ private VPC Application VM(s) ↓ Database / cache / queue / workers Administrators ↓ controlled access path Private resources
The important boundaries are:
| Boundary | Default design |
|---|---|
| Public user traffic | Only the required application edge |
| Application-to-database | Private VPC path |
| Cache/queue/worker traffic | Private VPC path |
| Administration | VPN, bastion, or tightly restricted path |
| Outbound internet | Only where a workload requires it |
| Cross-network access | Explicit VPN or other controlled connection |
A private network should reduce public exposure without turning the entire VPC into one trusted zone.
What is VPC architecture?
A Virtual Private Cloud (VPC) is an isolated network inside a cloud environment where resources can communicate through private addressing and controlled network policy.
VPC architecture determines:
- which workloads belong to the same private network;
- which CIDR range the network uses;
- which services can route to one another;
- which ports and protocols are permitted;
- how private resources reach the internet when required;
- how administrators reach private systems;
- how the VPC connects to offices, customers, or other networks;
- how the network is recreated during recovery.
The network should reflect the application graph rather than simply connect every private IP to every other private IP.
VPC design best practices start with workload isolation
The strongest starting point for VPC design is to identify which workloads should be isolated from the public internet.
For most multi-tier applications, these normally include:
- databases;
- caches;
- queues;
- background workers;
- internal APIs;
- monitoring endpoints;
- administrative interfaces;
- application backends that sit behind a public edge.
A common architecture is:
Internet ↓ Public web/API edge ↓ private network Application tier ↓ private network Database tier
This gives the application the connectivity it needs without creating a public endpoint for every backend component.
The same principle applies whether the backend is a self-managed VM or a managed service connected through a private path.
Private cloud network design should follow service relationships
A VPC is more useful when policy is expressed in terms of service roles.
| Source | Destination | Typical allowed flow |
|---|---|---|
| Internet | Public edge | HTTPS or required public protocol |
| Public edge | App VMs | Application port only |
| App VMs | Database | Required database port |
| App VMs | Cache/queue | Required internal service port |
| Workers | Database/queue | Required worker paths |
| Monitoring | Workloads | Health and metrics endpoints |
| Admin path | Servers | Approved SSH/RDP/admin traffic |
This is better than one broad rule that allows the entire private CIDR to reach everything.
A compromised application VM should not automatically receive unrestricted access to backup systems, unrelated databases, staging environments, or administrative services simply because they share private networking.
Use Cloud Firewall Best Practices for the rule-design layer.
How to isolate backend cloud workloads from the public internet
For a multi-tier application, isolation usually means removing direct public reachability from backend workloads and permitting only approved private sources.
A practical sequence is:
- Keep the public website/API endpoint reachable.
- Put application backends, databases, workers, caches, and queues on the VPC.
- Remove unnecessary public service ports from backend systems.
- Permit only the application tier to reach the database port.
- Permit only approved workers to reach queue or job-processing endpoints.
- Move SSH/RDP administration to a controlled path.
- Verify both IPv4 and IPv6 exposure where applicable.
- Test that required private paths still work after public exposure is reduced.
Private addressing is only part of the control. Authentication, application authorization, patching, secrets, and firewall policy still matter.
CIDR planning should happen before the network grows
Private IP ranges are easy to choose early and expensive to change after multiple systems depend on them.
RFC 1918 reserves these IPv4 ranges for private networks:
| Range | CIDR |
|---|---|
10.0.0.0 – 10.255.255.255 | 10.0.0.0/8 |
172.16.0.0 – 172.31.255.255 | 172.16.0.0/12 |
192.168.0.0 – 192.168.255.255 | 192.168.0.0/16 |
A team might reserve a production range such as:
10.20.0.0/16
and later divide the address plan conceptually:
10.20.10.0/24 application 10.20.20.0/24 database 10.20.30.0/24 workers/queues 10.20.40.0/24 monitoring/admin
This is only an example. The important requirement is to avoid accidental overlap with networks that may later need to connect.
Common overlap problems come from reusing the same range for:
- production and staging;
- office networks;
- VPN client pools;
- another cloud;
- MSP customer networks;
- a second environment that may later require routing.
If two networks that need to communicate use the same addresses, a future VPN or inter-network connection becomes more complicated.
Raff VPC CIDR ranges and overlapping networks
Raff currently documents VPC CIDR sizes from /16 through /28 using RFC 1918 private ranges.
Separate isolated VPCs can use overlapping CIDRs when they remain independent. That can be useful for keeping development, staging, or customer templates consistent.
However, if two networks may later need to connect through a VPN or another routed relationship, plan non-overlapping ranges from the beginning.
Isolation makes overlap possible; future connectivity determines whether overlap is wise.
Routing creates reachability, not authorization
Routing answers:
Where should packets for this destination go?
Security policy answers:
Should this source be allowed to use that path for this service?
Treat them as separate layers:
Route exists ↓ Firewall/security group permits source + port ↓ Service authenticates caller ↓ Application authorizes action
A route to a database subnet should not imply that every VM in the VPC can become a database client.
Likewise, a VPN route to production does not imply that every connected technician should receive administrative rights on every server.
NAT gives private workloads controlled outbound access
A private server may still need internet access for:
- operating-system updates;
- package repositories;
- external APIs;
- license servers;
- email providers;
- monitoring or telemetry.
A NAT or gateway pattern allows that outbound connectivity without requiring direct unsolicited public inbound access to the private VM.
Private workload ↓ outbound VPC gateway / NAT ↓ Internet
Raff currently documents NAT as part of the VPC gateway model together with DNS and DHCP.
NAT is not an authorization system. Review whether each workload needs general outbound internet access and restrict sensitive systems where the architecture requires it.
DNS and DHCP reduce manual network configuration
Multi-VM environments become easier to operate when internal services use predictable names and network settings do not depend on hand-maintained address configuration.
Internal service names such as:
db.production.internal cache.production.internal api.internal
make replacement and environment separation easier than embedding private IPs directly in application configuration.
Raff currently documents managed DNS and DHCP as part of its VPC gateway capabilities.
DNS still becomes a dependency. A healthy database can appear unavailable if the expected private name no longer resolves correctly.
One VPC does not have to mean one flat trust zone
A small application can start with one private network. It does not need complex segmentation simply because larger cloud architectures use many subnets.
Add stronger boundaries when there is a real difference in:
- trust;
- ownership;
- environment;
- routing;
- customer separation;
- security policy;
- recovery requirements.
Examples include:
- production vs staging;
- customer A vs customer B;
- application vs management;
- internet-facing vs sensitive data systems.
If the same simple policy works for all systems, extra segmentation may add operational complexity without meaningful benefit.
Development, staging, and production need deliberate separation
Teams sometimes put all environments into one private network because none of them is publicly exposed.
That can still create unnecessary trust.
Separate where appropriate:
- application credentials;
- database permissions;
- CI/CD identities;
- firewall rules;
- backup deletion rights;
- administrative paths.
A compromised development VM should not automatically gain a direct path to the production database.
Use Staging vs Production vs Development Environments for the broader environment model.
Windows and Linux workloads can share the same private architecture
A mixed environment may contain Linux application servers and Windows Server business workloads.
Example:
Public application edge ↓ VPC Linux app VM Windows business VM Database Internal file/service endpoint
Keep RDP and SSH administration separate from normal application traffic where possible.
Raff Windows VM can participate in the same VPC-based network model as Linux Cloud Servers.
For remote administration, use Bastion Host vs VPN vs Public SSH.
Load balancing changes the traffic boundary, not the trust model
When one application VM becomes an unacceptable capacity, deployment, or availability boundary, the architecture may add a traffic-distribution layer in front of several interchangeable application nodes.
Internet ↓ Traffic-distribution layer ↓ Private App VM 1 Private App VM 2 Private App VM 3 ↓ Private database/cache/queue
Before scaling this way, verify:
- application nodes can serve requests interchangeably;
- sessions are not unexpectedly tied to one node;
- durable uploads are not trapped on one VM disk;
- database connection capacity is adequate;
- readiness checks represent real service health;
- remaining nodes have enough capacity after one backend fails.
Raff's managed Load Balancer page is not treated here as a generally available dependency. Confirm current availability before designing around a managed product. The architecture works with any appropriate traffic-distribution implementation.
Use Load Balancing Explained for the detailed model.
Site-to-site VPN extends the VPC to another network
When an office, customer environment, or another approved network needs private access to Raff workloads, a site-to-site VPN can extend the network boundary without exposing every target service publicly.
Office / customer network ↓ site-to-site VPN Raff VPC ↓ Private application / Windows VM / service
Current Raff Site-to-Site VPN pricing is $20/month per tunnel. A remote-access VPN gateway is currently $15/month for up to 10 peers.
Verify the live pricing page when a commercial value affects a design decision.
MSPs should plan customer networks for future separation
For MSP and managed-IT workloads, address planning and administrator reachability become customer-isolation decisions.
Avoid architectures where:
- one flat VPC connects unrelated customers;
- technicians receive broad routes to all customers;
- the same administrative credential is reused across customer environments;
- overlapping networks are later expected to connect to one another;
- one automation token can modify several unrelated environments.
Prefer customer-scoped credentials, routes, network policy, and explicit offboarding.
Use Secure Remote Access for MSPs for the technician-access model.
Private networking does not automatically encrypt traffic
Network isolation and transport encryption solve different problems.
A private VPC path reduces who can route traffic to a service. It does not inherently mean the application payload is encrypted.
Use TLS or protocol-native encryption when:
- credentials or sensitive data cross service boundaries;
- policy requires encryption in transit;
- traffic crosses different trust zones;
- end-to-end protection matters to the application.
Private should mean controlled reachability, not implicit trust.
Recovery planning must include the VPC configuration
A restored VM is not a recovered service if its network relationships are missing.
Record:
- VPC name and CIDR;
- expected service names;
- route relationships;
- security-group/firewall rules;
- gateway/NAT requirements;
- VPN relationships;
- administrative paths;
- public edge/backend relationships.
After recovery, verify:
- Resources are attached to the expected VPC.
- Internal DNS names resolve.
- Required private ports are reachable.
- Unnecessary public ports remain closed.
- Applications can reach databases, caches, and queues.
- Administrators can reach systems through the intended path.
- VPN-connected networks can reach only approved resources.
Use Cloud Snapshots vs Backups for the recovery-copy layer.
How Raff VPC fits a multi-VM application
Raff VPC is Raff's current private-networking foundation.
Current facts used in this guide are:
- VPC is free;
- private VPC traffic is unmetered;
- Raff documents
/16through/28private CIDR sizes; - the VPC gateway currently includes NAT, DNS, and DHCP;
- stateful security groups provide per-VM network policy;
- separate VPCs can use overlapping CIDRs when they remain isolated;
- Site-to-Site VPN is available for network-to-network connectivity.
A practical Raff architecture can evolve gradually:
Stage 1 Public Raff VM → application Stage 2 Public application VM ↓ Raff VPC Private database / worker Stage 3 Traffic-distribution layer ↓ Private application nodes ↓ Raff VPC Private database / cache / workers Stage 4 VPN or another controlled network connection → only when an external private network genuinely needs access
Use Raff Cloud Servers for compute, Windows VM for Windows workloads, Managed Databases when the data layer should be operated separately, Security for Raff's current security surface, and Data Protection for VM recovery planning.