First, let's review RPO and RTO.
RPO stands for Recovery Point Objective,
and in the context of disaster recovery, this is the acceptable data loss
expressed in hours.
For example, let's say your company has
an RPO of one hour, that means you're okay with losing up to one hour of data
if disaster strikes.
On the other side, we have RTO, or
Recovery Time Objective, rather than acceptable data loss, we're talking about
acceptable downtime of your systems.
This is also expressed in hours.
An example here would be if you've got an RTO of one hour, then that means your
systems should be up and running again within one hour of disruption.
Just one more slide to illustrate the differences.
Here on our timeline, in the middle, we
have some disaster that happened, a fire, an earthquake, some other type of disruption.
For RTO, again, this relates to time, and this is a measure of how much downtime
you have after a disaster.
Recovery Point Objective has to do with
your data though, so this is really saying when was your data last backed up
before the disaster?
Because whatever that was, say it was a
day before, that means basically you're losing a day's worth of data.
When you're talking about disaster recovery, there's four different
strategies that you can use, and they run on a spectrum.
For each, we'll talk about RPO, RTO, costs, and a few other points.
So starting with Backup and Restore on the far left here, and I'll point out
that on the left, we have lower cost and lower complexity, and then as we go to
the right, you'll see higher cost and higher complexity.
So this is the simplest, cheapest option here.
With Backup and Restore, you've got RTO
and RPO measured in hours, and again, the lowest cost of all of them.
With this, you'll be using things like snapshots of your EBS volumes and
snapshots of databases or backups of databases.
You can also use S3 cross -region
replication to copy your data into a recovery region, and this should be used
for lower priority use cases.
Here, you'll need to deploy both your
data and your infrastructure to the recovery region after the event, so this
would be a manual effort.
Moving to the right, we have what's
called the Pilot Lite strategy.
With this option, you're going to have a
shorter RPO RTO measured in tens of minutes.
The cost will be higher here, though,
because you'll replicate your data to another region and also make a copy of
your core infrastructure in that region.
So this means your core infrastructure is
always available unlike with Backup and Restore that we just talked about.
With this option, you could be using things like S3 replication, RDS read
replicas, or Aurora global databases or DynamoDB global tables.
Moving to the right, we have Warm Standby.
With this option, you're going to get an
improvement in RPO RTO.
Those would only be minutes, but as you
might expect, at an increased cost.
Here, you're going to have a fully
functional but scaled down version of your production environment in another
region, which might sound similar to Pilot Lite.
The difference between the two is that Pilot Lite requires you to turn on the
servers and possibly deploy additional non -core infrastructure.
Whereas with Warm Standby, you can handle traffic immediately in the recovery
region, though it may be temporarily at a reduced capacity.
And then finally, on the right, we have Multi -site Active Active, which has real
-time RPO RTO, and it's going to be the most expensive option.
Here, you're going to have a fully functioning environment in multiple
regions, and traffic is being directed to multiple regions.
This means you've got near zero recovery time and data loss in the event of a disaster.
This should be used for mission -critical services.
Here, you're probably going to be using
things like Route 53 and AWS Global Accelerator to route traffic to the
active region.
Now, it should go without saying, but
it's really important to regularly test all of your recovery paths.
It doesn't really do you any good to have a disaster recovery plan that nobody
knows how to use or that fails when you go to execute it.
So for example, maybe you have a setup where you've got a primary database and
then a secondary database that's read -only to help give users better performance.
Your recovery path says that if the primary database goes down, you need to
fail over to the secondary.
So try that out.
Take your primary database offline, make sure that everything successfully
transitions over to the secondary.
Or if you're doing something like a
backup and restore, take one of your backups, restore it, and make sure that
you can direct traffic to it.
Maybe you've got load balancers and
you're working with auto -scaling groups so that the number of instances you have
gets scaled up or down, or unhealthy instances automatically get replaced.
Test this out as well.
Take one of your instances offline, make
sure you've got everything correctly configured to spin up another one.