Hi and welcome to this lecture.

In this lecture, we will do the RDS deployment. We will do as we did for the other deployments, and we'll talk about the planning phase first. I will show you the needed changes. Then we'll go to the AWS console and deploy a new RDS instance. We will configure it to be Multi-AZ, and we also configure Route 53 in the end.

This is what we have right now. We have a domain, more or less deployed because we still will do some changes in the final section of this course, so it's, I'd say, 50% deployed. We already have a web distribution. We have our Angular app deployed in an S3 bucket. We have elastic load balancers and auto scaling deployed in both Oregon and San Paulo regions, but we haven't really touched the RDS part yet. And what we will do is we will migrate from MySQL to Amazon Aurora, but we will not deploy a cross-region read replica.

I will not show you that because you don't need to know how to deploy a cross-region read replica. You just need to know what a cross-region read replica is and what you can accomplish with a cross-region read replica. So for the time's sake, I won't show you that, but that's not really much different from creating a Multi-AZ database for Aurora as you might see.

We will also create a replica, but the replica won't be hosted in the same region. The replica will be hosted in a different region, but the process is more or less the same. We won't talk about the process, but it's really simple.

So Amazon Aurora. We will use Amazon Aurora, which is basically an Amazon implementation of a MySQL database, and for me, the best quality of Amazon Aurora is that it has built-in scalability. We don't need to worry about the storage. We don't need to provision how much storage we need. AWS will handle the storage automatically. It will increase and decrease the storage capacity as we need, as we use the database. So that's awesome. We don't need to do any maintenance in our database in order to scale it up or down.

Also, Amazon RDS replicates our data across all availability zones in the region so our data is always secure. Only if the whole region goes down, we will lose our data, and that's when a cross-region replica comes handy. So let's go to the AWS console and do the RDS deployment.

So here at the AWS console in the Oregon region, we go to the RDS console, and the first thing that we want to do is stop all the database connections. So if we were dealing with a production application, which we are not, we would have to schedule a maintenance window because since we are going to move away from a database engine, and we are going to create another database, we will take a snapshot. And if we take a snapshot, and we have changes made after that snapshot in our database, those changes will not be sent to the new database. So you lose some data. Therefore, it's important that you stop all database connection.

So let's imagine that we scheduled a maintenance window. Our application is now down, and we will go select our database and take a new snapshot. I will call this snapshot migration, and I will take this snapshot. It will take a fair amount of time, so I will pause the recording and get back once it's done.

Okay, our snapshot was created, but before we go ahead and launch a new database, I want to do things right this time. So first, I will create a new security group for our RDS database. So for that, I will go to the VPC console, and I will create a new security group inside the VPC that we created in the VPC deployment lecture. We go in Security Groups, and we create a new one. And that will be called pizza-time-rds-security group. Description will be the security group for rds, and we must create this security group inside the VPC that we created. Everything is set.

Now we can go back to RDS. Here, on the RDS console, there is also other thing that I want to configure. I want to configure a subnet group. We already having here the default DB subnet group, and this group has all the subnets inside the default VPC.

So since we created a new VPC, we want to create a new DB subnet group if we want to launch our RDS database inside our new VPC. So clicking here to create a new subnet group, and I will call it pizza-time- sub-group. Put some description, and we need to select our pizza-time VPC. And we have the ability to select the availability zones and the subnet IDs of that zones. These subnets, they all live inside the pizza-time VPC, and we can also add all the subnets. I really like this option.

And then we don't want to use the public VPC, so if you recall from our VPC deployment lecture, the first subnets, one to three, are the public subnets. So we can remove those, and these are the private subnets. These are the subnets that we want, and we have one subnet in each availability zone.

So I click on Create, and now we can go ahead and really deploy our new RDS database. We must go in Snapshot. We select the snapshot that we created, and we select Migrate Snapshot. And we want to use Aurora as our DB engine, and we will use the smallest instance type available.

I will call this instance pizza-time-db-oregon because now we are going to use RDS in more than one region, so I want to put the region name here and we want to use the pizza-time VPC.

RDS already selected the pizza-time-sub-group that we just created, and we don't want to have our instance public accessible. Instead, we want only that the instances inside our VPC have access to our RDS instance.

Database port will be the same. We don't want to encrypt our database, and we will allow auto minor version upgrade, so we won't need to stop the instance and schedule a maintenance window to do minor versions upgrades.

Click on Migrate, and now we have to wait. AWS will deploy a whole new RDS instance and will take the data from the snapshot that we just created and apply to the new instance. So I will stop the recording and get back once it's done.

Okay, our Aurora database is deployed. We can see the results in here, but we can also see something a bit frustrating. It is not Multi-AZ already. And you might have heard that Amazon Aurora replicates your data across all the availability zones, and that's correct, but that doesn't mean that you also have instances in more than one availability zone. So your data will be safe in case of a problem, but you still have a downtime if you don't deploy a second database instance. And it's not so easy to deploy a Multi-AZ database with Aurora.

For example, if we go in here and select Modify as we did for the MySQL database, we don't have the option to turn this database into a Multi-AZ database. So we can't do much in here. The only thing that I will do in here is select the RDS security group that we just created, and I want to apply this immediately. I will modify the instance, but the instance isn't Multi-AZ already. To create a Multi-AZ database with Aurora, we need to create instead a replica. And for the replica, we need to specify a few things.

We will specify the instance identifier. That will be pizza-time- db-oregon- replica. That will not be public accessible, and we just need to make sure that we will not launch this instance in the same availability zone of the other one. So I will go and check where our main instance is. I will launch our second Aurora instance in a different availability zone. So this instance right now is in the availability zone b, and so we will select a different one. I will select this c, and we have the failover priority in here. That's super important. So we have tiers for failover. The smallest number means the highest priority in case of a failover. So during a failover, AWS can promote this replica, and we need to select the priority in here. I will say that that will be tier-0. That will be the highest priority, And I will leave the other settings as default, and I will create the Aurora replica.

Okay, our database instance replica is deployed. We can see that in here. It has a particular endpoint, the same for the main database. And we can see for both of these instances, that now, it is showing that we have two zones in the Multi-AZ field, and it also has an additional information. It says which database is the writer and which database is the reader. So this database right now is the main database, and this is the standby database. And we can simulate a failover by selecting the first database and clicking on Failover, and that will failover from the main database to the standby database.

This is happening because we have created actually a cluster. When we create a new Aurora instance, we are actually creating a new cluster, and we can see the cluster in here. The cluster has its own endpoint, and we can see the instances that are members of this particular cluster. If we refresh that, we can now see that the oregon replica now has the writer role, and the db-oregon, which was our main database, now has the reader role. So these databases changed their role. So in case of a failover, this will happen automatically, and we will not need to worry about that.

So just out of curiosity, if we wanted to create a new cross-region read replica for our DB cluster, the first thing that we would have to do is create a new parameter group for our RDS cluster. The parameter groups are a way to configure a specific behavior for your database instances or clusters.

Remember that RDS is a managed service, so you don't have access inside the instance itself. So in order to have a particular behavior, you'd have to create a parameter group, and that parameter group would have to be a cluster parameter group, and we would have to change a few settings. I will not show that. After that, you'd assign the new parameter group to the cluster. We would go here, modify the cluster, and select a different parameter group. We only have one here, so there is no way to change that right now.

Then, you would go on the writer database, and you'd select Create Cross Region Read Replica. And as you can see, this is the same screen that we used to create a regular replica inside our region. The only difference is that we can already deploy a Multi-AZ read replica, and that would create more than one read replica in the target region.

The other things you already know about. And as we also have in here, for example, the priority, and we could select the region and the subnet group and so on.

I will not go further than that, so let's now go to our EC2 console because we need to change the security group for our database instances. As you can see, it is not allowing inbound connections right now, so we need to change that.

Let's go the EC2 console. And we created a new security group for these RDS instances, so we need to allow inbound access to our EC2 instances. So we select the RDS security group, and we say that we want to allow all traffic to everybody inside our VPC. We will reveal these entries in the security section of this course, but that will work for us at this point. So click Save.

And remember that we also created a Route 53 entry for our database instance. Now we have to update that. So we will use the cluster endpoint this time. We will not use the endpoint for our particular instance because that would not make automatic failover possible.

So now we go to the Route 53 console, and we will update the DB entry. We go on Hosted zones. We select our zone, and we select the DB entry, and in here we can update our URL. We click on Save Record Set, and that will take a few minutes to apply. Let's wait till the DNS information propagates across the DNS servers, and I will get back once it's done just to show you that our pizza time application is up and running in the new RDS database.

Our application is already working. We can make login, and we can also see the orders in here. So we didn't lose any data. The data is here because we migrated our database from a snapshot of the previous database.

So right now, what we can do is we can select the old database, and we can delete this database. And we don't want to create a final snapshot because we already have one. We have the snapshot that we created for the migration, and we can simply delete that database.

And as you can see, if I clicking here and refresh the page, we will still be able to see the orders because we are not connecting to the old database.

RDS deployment

About