A green backup status in the cloud tells me protected objects have recovery points. It does not tell me the application can be rebuilt in another account, subscription, region, or cluster.
Rubrik Security Cloud has useful cloud-native recovery primitives. For AWS, RSC can protect EC2 instances and EBS volumes with native cloud snapshots, replicate recovery points across accounts and regions, restore an existing EC2 instance, export a snapshot as a new instance, and recover files.[1][2][3][4] Azure virtual machines and managed disks have similar restore, export, mount, and file-recovery options.[5][6] RSC separately protects cloud database services such as Amazon RDS and Azure SQL, and Kubernetes protection sets can include namespace-scoped resources and persistent volumes.[7][8][9]
Those capabilities recover data and workload objects. Application recovery starts when the team has to reconnect those objects to networks, identity, encryption keys, managed databases, DNS, load balancers, queues, object stores, secrets, and the other services the application used before the incident.
Rubrik has also announced Autonomous Business Recovery (ABR) for Cloud Applications, an unreleased pre-GA capability intended to discover application dependencies and orchestrate recovery across more of that stack. Rubrik's June announcement calls it Private Preview, while its published solution brief calls it Private Beta. Neither establishes general availability. Both place ABR on the unreleased side of Rubrik's safe-harbor boundary, so I would treat it as a future-state architecture direction rather than a dependency a production recovery design can assume today.[11][12]
Recovery contract: For every cloud application, define what Rubrik returns, what target cloud resources must already exist, what dependencies recover through separate workflows, and what service check proves the application is actually usable.
The Protected Object Is Only One Part of the Application
A traditional VM backup can encourage a simple mental model: restore the VM, connect the network, start the service. Cloud applications tend to spread state and dependencies across more provider services.
An EC2 application server may use an RDS database, an IAM role, a customer-managed KMS key, an Application Load Balancer, Route 53 records, S3 buckets, SQS queues, Secrets Manager, and security groups. An Azure VM may depend on a managed identity, Key Vault, Azure SQL, a load balancer, private endpoints, DNS zones, storage accounts, and Network Security Groups. None of those dependencies has to live on the operating system disk.
RSC's EC2 recovery workflow makes the boundary visible. An in-place restore rolls the existing EC2 instance back to a selected point in time while retaining its instance ID and private IP address. An export creates a new EC2 instance and asks the operator to select the target region, VPC, subnet, security group, instance type, KMS key, and optional key pair.[2][3]
The backup contains recoverable instance and volume state. The export still needs a usable cloud landing zone.
Azure works the same way at a different API surface. RSC can restore an Azure VM over the existing VM or export a snapshot as a new VM. During export, the operator selects the target subscription, resource group, region, VNet, subnet, Network Security Group, and optional availability set.[5][6]
Architecture point If the cloud recovery design does not name those target resources before the incident, the runbook has moved a large part of the recovery architecture into the middle of the outage.
Recovery Mode Changes the Prerequisites
The right Rubrik recovery action depends on what survived.
| Recovery path | What RSC does | What the architecture is assuming |
|---|---|---|
| AWS EC2 in-place restore | Stops the existing instance and replaces EBS volumes from the selected snapshot while retaining instance identity and private IP. | The source account, region, instance, network, IAM path, and surrounding application services are still usable. |
| AWS EC2 export | Creates a new instance from a source, replicated, or archived recovery point. | A target account or region is ready with the VPC, subnet, security group, KMS access, capacity, and permissions needed for the new instance. |
| Azure VM restore | Replaces the existing VM disks from the selected recovery point. | The original subscription, VM definition, network path, and dependent Azure services remain usable. |
| Azure VM export | Creates a new VM from the selected snapshot. | The target subscription and region have a resource group, VNet, subnet, NSG, permissions, encryption prerequisites, and capacity available. |
The in-place paths are strong when the surrounding cloud environment is healthy and the problem is corruption, deletion, or a bad change inside the protected object. Export is more flexible when the source placement cannot be trusted or used, but it exposes more target dependencies.
Rubrik can also use replicated or archived copies as recovery sources. AWS cross-account and cross-region snapshot replication is specifically designed to keep EC2 and EBS recovery points available when the original snapshot is unavailable or damaged.[4] That solves the recovery-point location problem. It does not create the target application's VPC design, identity model, DNS, managed services, or external integrations.
Cross-Region Copies Are Not a Cloud DR Topology
I want cloud snapshot replication because it separates the recovery copy from the original account or region. I do not want the architecture document to stop there.
A replicated EC2 snapshot in another account is useful only if the team can turn it into a working instance. RSC's export workflow still needs the destination VPC, subnet, security groups, encryption key access, and permissions.[3] The same principle applies to an Azure VM exported to another location: the recovery point can be valid while the target network, identity, private endpoint, or dependent database is missing.[6]
That is why I separate two questions in design reviews:
- Where will the recovery point survive? This is the backup and replication question.
- Where will the application run? This is the cloud recovery architecture question.
The answers can be in the same account, another account, another subscription, another region, or a different platform entirely. They still need to be designed independently.
Managed Databases Need Their Own Recovery Contract
Cloud applications often split compute and database state into separate managed services. Restoring the application VM does not restore the database service attached to it.
RSC protects Amazon RDS and Aurora separately. Recovery can use point-in-time export from continuous backups or snapshot export from scheduled or on-demand snapshots. The RDS recovery workflow asks for database settings such as instance class, storage type, KMS key, VPC, subnets, and security groups for the recovered database.[7]
Azure SQL is also protected and recovered as its own workload. Depending on the backup type, RSC supports point-in-time restore, long-term retention recovery, and recovery from immutable backups. Immutable Azure SQL backups can be exported to a target SQL Server, and BACPAC files can be used to recover into other subscriptions, cloud environments, or on-premises SQL Server deployments.[8]
A three-tier application may therefore have three different recovery contracts:
- recover or export the web and application VMs;
- recover the managed database through the database-specific workflow;
- recreate or reconnect the networking, identity, DNS, secrets, load balancer, and external integrations that tie the service together.
Operational view When an application owner says, "Rubrik backs up the app," I want the inventory to show the actual protected objects. EC2, RDS, S3, Azure VM, Azure SQL, Kubernetes, and external SaaS dependencies do not become one recovery object because they share one application name.
Kubernetes Gets Closer to the Application, but the Boundary Still Exists
Kubernetes protection is more application-aware than a VM snapshot because the protected unit can include namespace-scoped resources and persistent data.
RSC protection sets can include an entire namespace or selected Kubernetes resources such as Deployments, Services, Pods, and associated persistent volumes. A protection set can be recovered in place or exported to a new namespace in the same or a different Kubernetes cluster.[9]
That is a much better recovery unit for containerized applications than protecting worker-node VMs and hoping the cluster reconstructs itself.
The protection set still has a boundary. The destination Kubernetes cluster has to exist and be accessible. Persistent-volume protection depends on a CSI implementation that supports snapshots and creating PVCs from VolumeSnapshots. Application dependencies outside the namespace, such as an external RDS database, Azure SQL database, cloud load balancer, DNS zone, container registry, external secret store, or provider IAM relationship, need their own recovery or recreation path.[9]
Architecture point Namespace recovery can restore the Kubernetes objects Rubrik protected. It does not remove the need to map everything the namespace calls outside itself.
Orchestration Helps, but It Has a Scope
Rubrik Orchestrated Application Recovery adds a useful layer above individual VM restores. Recovery Plans store VM recovery specifications, target resource mappings, and boot order. RSC supports VMware, AHV, and Azure virtual machines in Orchestrated Recovery, with Azure currently limited to cyber recovery.[10]
For Azure virtual machines, that can move the design beyond one-at-a-time restores. The plan can group VMs and preserve a repeatable recovery sequence.
The scope still matters. A Recovery Plan is made of virtual machines. It does not automatically turn an Azure application that also depends on Azure SQL, Key Vault, private DNS, Application Gateway, Service Bus, or an external SaaS API into one atomic recovery object.[10]
I would use Rubrik orchestration where it fits, then keep the application dependency map beside it. The plan handles the objects it owns. The runbook handles the service.
Rubrik Is Moving Toward Application-Level Recovery
Rubrik announced Autonomous Business Recovery for Cloud Applications in June 2026. Rubrik says ABR can discover application dependencies, protect data and infrastructure configuration together, and orchestrate recovery across networking, compute, data, IAM, and configuration.[11][12]
As of an October 19, 2026 public-source recheck, the June 9 announcement still describes ABR for Cloud Applications as Private Preview, while Rubrik's published solution brief describes it as Private Beta. Neither source confirms general availability for Cloud Applications.[11][12] In either case, Rubrik treats the capability as unreleased and subject to safe-harbor language: the publicly documented Cloud Applications offering is not established as generally available, may change, and may never become generally available. I would evaluate ABR as part of a future-state Rubrik recovery architecture, but I would not make a committed production recovery plan depend on it until the required capability is generally available and contractually supported.
ABR reinforces the distinction between object recovery and application recovery. Dependency discovery, infrastructure configuration, recovery order, identity, networking, data, and service validation all exist because recovering an individual cloud object is not the same thing as recovering the application. Whether those responsibilities are manual, driven by infrastructure as code, handled through generally available Rubrik workflows, or increasingly automated by ABR, the recovery contract still needs to say what must come back and how the team proves the service works.
Build the Target Cloud Before You Need It
Cloud recovery often fails late because the recovery team assumes the provider can create whatever is needed on demand.
The provider can create resources only when the account is reachable, the API works, quotas exist, permissions are correct, encryption keys are accessible, and the organization knows what to create. The recovery design must document and validate those prerequisites before an outage.
For critical applications, I want one of two models:
- Prebuilt recovery foundation. The recovery account, subscription, networks, subnets, security controls, DNS zones, key access, logging, and minimum shared services already exist.
- Tested infrastructure as code. The organization can create the required cloud foundation from version-controlled code using credentials and pipelines that do not depend on the failed production environment.
Either model can work. An undocumented promise that "we can build it in the cloud if we need it" is not a recovery design.
The landing zone also needs capacity. Instance types can be unavailable in a region or constrained by quotas. Recovery can require different encryption-key permissions, service quotas, storage limits, or API permissions than day-to-day backup. RSC's own cloud workflows expose these dependencies by requiring target resource selections and recovery permissions before export or restore can complete.[3][6]
Protect the Application Map, Not Just the Data
A cloud recovery runbook should be able to answer which component is recovered by which mechanism.
| Application component | Recovery owner | Recovery method | Target prerequisite |
|---|---|---|---|
| EC2 or Azure VM | Rubrik + cloud platform | Restore or export from RSC recovery point | Account/subscription, region, network, security, key access, capacity |
| RDS / Aurora or Azure SQL | Rubrik + managed database service | Database-specific snapshot or point-in-time recovery | Target DB settings, network, encryption, credentials, capacity |
| Kubernetes namespace and PVs | Rubrik Kubernetes protection | In-place recovery or export to namespace/cluster | Working cluster, compatible storage, cluster access, required external services |
| DNS, load balancer, routes, firewall policy | Cloud/platform team | Prebuilt config or infrastructure as code | Control-plane access and approved configuration source |
| IAM, managed identities, secrets, KMS/Key Vault | Security/platform team | Break-glass, replicated/config-managed state, or platform-specific recovery | Independent administrative path and key/secret ownership |
| External APIs and SaaS dependencies | Application owner | Reconnect, reauthorize, or use documented fallback | Credentials, allow lists, endpoints, vendor availability |
The exact rows vary by application. The point is to expose ownership and prerequisites before the first restore starts.
If a row has no recovery owner, no source of truth, or no target prerequisite, the recovery design is carrying an assumption it has not resolved.
Twelve Questions I Would Ask Before Signing Off
- What cloud objects are actually protected by Rubrik for this application?
- Which recovery path will be used for each object: in-place restore, export, point-in-time recovery, snapshot export, file recovery, or Kubernetes recovery?
- Which account, subscription, region, or Kubernetes cluster will receive the recovered workload?
- Does that target already have the VPC or VNet, subnets, routing, security controls, DNS, and private connectivity the application needs?
- Which KMS keys, Key Vault items, certificates, secrets, IAM roles, managed identities, and emergency credentials are required during recovery?
- Which managed databases, object stores, queues, load balancers, API gateways, and external services are outside the VM or namespace recovery point?
- Are those dependencies protected separately, rebuilt from code, or intentionally accepted as external dependencies?
- Can the target environment be created or administered if the production identity path and deployment pipeline are unavailable?
- Are the required cloud quotas, instance families, storage classes, and regional services available at the recovery target?
- What startup order reconnects the application without pointing a recovered component at damaged production services?
- What transaction or business function proves the recovered service is usable, not merely running?
- When recovery succeeds, how does the team restart protection, monitoring, logging, and ownership in the new location?
Those answers produce a recovery architecture. A list of protected cloud resources does not.
The Bottom Line
Rubrik supports several recovery paths for specific cloud workloads. EC2 instances can be restored or exported. Azure VMs can be restored, exported, mounted, or recovered at the file level. RDS, Aurora, and Azure SQL have their own database recovery paths. Kubernetes protection sets can recover application resources and persistent data.[2][5][7][8][9]
Those are the recovery building blocks.
Cloud application recovery is the work of assembling them into a usable service in a target environment that has networking, identity, keys, managed services, capacity, DNS, security policy, and external dependencies ready to support the recovered data. Rubrik's pre-GA ABR for Cloud Applications, as described in the checked public materials, is aimed at automating more of that application-level work, but a production design should still be based on capabilities that are generally available and explicitly supported.[11][12]
I would design object protection and application recovery separately, then test them together.
Key Takeaways
- A successful cloud backup proves a recoverable object exists. It does not prove the complete application can run at the recovery target.
- In-place restore and export have different dependency profiles. Export exposes target network, security, encryption, capacity, and permission requirements.
- Cross-account or cross-region snapshot replication protects recovery-point availability, not the application's cloud topology.
- Managed databases such as RDS, Aurora, and Azure SQL need their own recovery contracts alongside VM recovery.
- Kubernetes protection sets can recover namespace resources and persistent volumes, but cluster-external services still need separate recovery paths.
- Treat cloud networking, identity, keys, DNS, managed services, quotas, and infrastructure as code as part of the recovery architecture.
- Rubrik ABR for Cloud Applications remains a pre-GA direction in the checked public materials for broader application-level recovery, not a dependency to assume in a committed recovery plan.
- The final success condition is a working application service with protection and operations restored, not a completed snapshot restore.
Source Notes
Source-link access note (October 19, 2026): Some Rubrik documentation links may redirect to Rubrik OnePass or require an authenticated session. These are the vendor's canonical documentation references; an authentication redirect is not confirmation that a particular page was independently opened or verified. Public Rubrik materials and accessible documentation were checked where possible. Verify current feature availability, support limits, and release status in your own Rubrik documentation session before making a production design decision.