Private cloud networking for MSPs is the design of isolated client network boundaries, controlled administrative paths, and explicit traffic rules across the cloud environments an MSP operates.
For most managed production clients, a separate private network is the clearest default because it keeps routing, firewall policy, credentials, recovery, and incident containment easier to explain per customer. Shared networks can still work for standardized lower-risk services, but only when segmentation is enforced rather than implied.
Raff Technologies supports more than 3,000 customers and 15,000 deployed VMs. In MSP infrastructure reviews, the recurring problem is not simply whether a workload has a private IP. It is whether the provider can explain which technicians, services, routes, automation credentials, and recovery systems can cross each client boundary.
This guide focuses on that MSP-specific isolation decision. For the wider networking architecture, start with the Cloud Networking Guide. For VPC, CIDR, routing, NAT, and private-service fundamentals, use VPC Architecture for Multi-VM Applications.
Private networking must create a real client boundary
A private IP address does not prove that two clients are isolated.
Real isolation combines several controls:
- separate network or address-space ownership;
- explicit routing relationships;
- deny-by-default client-to-client traffic;
- firewall or security-group policy;
- named administrator identities;
- client-scoped automation credentials;
- tenant-aware monitoring and logs;
- backup and restore boundaries;
- documented onboarding, incident, and offboarding procedures.
The useful test is simple: can the MSP identify every legitimate path into a client environment and remove or isolate one client without affecting another?
A practical traffic model may look like this:
| Source | Destination | Expected relationship |
|---|---|---|
| Public internet | Client edge | Required public service ports only |
| Client edge | Client app tier | Private application traffic |
| Client app | Database or cache | Required service ports only |
| MSP management | Client admin endpoints | Approved management protocols only |
| Monitoring | Client workloads | Metrics and health paths only |
| Backup systems | Client data | Documented backup and restore flows |
| Client A | Client B | Denied by default |
| Staging | Production | Denied unless explicitly required |
The recurring failure is rarely the total absence of private networking. It is a network that grew without ownership: temporary routes remain permanent, one management subnet reaches several customers, or shared credentials make it difficult to identify who can cross a boundary.
Network segmentation and client isolation are related, but not identical
Network segmentation divides infrastructure into smaller trust zones. Client isolation is the stronger operational requirement that one customer's systems, identities, routes, logs, and recovery paths cannot unintentionally cross into another customer's environment.
Segmentation can support client isolation, but a VLAN, subnet, security group, or private CIDR alone is not enough if:
- the same administrator credential works across every customer;
- a shared automation token can modify all environments;
- monitoring or backup systems have unrestricted cross-client access;
- broad routes connect otherwise separate networks;
- restore procedures can recover Client A data into Client B resources;
- offboarding leaves keys, routes, DNS records, or backups behind.
For an MSP, network segmentation should therefore be designed together with identity, automation, logging, backup, and offboarding controls.
The client isolation framework separates shared, isolated, and dedicated models
The decision should follow workload risk, operational scale, contractual requirements, and the consequences of a routing or credential error.
| Model | Appropriate when | Main advantage | Main trade-off |
|---|---|---|---|
| Shared private network with enforced segments | Workloads are standardized and lower risk | Highest operating efficiency | Policy mistakes can widen cross-client reach |
| Separate private network per client | Managed production clients need clear boundaries | Easier isolation, review, and offboarding | More address and policy administration |
| Shared management plane plus isolated client networks | MSP needs repeatable operations across customers | Centralized tooling with client-specific networks | Management plane becomes privileged cross-client infrastructure |
| Dedicated infrastructure per client | Contract, risk, ownership, or maintenance requires stronger separation | Clearest customer-specific boundary | Higher cost and duplicated operations |
Choose a shared segmented network when the MSP controls deployment, clients do not require direct administration, workloads are highly standardized, and client-to-client policy can be tested consistently.
Choose a separate private network when the environment is production-critical, customer data has a distinct ownership boundary, administrators differ by client, or one client must be isolatable without changing others.
Choose dedicated infrastructure when the customer requires independent resource ownership, maintenance windows, recovery procedures, or commercial separation beyond a logical private network.
A stronger service tier should correspond to a real technical boundary. A “dedicated” label is not meaningful if management credentials, routing, recovery, and operating procedures remain effectively shared.
Separate VPCs are usually the clearest MSP customer boundary
For many MSPs, one VPC or equivalent private network per production customer provides the clearest operational model.
MSP management plane | +--> approved path --> Client A VPC | +--> approved path --> Client B VPC | +--> approved path --> Client C VPC Client A VPC -X- Client B VPC Client B VPC -X- Client C VPC
The important part is not the number of VPCs. It is that routes, credentials, firewall rules, logs, backup scope, and administration can all be reasoned about per customer.
A separate VPC becomes especially useful when:
- each client has different administrators;
- the client may later require site-to-site VPN access;
- customer workloads have different security rules;
- offboarding must remove one environment cleanly;
- one incident must be contained without changing unrelated customers;
- the MSP needs customer-specific audit evidence.
The management plane creates the largest shared privilege boundary
Monitoring, backup, automation, logging, bastion hosts, VPN gateways, and credential systems often need access to several client environments.
That makes the management plane one of the most sensitive parts of an MSP architecture.
Named MSP administrator ↓ controlled identity and access path MSP management plane ├─ approved route → Client A private network ├─ approved route → Client B private network └─ approved route → Client C private network
The management plane should not gain unrestricted client access simply because it is operated by the MSP.
Use:
- named human identities;
- separate machine identities for automation;
- client-specific routes or gateway policy;
- firewall or security-group rules after network entry;
- no universal SSH key, Administrator password, or API token;
- logs tied to technician and client;
- explicit break-glass access;
- an isolation procedure for a compromised management component.
Administrative access should also remain separate from customer-facing traffic. A client may expose HTTPS publicly while SSH, RDP, database administration, monitoring, and recovery systems remain private.
Use Secure Remote Access for MSPs for the bastion, VPN, and zero-trust decision, and User Access Review for Cloud Servers for recurring permission reviews.
Shared services must preserve tenant-aware identity and data boundaries
MSPs often centralize services because running one monitoring or backup stack per customer may be inefficient. Shared services can be reasonable when they preserve client-level scope.
For monitoring and logging, the system should identify the client, environment, workload, and severity. A technician investigating Client A should not require broad access to Client B data merely because both use the same platform.
For backups, define per client:
- protected systems and data;
- backup credentials;
- retention;
- restore permissions;
- recovery destination;
- deletion authority;
- offboarding treatment.
For automation, scope credentials by client or task. One deployment token should not automatically create, modify, and delete resources across the complete MSP estate.
For DNS and service discovery, use client- and environment-specific names. Avoid internal naming patterns that make accidental cross-client discovery easier.
Network reachability and application authorization should remain separate. A monitoring collector that can reach a client VM should still authenticate to the exact service it needs.
Windows and RDP environments need the same client isolation model
MSPs frequently manage Windows Server workloads for accounting software, IIS, SQL Server, line-of-business applications, file services, and Remote Desktop access.
A cleaner pattern is:
Named technician ↓ controlled VPN/bastion path Client-specific VPC ↓ Windows VM ↓ private path Database / internal service
Do not rely on a public RDP endpoint as the customer boundary. Keep named Windows identities, least-privilege Administrator membership, Network Level Authentication where supported, patching, and client-specific credentials as separate controls.
For Raff Windows workloads, use Windows VM together with VPC when the client environment needs private service or administrative paths.
Address planning determines whether customer networks can connect later
MSP private networks frequently become connected later to offices, VPN pools, another cloud, a third party, or an acquired environment. CIDR planning therefore matters before the first client integration request arrives.
Maintain a simple registry containing:
- client and environment;
- network CIDR;
- connected office or VPN ranges;
- management-network range;
- third-party or other-cloud networks;
- owner;
- expected future connections.
Overlapping private ranges are harmless while networks remain completely isolated, but they can complicate future peering or VPN connections. Plan connected networks to avoid overlap where possible.
When a customer later needs network-to-network access, Site-to-Site VPN can extend the private boundary instead of publishing internal services to the internet.
Incident response should be possible per client
Isolation also has to work during failure.
A useful incident question is:
Can the MSP isolate Client A without interrupting Client B?
That may require:
- blocking management access;
- disabling a public edge;
- removing a compromised VM from private routes;
- rotating client-specific credentials;
- revoking automation tokens;
- isolating a VPN path;
- restoring the workload into a clean network.
A shared service that cannot be restricted per customer can turn one client incident into an MSP-wide incident.
Offboarding should remove every trust path deliberately
Offboarding should remove trust as deliberately as onboarding created it.
Define:
- final data export;
- route and VPN removal;
- firewall/security-group cleanup;
- administrator and automation credential revocation;
- DNS transition;
- monitoring and logging cleanup;
- backup retention or deletion handling;
- evidence that the MSP no longer retains administrative access.
A network architecture is easier to trust when the customer can be cleanly isolated, recovered, and removed without broad changes to unrelated environments.
Raff VPC supports per-client network isolation
Raff VPC provides the current private-network foundation for Raff workloads.
Current facts relevant to MSP design are:
- VPC traffic is private and unmetered;
- VPC itself has no separate VPC charge;
- private IPv4 CIDRs can be used to organize client-specific address space;
- NAT, DNS, DHCP, security policy, peering, and private-service patterns can support multi-VM designs;
- Site-to-Site VPN can connect customer or office networks to a Raff environment;
- a Raff remote-access VPN gateway is currently $15/month for up to 10 peers;
- Site-to-Site VPN is currently $20/month per tunnel.
An MSP can use separate VPCs for customer boundaries:
MSP management access ↓ approved gateway or admin path Client A Raff VPC ├─ public application edge ├─ private application services └─ private data and recovery paths Client B Raff VPC ├─ public application edge ├─ private application services └─ private data and recovery paths
Raff Security provides the surrounding network-security controls, while Raff VM and Windows VM provide compute for customer workloads, bastions, management roles, and utility services. IAM and API keys should be scoped so automation and technicians do not receive broader access than the customer or task requires.
For recovery, Data Protection should also follow client boundaries. Restore rights, backup deletion authority, and target environments should not become an accidental cross-client privilege path.
Raff does not define the MSP’s operating model. The provider still owns technician permissions, client-specific routes, VPN or bastion configuration, application credentials, backup scope, incident procedures, and offboarding.
For an MSP, the useful product question is therefore not simply “Does the provider offer private networking?” It is:
Can we map one customer to a clear private boundary, restrict who can enter it, recover it independently, and remove that boundary without disturbing the rest of the estate?