In this clip, we're going to take a look at the concept of disaster recovery, or DR.
And Amazon uses a certain language to describe certain situations that you could use to ensure
that your application can be recovered as fast as you want it to be recovered.
So let's look at these concepts.
We have backup and restore on the left.
And then on the right, we have multi-site active-active.
Each of these disaster strategies uses two locations.
You could have a location on-prem and one in the cloud, or you could have AWS regions,
one being the production site, one being the backup.
It just depends on what resiliency do you want for your application stack.
So let's address the different scenarios that we could see.
Backup and restore is the cheapest, has a much longer RPO, RTO, or the restore point,
i.e., recovery of data.
And restore time, how much time will this take?
We get into a situation where it could be hours, but maybe that's okay.
Maybe it's a test environment and you have hours to restore it.
Perhaps you need everything to be a little faster.
Or on the right, multi-site active-active, you can see the RPO, RTO is real-time in that
we're not necessarily going to lose anything.
The system can fail over to a different location automatically.
Backup and restore, the cheapest.
Multi-site active-active, the most expensive because you have resources in two locations
that are running 24-7.
If we take a look at the multi-region backup, in this case, we have US West region and the
Southeast region, two physical separate locations.
In the West region, we've got a couple of application servers, a database instance,
and there is a backup service in place.
Maybe this is a software appliance, third party, something that the customer has designed
that the backup service backs up the functioning servers to another physical location.
And it's putting the backups in an S3 bucket, which has lots of resiliency.
And the images of the servers, the AMIs, and the snapshots of the EBS volumes,
they're also stored in this physical location.
So, how much time would it take to actually restore a downed server depends on how much
time it takes.
Rebuilding a server might take 5, 10 minutes.
It might not take that long, but it might take more time than an active-active environment
or a pilot light response.
Speaking of pilot light, that's our next option.
What we see on the left is the US West region with an application stack, a couple of web servers,
a couple of application servers, and a primary database server.
Now, let's see how this is set up to work when failure occurs.
So, as we've mentioned, we have the production site on the left, where 53 is monitoring requests
to this region.
Everything seems okay right now, but the planning for the problems that may occur include snapshots
of the AMIs of the web servers, the app servers, and the database servers,
and they're stored in the other region in a specific S3 bucket.
The database is being synchronized, so the primary and the replica have the exact same data.
So, the database in this pilot light setup is the item that is left on, hence the term pilot light,
right, something has to be left on.
The data is up to date, but the compute is off.
So, if we're going to have a failure, then Route 53 will fail over to the southeast region,
which means that these servers, they're off, they have to be turned on.
So, once they're on and scaled, because the west region is down, everything can continue.
We have our required resources, the images, anything that we might need in the S3 bucket for recovery,
but in this case, the servers are just off.
So, we need to turn the servers on.
We have to get them to their required size to handle the production workload, and we're good to go.
If we look at a warm standby using the Aurora global database, Aurora being a SQL database,
MySQL Postgre that can operate with any single region, but it can also synchronize across multiple regions.
In this example, on the left, we have the Aurora primary and a replica in different availability zones,
the shared cluster data volume, shared among all the nodes, and an additional replica over in the region US-West.
So, the active region US-East, the region that will fail over if there's an issue with US-East is US-West.
The database is synchronizing.
It's up to date in both regions.
We have compute in both regions as well, but note that the compute in US-West, everything isn't turned on.
So, we are able to handle a certain amount of traffic from the web tiers and the app tiers,
but we can't handle the maximum amount of traffic that the system is designed for when it initially fails over.
Once we have failover, the instances in the web tier and the app tier will have to be scaled to match the maximum amount of traffic that might be.
Once we have failover, the web tier and app tier in US-West must be scaled up to match the amount of compute required for the number of customers that are using this resource.
So, a warm standby using Aurora Global Database.
Let's look at another example, US-East and US-West.
The compute is exactly the same.
There's nothing that actually needs to be scaled because the system is designed as an active, active system.
If there's a failure in US-East, we can fail over to US-West and vice versa.
As mentioned, the DynamoDB is a global table and the changes are globally replicated to both regions.
Is this costing me more money?
Absolutely. Everything is on and sized accordingly, according to the application and the end user's needs.
But it's certainly going to be more expensive.
Our next option is looking at users in San Jose and users in Texas in a read, local, write global design.
The database is synchronized between the US-West and the South-East region.
We have web servers and app servers running the application.
We have our backup components, snapshots, AMIs being synchronized for backup.
And we have Route 53 that is directing the users in Texas as to where they will read their information.
Users in Texas will read their records from the South-East region,
but they will write their changes to the DB primary in US-West.
The users in San Jose will read and write from the US-West region.
So, we have a situation where we have failover.
We have functionality.
We have active, active.
Writes go to the primary region, US-West.
Both regions can have local reads.
So, that's a look at disaster recovery scenarios at AWS.