Welcome to another episode of 'Back to Basics'.
I'm Shailaja Suresh, a senior solutions architect with Amazon Web Services.
Cloud architects often ask themselves,
"Now that I have provisioned my workloads using Amazon Relational Database,
what do I do to ensure disaster recovery of my database?"
Does that sound familiar to you?
If so, let's get 'Back to Basics'.
Now, before we look at a pattern,
let's familiarize ourselves on a few concepts.
So what is an AWS Availability Zone?
An Availability Zone is one or more datacenters with redundant part
and networking connected by ultra low latency networks.
AWS customers run their applications in multiple Availability Zones
to achieve greater fault tolerance and high availability.
Now what is an AWS Region?
Each AWS Region consists of multiple, physically separate Availability Zones
within a geographic area.
Each AWS Region is designed to be completely isolated from other regions.
For the same reason, to enable disaster recovery on your database at AWS,
we recommend portioning your databases across multiple regions.
Now let's talk about what RTO and RPO is.
RTO or Recovery Time Objective is the maximum acceptable delay
between a service disruption and a restoration point.
RPO or Recovery Point Objective, on the other hand,
is the maximum acceptable data loss that is permitted
between a service disruption and last data recovery point.
Organizations have their own RTO and RPO requirements
as mandated by their customers.
Now let's look at a pattern to illustrate disaster recovery
across multiple regions with Amazon Aurora, a relational database.
In this example, we have provisioned the application
and the Aurora Database across two regions.
The application is connected to an Aurora Cluster in a primary region
which performs reads and writes from the writer instance
and only reads from read replicas.
The application is connected to an Aurora Cluster in a secondary region
which performs only reads from read replicas
Amazon Route 53, Amazon's domain naming service,
has been created to point to the different
and changing Aurora Reader and Writer endpoints.
To minimize the amount of manual work you must undertake
to relink your applications during a DR failover.
Now let's say that in a rare yet possible scenario,
the entire region's infrastructure or service becomes unavailable
at the primary region.
In this case, you can initiate the Failover
by promoting a secondary cluster to become a primary instantaneously,
preventing any data loss within the limits of RPO and RTO set.
Upon completion of failover,
this promoted region acts as the new primary Aurora Cluster
and can take full read and write workloads in under a minute,
which minimizes the impact on application uptime.
At AWS, we prescribe well-architected architecture patterns to our customers.
That said, let's remind ourselves of a common anti-pattern in this architecture.
Provisioning databases just across Availability Zones
and not across regions does not ensure disaster recovery for your database.
Let's take a case where there is a service disruption
in one geographical region due to an earthquake.
Now you would need another region which is in a different geographical region
far away from the area experiencing the earthquake
to take away your application.
I hope this pattern comes to you handy
when you provision disaster recovery for your database.
Check out the links below for more details.
See you next time.