AWS SA Professional – Practice Question 5

question

A customer is running an application in US-WEST (Northern California) region and wants to setup disaster recovery failover to the Asian Pacific (Singapore) region. The customer is interested in achieving a low Recovery Point Objective (RPO) for an Amazon Relational Database Service (RDS) multi-AZ MySQL database instance. Which approach is best suited to this need? (Choose 1)

a. Synchronous Replication

b. Asynchronous Replication

c. Route53 Health checks

d. Copying of RDS incremental snapshots

This question is testing your understanding of Disaster Recovery strategies and also ensuring you understand a number of key concepts.

Recovery Point Objective (RPO)
A recovery point objective, or “RPO”, is defined by business continuity planning. It is the maximum targeted period in which data might be lost from an IT service due to a major incident.

Recovery Time Obejective (RTO)
The recovery time objective (RTO) is the targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.

So now I’ve covered a few of the key things that need to be understood to answer the question, lets go ahead and rule out some obvious incorrect answers.

“Answer C” is incorrect given this will purely handle the health-checking against targets, be it an EC2 Instance, Elastic Load Balancers etc.. This doesn’t handle anything to do with the replication of data for the MySQL RDS Database. Route 53 could be utilized as part of an overall solution for Disaster Recovery, but in this instance it’s not meeting the requirements.

“Answer D” is incorrect as this is purely copying the MySQL RDS Instances incremental backups to the other AWS Region. It doesn’t take into consideration the restoring of the snapshot in an automated fashion or the fact that the Snapshots are point in time so there is potential for data loss from the point of the last backup. As the client is looking for a low RPO, in my opinion this can also be ruled out.

So this now leaves us with the choice between the choice of either Synchronous Replication (“Answer A”) or Asynchronous Replication (“Answer B”). Its now important to understand the difference between Synchronous and Asynchronous replication.

Synchronous v Asynchronus Replication
The primary difference between synchronous replication and asynchronous replication is the way in which data is written to the replica. Most synchronous replication products write data to primary storage and the replica simultaneously. As such, the primary copy and the replica should always remain synchronized.  In contrast, asynchronous replication products write data to the primary storage first and then copy the data to the replica. Although the replication process may occur in near-real-time, it is more common for replication to occur on a scheduled basis. For instance, write operations may be transmitted to the replica in batches on a periodic basis (for example, every five minutes).

There are two main benefits to asynchronous replication:

  1. It tends to cost significantly less than synchronous replication. Synchronous replication requires more bandwidth than asynchronous replication and may also require specialized hardware (depending on the implementation).
  2. It is designed to work over long distances. Since the replication process does not have to occur in real time, asynchronous replication can tolerate some degradation in connectivity.

Similarly from reading the AWS RDS Frequently Asked Questions we know that RDS Multi-AZ Databases use Synchronous Replication and Multi-AZ can only be enable within an AWS Region and not Across Regions.

If we refer back to the Question we know that the Client wants to establish a DR Environment in Singapore whilst the existing Multi-AZ RDS Database is located in North California.

Therefore I’m confident in saying that “Answer B” is the correct answer.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s