Rubrik Security Cloud can make a complicated protection estate look pleasantly small. Log in once, see protected workloads across platforms, assign SLA Domains, monitor activity, and start recovery operations. That is exactly what a centralized management layer should do.
The trouble starts when that screen gets turned into the architecture diagram.
If a design review shows Applications -> Rubrik Cloud and stops there, I still do not know what reads a vSphere VM, which network carries the backup traffic, where the protected copy lives, what crosses a WAN or cloud boundary, or what has to work when that VM needs to come back. I also do not know whether those answers apply to an AWS workload or Microsoft 365. They often do not.
Rubrik's own current documentation separates Data Center protection, which is protected by a Rubrik cluster, from Cloud protection provided by Rubrik Cloud-Native protection. It also defines infrastructure separately, including Rubrik clusters and Rubrik Cloud Vault. SLA Domains express protection intent across frequency, retention, replication, and archival, but that policy still has to be executed by real infrastructure somewhere.[1][2]
The architecture work begins after the policy is defined.
What RSC controls, and what still has to execute
RSC is the common management surface. Current Rubrik APIs expose protected workloads, SLA Domains, clusters, snapshots, activity, reporting, recovery operations, and administrative controls through the RSC service. The SLA model can be applied across different workload types while RSC provides a consistent place to inventory and operate them.[1][2][3]
That consistency is useful, but it can hide implementation differences. A policy assignment is not the component reading blocks from a hypervisor. An inventory screen is not the network carrying backup traffic. A recovery button is not the datastore receiving an exported VM.
I would separate the design into two questions during review:
- What does RSC define, authorize, monitor, or orchestrate?
- Which workload-side, Rubrik-side, cloud-side, and destination components actually perform the protection or recovery operation?
The second question changes with the workload.
Follow the workload, not the portal
Three current Rubrik protection models make the point better than a generic diagram ever will.
vSphere: a Rubrik cluster is still part of the protection system
For VMware vSphere, Rubrik documents API-driven protection and recovery around registered vCenter infrastructure and a Rubrik cluster. Standard VM backups are taken at the hypervisor. The RSC object model associates the VM with a Rubrik cluster, and recovery operations use real vSphere compute, host, datastore, and network objects.[4]
That gives the architect a concrete set of components to map. The source VM and ESXi infrastructure exist on one side. The Rubrik cluster participates in protection and holds or serves protected data. vCenter remains part of inventory and recovery coordination. Replication or archival, when configured in the SLA Domain, adds a destination and another traffic flow.[2][4]
Recovery changes the route again. Rubrik's current vSphere guidance distinguishes Live Mount, which serves a VM from Rubrik backup storage, from Export, which hydrates a new VM onto the selected vSphere datastore. Export requires a target compute location and storage location. Live Mount can also require deliberate network handling so a recovered VM does not collide with production.[4]
A diagram that only shows the RSC service misses the components that will decide whether the backup completes and whether the recovery meets its RTO.
AWS cloud protection: the same RSC experience can sit over different infrastructure ownership
Rubrik's current AWS cloud protection model makes the separation even clearer. In September 2026, Rubrik documented two deployment models: customer-hosted protection and Rubrik Managed Cloud Protection. Both use the same RSC policy engine and recovery experience, but the compute, storage, account boundary, and operational responsibility underneath them differ.[5]
Rubrik describes Exocompute as the compute layer that reads snapshots, processes data, and moves it to protected storage. In the customer-hosted model, Exocompute runs in the customer's AWS account. The customer owns the account boundary, networking, IAM, and surrounding security posture, and the backup storage can be customer-owned or Rubrik Cloud Vault. In the managed model, Rubrik runs Exocompute and the vault in Rubrik's environment, while the customer establishes the required cross-account access.[5]
The RSC screen is intentionally consistent across those choices. The network and trust design is not.
If I am reviewing the customer-hosted model, I want the AWS account, VPC and subnet placement where applicable, IAM roles, storage location, routing, security controls, and connectivity represented. If I am reviewing the Rubrik-managed model, I want the cross-account trust, data movement out of the protected account, managed vault location, and recovery dependencies represented. The management experience does not tell me which one was selected.
Microsoft 365: the protected application is SaaS, but the protection system still has infrastructure
Microsoft 365 is a useful counterexample because there may be no local hypervisor, repository, or backup VLAN at all. Rubrik's current Microsoft 365 architecture paper describes RSC as the control and management plane, with a separate Exocompute data plane running on Azure Kubernetes Service in a Rubrik-managed Azure account. That data plane processes backup and recovery API operations, indexing, and encryption, and it pulls Microsoft 365 data into customer-specific Azure storage managed by Rubrik.[6]
The source application is SaaS. The protection work still runs somewhere. The backup data still lands somewhere. Authentication and API permissions still matter. Microsoft API behavior and Azure-hosted protection services become part of the design instead of ESXi, a local cluster, and a datastore.[6]
Rubrik's current Microsoft 365 deployment documentation explicitly supports two data plane modes. In Rubrik-hosted mode, the data plane runs in an Azure account hosted by Rubrik. In customer-hosted mode, it runs in an Azure account hosted by the customer. RSC remains the centralized control plane in both cases, so the selected deployment model has to be identified before anyone can draw the dependencies correctly.[7]
Backup traffic still has an address
Centralized SaaS management can make network discussions drift toward browser access and outbound connectivity to RSC. Those connections matter, but they are not the whole backup network.
For a vSphere workload, the architect still needs to know which Rubrik cluster protects the VM, how the hypervisor and cluster reach one another, and where the protected copy is stored. If the SLA Domain replicates or archives snapshots, those flows leave the primary protection environment for another destination. During an Export recovery, protected data has to be hydrated onto the selected vSphere storage.[2][4]
For AWS cloud protection, compute and storage placement depend on the selected deployment model. Customer-hosted protection puts more of the network and account boundary in the customer's design. Rubrik Managed Cloud Protection moves those components into Rubrik's environment and uses cross-account access to the protected AWS environment.[5]
For Microsoft 365, the protection flow is between Microsoft 365 services and the Azure-based Exocompute and storage architecture Rubrik documents for that service. Microsoft identity, application permissions, APIs, and the hosted protection environment matter in a way that a vSphere backup network does not.[6]
This is why I do not start a Rubrik network review with a generic port matrix. I start with arrows.
Draw the protection flow. Draw replication separately. Draw archival separately. Draw recovery separately. Then determine which VLANs, routes, firewalls, WAN links, cloud constructs, service endpoints, and trust boundaries those arrows actually cross.
A firewall rule can be technically correct and the architecture can still be wrong because the link behind it is undersized, the route crosses an unexpected failure domain, or the recovery flow depends on infrastructure nobody included in the DR design.
A healthy RSC session does not benchmark the backup system
A responsive RSC interface proves that the management service is responding to the user. It does not prove that ESXi source reads are healthy, that a Rubrik cluster is ingesting at the required rate, that Exocompute has the cloud resources it needs, that an archive destination is keeping up, or that a recovery datastore can accept data fast enough to meet the RTO.
Those are different systems doing different work.
On vSphere, the recovery modes make the distinction easy to see. Live Mount serves a VM from Rubrik backup storage. Export copies the data to a target datastore. The performance envelope and infrastructure involved are different even though both operations are launched through the same RSC-oriented management model.[4]
The AWS example is similar. The same RSC policy experience can sit above customer-hosted compute and storage or Rubrik-managed compute and vault services. Troubleshooting a slow operation starts with the deployment model and the components participating in that operation, not with the assumption that the SaaS management layer is the bottleneck.[5]
Operational view When a backup or recovery operation is slow, map the operation to its source, execution component, storage destination, and network path before assigning the problem to RSC. Use RSC events and job state as evidence, then troubleshoot the infrastructure that is actually moving or serving the data.
Availability is a dependency matrix, not a product checkbox
The same discipline applies to failure scenarios. I would not put a sentence such as "backups continue if RSC is unavailable" into a design document unless Rubrik documents that behavior for the exact workload and deployment model being reviewed, or the team has tested it and recorded the result.
Rubrik exposes cluster connection state through RSC APIs. The API exposes status and connectivity fields, including connection timestamps and connectivity checks, which gives the architecture a concrete state to account for. It still does not establish one universal disconnected-mode behavior across vSphere, AWS cloud-native protection, Microsoft 365, databases, SaaS applications, and every other supported workload.[3][8][9]
For each protected service, build a small dependency matrix around the operations you care about:
| Operation | Dependencies to identify |
|---|---|
| Scheduled protection | Source platform, protection execution component, protected storage, required control connectivity, authentication, network path |
| Policy change | RSC access, authorization, workload or cluster connectivity required to apply the change |
| Replication or archive | Source copy location, destination, WAN or cloud connectivity, credentials or service permissions |
| Recovery | Recovery point location, execution component, target platform, target storage, target network, authentication, DNS and application dependencies |
Do not fill unknown cells with assumptions. If the documentation is model-specific or silent on a failure mode, make the failure test part of acceptance.
That is much more useful than treating "Rubrik" as one availability object.
Recovery redraws the architecture
Backup diagrams have a bad habit of ending at the protected copy. That is only half of the system.
Rubrik's vSphere recovery documentation is explicit about the physical resources recovery can require. Live Mount can run a recovered VM from Rubrik storage. Export needs the destination compute, host, datastore, and network information and copies the VM onto that selected storage. Those are recovery dependencies that may not sit on the same network path or even in the same failure domain as the original protection traffic.[4]
Microsoft 365 recovery follows a completely different model. Rubrik's documented data plane handles recovery API processing and uses the Microsoft 365 service, identity permissions, and the hosted Azure protection environment. There is no vSphere datastore to hydrate, but there are still external services and permissions that have to work.[6]
AWS again depends on which cloud protection deployment was selected. Customer-hosted and Rubrik-managed models place compute, storage, network responsibility, and trust boundaries differently even though the recovery operation is presented through the same RSC experience.[5]
The recovery diagram should answer a different set of questions than the backup diagram: Where is the selected recovery point now? What has to read it? Where is the destination? Which network carries the restore traffic? Which identity system authorizes the operation? Which target storage and compute services have to be healthy? Does DNS need to change? Is an isolated recovery network required before the workload is allowed near production?
If those answers are missing, the design describes data protection, not recovery.
Security still crosses the layers
RSC centralizes important administrative controls. Rubrik exposes role-based access control for users and service accounts through RSC, and its API guidance recommends least-privilege roles for service accounts.[10][11]
That does not collapse every trust boundary into RSC. The vSphere design includes access to vCenter and recovery targets. AWS protection can include customer IAM, cross-account roles, VPC or account boundaries, and cloud storage depending on the deployment model. Microsoft 365 uses Entra enterprise applications and service principals to authorize access to Microsoft 365 APIs.[4][5][6]
The architecture therefore needs both the administrative trust model and the infrastructure trust model. They overlap, but they are not the same thing.
I would keep this review focused on who or what can initiate operations, which credentials or roles let the protection system reach the workload, which network boundaries isolate protected data, and what authorization is required to recover. Deeper separation of production and recovery authority deserves its own design review rather than being reduced to a paragraph here.
The architecture review I would run
For every protected workload or workload class, I want the design team to be able to answer these questions without opening the RSC UI and guessing from what is visible there:
- Where is the protection policy defined?
- What actually reads or processes the workload data?
- Where does the backup traffic go?
- Where is the protected copy stored?
- What network carries the protection traffic?
- Where does replication traffic go, if replication is configured?
- Where does archive traffic go, if archival is configured?
- Which external services, identities, APIs, or cloud resources are required?
- What happens to protection and management operations when WAN, internet, or service connectivity is lost?
- What infrastructure must be available to recover the workload?
- Where does restore or recovery traffic travel?
- Which dependencies sit outside Rubrik itself?
I would add one more requirement to the review: every answer should name a component or a verified behavior. "Rubrik handles it" is not an architecture answer.
A vSphere VM, an AWS workload, and a Microsoft 365 tenant can all be governed from RSC. They can also have completely different protection execution points, storage locations, network flows, permissions, and recovery dependencies. The management plane is supposed to make those systems easier to operate. The design still has to show what actually has to work underneath it.
Source Notes
Product behavior changes. These sources were checked against public Rubrik documentation and technical material available on September 29, 2026.