‫So when you deploy RDS databases, you need to understand
‫there are multiple architectural choices
‫you need to make, that you can make, actually.
‫So the first is to use RDS Read Replica.
‫So let's take the example of your application,
‫that reads from your main RDS database.
‫But say that now you need to scale the read workloads,
‫we have more and more applications
‫that need to read more and more data from RDS.
‫The way you can do it is by creating Read Replica.
‫So that means that there is gonna be some copies,
‫some replicas of your RDS database
‫that are going to be created.
‫And this is going to allow your applications
‫to read from this Read Replica also.
‫And therefore, you're distributing the reads
‫to many different RDS databases.
‫So you can create up to 15 Read Replicas.
‫So as you can see, in this example,
‫I have two Read Replicas on top of my main RDS database,
‫and my applications can read from all of them.
‫Now, when it comes to writing data,
‫writing data is only done to the main database,
‫so your application still have to write
‫to the only one central RDS database, okay.
‫So Read Replicas are used to scale reads.
‫Now we have Multi-AZ.
‫And so this is helpful when you have
‫to have failover in case of an AZ outage.
‫So in case in the availability zone,
‫like crashes, and this gives you high availability.
‫So in this example, your applications to read and write
‫from the same main RDS database, okay.
‫But we are going to set up
‫a replication cross AZ,
‫so in another different availability zone.
‫And this is going to be a failover database,
‫and this is why it's called Multi-AZ
‫because it's in a different AZ.
‫Now, in case the main RDS database crashes,
‫for whatever reason,
‫because maybe there's an issue with it,
‫or maybe because the AZ is having problems,
‫then RDS will trigger a failover.
‫And then your application will failover
‫to developer database in a different AZ.
‫So in this case, data is only read and written
‫to the main database.
‫The failover DB is passive,
‫it's not accessible until there is an issue
‫with the main database.
‫And you can only have one other AZ zone as a failover AZ.
‫The last kind of deployment you can do
‫is called Multi Region.
‫So this is for read replicas,
‫but this time, instead of being in the same region,
‫they are across different regions.
‫So to take an example,
‫we have EU-West one for RDS database,
‫and we're going to create a read replica in US-East two.
‫And so applications in US-East two can read locally
‫from this read replica.
‫But anytime this application needs to write data,
‫the writes need to happen across region.
‫And so we need to write the data to US one.
‫Same if you were to have also another region
‫in AP-Southeast two so in Australia,
‫you'd have the same concepts.
‫So why would you want a multi region type of deployments?
‫Well, number one,
‫because you want to set up a disaster recovery strategy,
‫in case of a region issue.
‫So if EU-West one is having a regional issue,
‫then you have a backup in either ES-East two,
‫or AP-Southeast two,
‫and this is why it's a disaster recovery strategy.
‫And also, as you can see,
‫our applications that are in different regions
‫get better performance, because they're read
‫from a local database, so they have less latency.
‫But finally, when you do this,
‫you need to understand that
‫because you are replicating data across regions,
‫then there is going to be a replication cost associated
‫with a network transfers of data between regions.
‫So that's it for RDS deployments,
‫the scenarios that will be proposed to you at the exam
‫will make it clear what department you choose.
‫So hope you liked it and I will see you in the next lecture.