Private cloud networking for MSPs should make each customer a clear network, identity, recovery, and operational boundary—not merely give each workload a private IP. For managed production clients, the MSP should be able to explain which resources belong to the customer, which routes exist, which technicians and automation identities can enter, how shared services reach the environment, and how the entire boundary is isolated or removed without affecting another client.
For Raff Technologies workloads, a practical default is to use a dedicated Raff VPC per managed production client when clear customer separation matters, then add only the public edge, private service paths, administrative routes, peering, VPN connectivity, and managed-service endpoints that the client actually needs.
A useful MSP rule is:
If Client A can be isolated, recovered, audited, and offboarded without changing Client B, the network boundary is doing useful operational work.
This guide owns the MSP-specific decision. For broader VPC, CIDR, NAT, DNS, routing, and multi-VM design, use VPC Architecture for Multi-VM Applications.
MSP private networking: quick decision framework
| Decision | Strong default for managed production |
|---|---|
| Customer network boundary | Separate VPC or equivalent private network per client |
| Client-to-client traffic | Deny by default |
| Public exposure | Only services that genuinely require internet reachability |
| Technician access | Named identity through client-scoped VPN, bastion, or controlled admin path |
| Automation | Client- or task-scoped credentials |
| Monitoring | Shared where useful, but tenant-aware and least privilege |
| Backups and recovery | Client-specific restore scope and deletion authority |
| Office / branch connectivity | Site-to-site VPN where private network-to-network access is required |
| Shared services | Explicit peering/private endpoint path, not accidental flat routing |
| Offboarding | Remove routes, credentials, DNS, monitoring, recovery access, and retained data deliberately |
The goal is not maximum segmentation. It is the smallest network model that the MSP can explain commercially, operate consistently, and contain during an incident.
A private IP is not the same as client isolation
A private IP changes reachability. It does not prove that one customer is separated from another.
Real MSP client isolation combines:
- network ownership;
- routing boundaries;
- firewall or security-group policy;
- named administrator identities;
- automation credentials;
- logging scope;
- monitoring access;
- backup and restore permissions;
- incident containment;
- offboarding controls.
For example, two clients can have different private subnets and still share too much risk if:
- one technician VPN reaches both without client-specific authorization;
- one API key can modify both environments;
- one bastion stores credentials for every customer;
- a shared monitoring account exposes all logs and metrics;
- a recovery operator can restore one customer's data into another customer's environment;
- broad peering creates unintended routes.
The MSP should therefore test the whole trust path, not only the addressing plan.
Separate VPCs are usually the clearest production-client boundary
A separate VPC per managed production client makes ownership easier to reason about:
MSP management plane | +--> approved admin path --> Client A VPC | +--> approved admin path --> Client B VPC | +--> approved admin path --> Client C VPC Client A VPC -X- Client B VPC Client B VPC -X- Client C VPC
This is especially useful when:
- clients have different administrators;
- customers run different security policies;
- one client may later need office or branch connectivity;
- incident containment must remain customer-specific;
- a customer needs separate audit evidence;
- offboarding should remove one environment cleanly;
- the MSP sells a dedicated network boundary as part of the service.
A separate VPC is not automatically a dedicated infrastructure stack. Compute, managed services, monitoring, and other platform components can still be provider-operated. The useful promise is narrower: the customer's private network and routes have a distinct ownership boundary.
Shared networks can work, but only when the service is standardized
A shared private network can be operationally efficient for lower-risk or highly standardized services.
It is more defensible when:
- the MSP owns all deployments;
- clients do not receive network administration;
- workloads follow one service template;
- tenant routes are constrained by policy;
- identities and credentials remain client-scoped;
- logs, backups, and monitoring preserve tenant boundaries;
- the contract does not promise a dedicated client network.
Shared infrastructure becomes risky when segmentation exists only in documentation.
A useful test is:
Can Client A reach Client B? Can Client A credentials affect Client B? Can Client A restore or automation jobs target Client B? Can a technician support Client A without broad access to Client B?
If those answers depend on convention rather than enforced controls, the network is not meaningfully tenant-aware.
MSP service tiers should map to real network boundaries
Commercial tiers are easier to defend when the technical difference is visible.
| Service tier | Example network boundary |
|---|---|
| Standard managed | Shared platform with enforced client segmentation |
| Isolated client network | Separate VPC, client-scoped routes and credentials |
| Dedicated managed environment | Separate VPC plus stronger compute, admin, recovery, and lifecycle boundaries |
The names are commercial choices. The technical description must remain precise.
Do not sell “dedicated” when only the subnet name changes but:
- administrator credentials remain shared;
- routes remain broadly connected;
- backups share unrestricted restore permissions;
- the same automation identity controls all customers;
- incident containment still requires MSP-wide network changes.
A stronger service tier should correspond to a real increase in isolation, ownership, support scope, or operational independence.
The management plane is the highest-value shared boundary
MSPs often centralize:
- technician access;
- monitoring;
- logging;
- backups;
- automation;
- configuration management;
- ticketing and operational tooling.
That management plane may need approved paths into several customer environments, which makes it one of the most privileged parts of the architecture.
Named technician / automation identity ↓ MSP management plane ├─ explicit path → Client A VPC ├─ explicit path → Client B VPC └─ explicit path → Client C VPC
Protect it with:
- named human identities;
- separate machine identities;
- client-specific groups or policy;
- no universal SSH key or Windows password;
- client-scoped routes;
- target-level firewall rules;
- audit logs tied to technician and customer;
- break-glass access that is exceptional rather than routine;
- an incident procedure for isolating the management layer itself.
Use Secure Remote Access for MSPs for the technician-entry decision.
Network reachability and authorization must remain separate
A route only creates a path. It does not prove the caller should be allowed to use the service.
A safer model is:
Route exists ↓ Firewall/security group allows required source + port ↓ Service authenticates identity ↓ Application authorizes action
This matters for:
- SSH and RDP;
- databases;
- monitoring endpoints;
- backup systems;
- internal dashboards;
- management APIs;
- shared services.
A technician who can reach a customer subnet should not automatically become local Administrator, root, database admin, or backup-delete operator.
For rule design, use Cloud Firewall Best Practices.
Shared monitoring and logging must remain tenant-aware
Running one observability stack for every customer can create unnecessary operating overhead. Shared monitoring is reasonable when the data and permissions remain customer-scoped.
Record enough context to identify:
- client;
- environment;
- workload;
- region/network;
- severity;
- owner.
Then control who can query or modify:
- dashboards;
- logs;
- alert rules;
- monitoring credentials;
- notification routes.
A technician investigating Client A should not need unrestricted access to Client B telemetry.
Observability can become a cross-client data leak even when the underlying VPCs are isolated correctly.
Backup and recovery paths must respect the same client boundary
Recovery is another privileged network and identity path.
For each client, document:
- protected workloads;
- recovery-point ownership;
- backup credentials;
- restore permissions;
- recovery destination;
- deletion authority;
- retention responsibility;
- who validates the recovered application.
A separate client VPC is useful during recovery because restored systems can return into a known customer-specific network boundary rather than an MSP-wide shared environment.
For Raff VM backups, the current restore behavior is in-place, so an MSP should distinguish the production restore path from an isolated rebuild or recovery exercise. Use Restore Testing Checklist for Production VMs for that workflow.
Windows and RDP workloads need the same isolation model
MSPs frequently manage Windows Server workloads for:
- accounting and finance software;
- IIS and .NET applications;
- Microsoft SQL Server;
- line-of-business applications;
- file services;
- RDP-based administration.
A stronger pattern is:
Named technician ↓ controlled VPN / bastion / private access Client-specific VPC ↓ Windows VM ↓ private path Database / internal service
Do not treat a public RDP endpoint as the customer boundary.
Keep these controls separate:
- named Windows identities;
- least-privilege local Administrators membership;
- Network Level Authentication where supported;
- patching;
- client-specific credentials;
- route/firewall restrictions;
- access review and offboarding.
Raff Windows VM can use VPC for private service-to-service and administrative paths.
CIDR planning becomes important when customers connect external networks
Customer networks often start isolated and later connect to:
- an office;
- a branch;
- a VPN address pool;
- another cloud;
- an acquired network;
- a vendor environment;
- a disaster-recovery environment.
Maintain a simple address registry with:
- client;
- environment;
- VPC CIDR;
- office/branch ranges;
- VPN ranges;
- MSP management ranges;
- other-cloud ranges;
- owner;
- future connection notes.
Overlapping private address ranges may be harmless while environments remain isolated, but they complicate routing when networks must connect later.
Plan for future connectivity before the first site-to-site tunnel is requested.
Site-to-site VPN extends the private boundary without publishing services
When a customer office, data center, or another cloud must reach private workloads, a site-to-site VPN can extend the private network:
Customer office / another cloud ↓ encrypted tunnel Client Raff VPC ↓ Private application / Windows VM / internal services
The tunnel creates a private path. It does not eliminate the need for:
- source/destination policy;
- firewall rules;
- identity controls;
- route ownership;
- logging;
- incident procedures.
Raff currently documents WireGuard and IPsec site-to-site connectivity through its VPC networking model. Verify the live VPC, Site-to-Site VPN, and pricing pages before quoting implementation limits or commercial values to a client.
VPC peering should be explicit, not a shortcut to a flat MSP network
Peering can connect private networks when shared services genuinely need it.
Examples include:
- central monitoring collectors;
- a shared build system;
- a shared service VPC;
- approved internal APIs.
But peering should not become “connect every customer to the management VPC and allow everything.”
For each peering relationship, define:
- business reason;
- allowed traffic;
- route ownership;
- source and destination services;
- firewall rules;
- identity used by the shared service;
- removal condition.
The right model is shared service access, not shared trust.
Private service endpoints reduce unnecessary public exposure
Managed databases, applications, functions, or other provider services may support private service connectivity.
Raff VPC currently documents private endpoints for supported managed services through its PrivateLink model. This can let a client workload reach supported services without sending that connection over a public path.
For an MSP, the operational benefit is cleaner ownership:
Client workload ↓ private endpoint Managed service
instead of creating public access rules simply because the database or platform service is managed by the provider.
Private service connectivity still needs application credentials and least-privilege access. A private path does not replace authentication.
Incident response should be possible per customer
A useful design test is:
Can we isolate Client A without interrupting Client B?
The answer may require the ability to:
- block a public edge;
- disable a compromised route;
- remove a VM from permitted network paths;
- revoke client-specific automation credentials;
- disable an admin VPN path;
- rotate customer credentials;
- restore the client into a clean boundary;
- preserve evidence without exposing other customers.
If a shared component cannot be restricted per customer, one incident can become an MSP-wide event.
Offboarding proves whether the architecture really has ownership boundaries
Onboarding creates trust. Offboarding must remove it.
A complete client offboarding process should address:
- data export;
- route and peering removal;
- VPN removal;
- firewall/security-group cleanup;
- human account revocation;
- automation credential revocation;
- DNS transition;
- monitoring and log access;
- backup retention or deletion;
- evidence that MSP administrative access has ended.
A customer network that cannot be removed cleanly was probably too entangled with the MSP's shared environment.
MSP networking economics include operations, not only provider charges
A separate VPC can simplify customer ownership even when the provider's network layer itself is inexpensive.
The real MSP cost model also includes:
- address planning;
- route and firewall administration;
- VPN configuration;
- technician access;
- monitoring;
- incident response;
- documentation;
- restore testing;
- offboarding;
- client-specific exceptions.
This matters commercially.
A customer that requires:
- a separate VPC;
- site-to-site connectivity;
- dedicated admin paths;
- customer-specific firewall review;
- restore validation;
- audit evidence;
is buying more operating work than a standardized shared-network client.
Price the managed service around the boundary and support obligation, not only the infrastructure line item.
How Raff VPC fits an MSP client-isolation model
Raff VPC is the current private-network foundation for Raff workloads.
The current public product model includes:
- isolated VPC networking;
- stateful security groups;
- managed gateway services such as NAT, DNS, and DHCP;
- VPC peering;
- private endpoints for supported managed services;
- Site-to-Site VPN connectivity;
- API, CLI, and Terraform support for network automation.
Those capabilities let an MSP build repeatable customer boundaries without hard-coding every current limit or price into an evergreen architecture guide.
A practical pattern is:
MSP technician / automation ↓ approved client-scoped access Client A Raff VPC ├─ public edge only where required ├─ private application services ├─ private database / managed-service paths └─ client-specific recovery access Client B Raff VPC ├─ public edge only where required ├─ private application services ├─ private database / managed-service paths └─ client-specific recovery access
Use Raff Cloud Servers and Windows VM for compute, Security for Raff's current security controls, IAM for account and permission management, Managed Databases where the data layer should have separate operational ownership, and Data Protection for VM recovery workflows.
Raff provides the infrastructure building blocks. The MSP still owns customer-specific routing, technician access, OS-level permissions, application credentials, monitoring scope, recovery procedures, and offboarding.
