Because outages never give notice.
RPO and RTO defined as a business requirement, implemented in one of the four AWS DR strategies and tested on a regular basis.
Almost every company has backup. Few know how long it would take to be operational again, and fewer have tested it. That is the difference between backup and disaster recovery: backup is a copy of the data; DR is the proven ability to resume operations within a window the business accepts. Without a test, you do not have DR, you have an expectation.
It starts with two numbers that are a business decision, not an IT one. RPO (Recovery Point Objective) defines how much data you accept losing, measured in time. RTO (Recovery Time Objective) defines how long you accept being down. Those two numbers drive the architecture and the cost. AWS recommends defining a small number of RPO and RTO classes and fitting applications into them, instead of negotiating case by case.
AWS organizes DR into four strategies, from lowest to highest cost and complexity: backup and restore; pilot light, with RPO in minutes and RTO in tens of minutes; warm standby, with RPO in seconds and RTO in minutes; and multi-site active/active. One technical detail that changes outcomes: AWS splits its services into data plane and control plane, and recommends using only data plane operations in the failover procedure, because the data plane has a higher availability target than the control plane.
If two or more of these scenarios sound familiar, it is worth a conversation.
Initial assessment at no cost
The exact composition depends on your environment and on the requirements identified during the assessment. This is the baseline we work from for this solution.
Central place to configure, schedule and monitor backup of EBS, EC2, RDS, Aurora, DynamoDB, EFS, Storage Gateway and the FSx families, with cross-account and cross-region copy
Continuous replication with recovery in a secondary region, the basis for the pilot light and warm standby strategies
Asynchronous, continuous object replication to the DR region
Protection against improper deletion and modification, a direct mitigation for human error and ransomware
Infrastructure as code, without which rebuilding the environment in the DR region becomes slow and error-prone
Traffic redirection on failover with health checks and routing policies
Continuous validation of whether the environment actually meets the declared RTO and RPO targets
Automation of periodic restores and recovery tests
Immutable retention, preventing backups from being deleted even by a privileged credential
We map the applications and define RPO and RTO classes together with the business areas. Not everything needs warm standby, and paying for it across the whole portfolio is waste.
We compare the RPO and RTO the current environment delivers with what the business requires. The gap between the two is the real scope of the project.
We assign each class one of the four AWS strategies, balancing cost and risk. A billing system and an internal portal rarely deserve the same architecture.
We configure backup policies, replication and the failover procedure. Wherever possible, we use only data plane operations on the critical recovery path.
We run the failover in a controlled environment and measure the actual RTO and RPO. This is the step most projects skip, and it is exactly what turns a plan into a capability.
We set a test calendar and document the procedure for returning to the primary region. A DR environment without periodic testing accumulates configuration drift until it stops working.
Actual recovery time observed in a test, not the number estimated in a spreadsheet
Actual data loss verified during the recovery exercise
Share of critical resources under an active, verified policy
Successful restores over the total attempted during tests
Market references documented by AWS itself in equivalent scenarios. Each card links to the original story published on the AWS site.
The manual failover process of the legacy identification solution, kept on premises, left employees without access to systems for up to 30 minutes. The company rebuilt the failover mechanism with Amazon CloudWatch.
Published result
AWS published the reduction of failover time from 30 minutes to 3 minutes.
In the same migration program supported by AWS MAP, the company treated disaster recovery as part of the scope, not as a later project.
Published result
According to AWS, there was improvement in security and disaster recovery capabilities.
The cases above are customer stories published by Amazon Web Services. The results cited belong to the companies mentioned and serve as a reference for what is technically achievable on AWS. They do not represent results delivered by Núvoli, nor a guarantee of equivalent performance, since every environment has its own context.
Our approach is not opinion. It follows guidance documented by AWS, and you can check the source yourself.
The first step is an assessment of your current setup, at no cost and with no commitment. You come out of it with risks mapped and priorities defined, even if you decide not to move forward with Núvoli.
