Most cloud backup tools do one job well: they protect individual things. A server here, a database there.
But your business doesn't run on a server or a database. It runs on applications and applications are compute, data, networking, and permissions, all working together. In the event of a catastrophic failure, restoring one piece of that architecture doesn't give you your business back.
For most organizations, a handful of these applications make up the Minimum Viable Business (MVB): the minimum set of applications and business services that support revenue, customers, employees, and operations.
A typical AWS application now touches load balancers, Auto Scaling groups, databases, object storage, Lambda functions, secrets, and all the network and IAM plumbing that connects them. When you need to recover that, you aren't recovering a single resource. You're recovering a complex web of data and its dependencies.
Rubrik Autonomous Business Recovery (ABR) for Cloud Applications is now generally available, with support for cloud-native architectures including containerized applications, AWS Lambda functions, and Amazon S3. ABR discovers the dependencies inside each AWS application, keeps that map current, and recovers the whole application in dependency order. For the applications behind your Minimum Viable Business, recovery starts from a map Rubrik already holds.
Rebuilding Is Not The Same As Recovering
Say an attacker logs in to your AWS account with a compromised identity and deletes the production environment. Your EC2 and RDS backups are good, so the data is safe. That’s great.
Now the real work starts.
The VPC and subnets are gone. So are the security groups, the IAM roles, the load balancer, and the DNS records that pointed users at it. Someone has to remember what all of that looked like, recreate it in the right order, and wire it together before the restored servers have anywhere to run.
Most teams do this from runbooks, Infrastructure as Code, wiki pages, and the memory of whoever built the thing. But these all go stale the first time someone edits a security group out of band, and you usually find that out in the middle of the incident.
Backups get your data back. They don't get your application back
Introducing Rubrik Autonomous Business Recovery for Cloud Applications
Today Rubrik Autonomous Business Recovery (ABR) for Cloud Applications is generally available, following its introduction at Rubrik Forward in June, 2026. ABR discovers, protects, and recovers complete AWS applications rather than individual instances, databases, or buckets.
Every organization has a Minimum Viable Business: the minimum set of applications and business services that support revenue, customers, employees, and operations.You decide which AWS applications make up yours, and ABR then allows you to discover the dependencies inside each one, keep that picture current, and recover each application as a whole when it matters.
An application is its AWS configuration plus its workloads. Configuration is the stateless infrastructure around your data: VPCs, subnets, security groups, IAM, load balancers, Route 53, launch templates, Lambda function settings, and more. Workloads are the parts that hold data: EC2 and EBS, RDS and Aurora, and S3. ABR protects both and brings them back in the right order, in a single recovery.
ABR builds on Rubrik Cloud Native Protection (CNP) and doesn't replace it. Your workload snapshots are still CNP snapshots, and your existing EC2 and RDS policies keep working as they are. ABR adds the ability to understand your application, map its dependencies, and recover all of it.
What's New at General Availability
Early access, introduced at Rubrik Forward, focused on three-tier applications built on AWS. General availability extends ABR to cloud-native architectures, including containerized applications Lambda functions, and Amazon S3.
How It Works
ABR works in three stages: discovery, protection, and recovery.
Discovery: Start With a Tag, Discover the Dependencies
You choose the source AWS account where the application lives and a separate AWS account to recover into. Then you add anchor tags, which are tags you've already applied to the resources at the heart of the application, such as a load balancer and a database. Rubrik finds every resource carrying those tags, then follows their dependencies to discover the EC2 instances, VPCs, subnets, security groups, and everything else the application relies on. Discovery is read-only, so Rubrik doesn't add tags to anything in your source account. If dependencies are missed, include them by simply applying your anchor tag. If dependencies are not required, they can be manually excluded from the application easily using the dedicated discovery wizard. Further, this guided discovery experience allows you to customize your application dependency maps further in line with your application requirements.
Rubrik refreshes the application dependency map over time. A new load balancer or Auto Scaling group gets picked up, and an excluded or deleted resource drops out.
Protection: Two SLAs, Each With Its Own Job
Protection splits in two. An Application SLA captures the configuration and sets the application-wide recovery point. Each workload keeps its own Cloud-native protection SLA for its data, so an hourly EC2 policy stays hourly. Set your workload SLAs to run at least as often as the Application SLA, which can run as often as every six hours, and the application shows as fully protected.
Configuration is a small amount of JSON, and it's stored immutably in Rubrik-hosted storage, so it adds no storage cost in your AWS account. Lambda code and Secrets Manager values are handled differently, because they often contain sensitive data like credentials, API keys, and proprietary code. Rubrik doesn't store them in Rubrik-hosted storage. They're written to a backup location you choose on the Application SLA, either your own S3 archival location or Rubrik Cloud Vault, so that data stays somewhere you control.
Recovery: One Wizard, Dependency Order
Recovery always lands in a separate AWS account, so the rebuilt application is isolated from a source account that may be compromised. Today, recovery runs in the same AWS region as the source application. Here's what happens when you run it:
You launch the recovery wizard in Rubrik Security Cloud and choose your snapshots, network settings, and, if you want them, pre and post recovery hooks. Building on Rubrik's Preemptive Recovery Engine, the wizard recommends the most recent snapshot that isn't flagged by Anomaly Detection or quarantined by Threat Monitoring, so you aren't guessing which restore point is clean.
Rubrik runs pre-checks against the recovery account for KMS key aliases, ACM certificates, and EC2 key pairs. If something is missing, the recovery stops before anything is created.
Optionally, a pre-recovery Lambda function you provide runs in the recovery account.
Rubrik rebuilds the configuration wave by wave, in dependency order, so the network exists before the things that sit in it. For networking, you choose how the network gets built. Rubrik can clone the source network into the recovery account as is, clone it with remapped CIDR ranges, or place the application into a landing zone VPC you've already built. If you enable it, Rubrik also updates Route 53 records to point at the recovered resources.
Workloads are restored from their own snapshots into the recovered network. For S3, prioritized recovery brings the most important data back first.
A reconcile pass connects the pieces that could only be wired up once their dependencies existed, such as IAM policy attachments and Auto Scaling capacity.
Optionally, a post-recovery Lambda function you provide runs.
Recovery is re-runnable. If something fails partway through, resources that already succeeded are skipped on resume, and resources that already exist are adopted instead of duplicated.
When you're testing, run clean up afterward and Rubrik deletes only what that recovery created. When it's real, run Lock Recovery. It's permanent: Rubrik stops managing the recovered resources and hands them over to you as normal AWS resources.
Get Started
Protecting your workloads gets your data back. Recovering an application means getting the network, the permissions, the configuration, and the data back together, in the right order, without relying on a runbook someone wrote last year. ABR for Cloud Applications discovers the application, protects it, and rebuilds it into a clean AWS account in one recovery. For the applications that make up your Minimum Viable Business, that is the difference between reconstructing under pressure and recovering something you have already mapped.
See it for yourself. Walk through the interactive demo, and read the one-pager Or your join us at the virtual Cloud Resilience Summit to see this product in action and hear from AWS experts on how this capability helps their customers build resilience for their Minimum Viable Business applications running on AWS cloud.