All Amazon AWS Certified Solutions Architect - Associate certification exam dumps, study guide, training courses are prepared by industry experts. Amazon AWS Certified Solutions Architect - Associate certification practice test questions and answers, exam dumps, study guide and training courses help candidates to study and pass hassle-free!

EC2 Storage - EBS & EFS

11. EBS & EFS - Section Cleanup

Okay, so let's just clean up this entire section. So for this, I'm going to go to action on my file system and delete it. And for this, I have to enter the file system ID. So I'll just copy and paste this. And so, okay, we're going to get rid of our file file system. PNow that we have our easy-to-instances, make sure to terminate any easy-to-instances that are running easy to instance. So that's good. Then, in terms of volumes, we're going to have to clear up those as well. So any volumes that are available, you have to terminate them. So I'll right-click and delete all these volumes. Okay. Now for snapshots, you've made a few. Let's just go back and delete every snapshot you have just so that you can get rid of them and not pay for any storage for snapshots. Okay. And then finally, security groups, if you want to, because it's going to get a lot of security groups right here.

You can basically delete so many of the security groups except the default one for default. Just don't delete that one. So you can go ahead and delete the security groups, and they will only be deleted once. You have basically deleted all your Easy-T2 instances associated with those. So maybe these won't be deleted right away, but you can just keep trying until it works. I'll delete the security group now. Yes, this one works. I'll delete the load balancer. Security group. Yes, they worked. And this for EFS: it's still used by my instances. I have to wait for my instances to be shut down properly before I can go ahead and delete that last security group. So I'll have to wait a little bit. But that's it. Once you've cleaned up everything, you're ready to go for the next section.

12. EFS vs EBS

So now let's discuss EBS versus EFS. So EBS volumes can be attached to only one instance at a time, and they are locked into a specific availability zone. So here's an example: We have our EC2 instance in the first AZ, and the EBS volumes we can really see within that AZ are only attached to one ETW instance at a time. So we have different types of EBS volumes. Some important ones are GP 2, where the I/O will increase as the disc size increases, and IO 1, where we can increase the IO independently of the volume size. And this is great if you're running a critical database. If you want to migrate an EBS volume across different availability zones, you first need to take a snapshot.

And then, once you have the snapshot, you're going to restore it into another AZ, and that will create a new EBS volume in that AZ. And so while you do these EBS snapshots and use backups, that will use a lot of I/O on your EBS volumes. So it should be run only when your instance is not actively using your EBS volumes. Otherwise, you may have performance issues. Finally, the root EBS volumes of your instances will get terminated by default when your EC2 instance gets terminated. But this is a behaviour that you can disable if you want to. So this should be something you master right now. This is very easy. This is EBS, and this is all you need to know. And now you should know that EFS is very, very different.

So EFS is your elastic file system, and this one can be mounted to hundreds of thousands of instances across multiple availability zones. So these instances are running Linux. And as we can see, the EFS in this case is outside of our AZ because it is multi-AZ. So you can use EFS mount targets that are going to be in a specific AZ to mount between your EC2 instances all the way to your EFS drive. As a result, we can use EFS to share website files like WordPress. And as I said, it is only for Linux instances because it is a post-exchange file system. So it does not work for Windows. EFS is going to be more expensive than EBS, about three times more expensive. However, if you wanted to save money, you could use EFS infrequent access as a storage tier and a lifecycle policy to achieve these increased cost savings.

And again, what you need to remember is that for EFS, you get billed only for what you use on your EFS. In contrast, for EBS, you must provision ahead of time, assuming you know the size of the EBS drive, and you pay for the provision capacity rather than the actual use capacity. So now you should remember that EFS is really for a network file system to be mounted across multiple instances. EBS is for a network volume that needs to be mounted only on one instance, and it is locked to an AZ. An instance store is to get the maximum amount of I/O onto an EC2 instance, but it is something you lose if you lose that instance. So it is an ephemeral drive. OK, well, that's it. I hope you liked it, and I will see you in the next lecture.

AWS Fundamentals: RDS + Aurora + ElastiCache

1. AWS RDS Overview

So let's get started with an overview of AWS RDS. RDS stands for "relational database service." And what it means is that it's a managed database service for databases that use SQL as a query language. So Sequel is a structured language to query databases. It's very well adapted, and it's running on many engines. So it allows you to create databases through the RDS service in the cloud, and these databases will be managed by AWS. You get a lot of benefits from it.

So what types of database engines are managed by AWS? Well, the first one is Postgres SQL. Then we have MySQL, MariaDB, Oracle, Microsoft, SQL Server, and finally, Aurora. And we have a dedicated section for Aura. So right now, you can just forget about it. Okay, but so are the first five: PostgreSQL, Maradb, Oracle, and Microsoft SQL Server. You have to remember them. So why would we use RDS versus deploying our own database service on top of, say, an Easy-Two instance? because this is possible. Well, RDS is a managed service, and as such, it provides a lot of services on top of just giving us a database.

The provisioning of the database, for example, is fully automated, as is the patching of the underlying operating system. There are continuous backups being made, and you are able to restore to specific timestamps called point-and-time and Time Restore. You can also have monitoring dashboards to view the performance of your database. You can read replicas, and we have dedicated a lecture on reading replicas in this course. You can set up a multiple AZ to improve reading performance, and we have sections on multiple AZ that will be useful for disaster recovery. You have upgrade maintenance windows, and you can scale both vertically by increasing the instance type and horizontally by adding Replicas filing.

The storage is backed by EBS. So this is something we're already familiar with: GP two volumes or I zero one. The only thing we lack is the ability to SSH into the instances, specifically the RDS instances. So, because this is a managed service, AWS provides us with a service, and we don't have access to the underlying EC2 instance. But this is not too bad because we get all these things that we would have to set up on our own if we wanted to deploy our own database engine on EC2.

So let's talk about Ards backups for a little bit. Backups are automatically enabled in RDS, and you have automated backups. They're daily full backups of the database, which are done during the maintenance window that you define. And then the transaction logs, the daily transaction logs, are backed up by RDS every five minutes. So, when these two things are combined, you can restore your database to any point in time, from the most recent backup to five minutes ago. There is a seven-day retention for these automated backups by default, but it can be increased to 35 days. And you have database snapshots.

So snapshots are slightly different from backups. Snapshots are backups that are manually triggered by the user and the backup retention. So the snapshots will be retained for as long as you want. So they're more helpful if you want to retain the state of your database for six months at some point in time. So this is it, just for an overview of RDS. In the next lecture, I want to talk about reading, replicas, and multi-AZ. and then we'll go into more detail, so I will see you in the next lecture. So this is it, just for an overview of RDS. In the next lecture, I want to talk about reads, replicas, and multiples. Then we'll get our hands dirty. So I'll see you in the next class.

2. RDS Read Replicas vs Multi AZ

Going into the exam, it is going to be extremely important to understand the difference between RDSread replicas and multi-AZ and the exact use cases for those. So this lecture is really dedicated to understanding replicas and multi-AZ.

So let's get started with the book Replicas. Read replicas, as the name indicates, help you scale your reads. So let's have an example. Here we have our application and an RDS database instance, and our application performs reads and writes to our database instance. But say we want to scale the reads because the main database instance cannot scale enough. They receive too many requests. Well, we can create up to five read replicas, and they can be within the same availability zone, across availability zones, or across regions. So there are three different options, and they're very important to remember.

So say we have another RDS instance and another read replica, and what will happen is that there will be an asynchronous replication between the main RDS database instance and the two read replicas, which means that the reads are eventually consistent. What that means is that, for example, if your application reads from the read replica before they had the chance to replicate the data, then you may get all the data. And this is why it's called "eventually consistent asynchronous replication." And these replicas can be awesome for reading and scaling reads, but they can also be promoted to their own database. So you can take one of these replicas and declare, "OK, I want it to be its own database now," and claim ownership.

And so you promote it to its own database. After that, it is completely removed from the replication mechanism, but it continues to live and has its own lifecycle. So in case you want to use read replicas, the main application in orange at the top of the screen must update the connection string to leverage the list of all the read replicas you have in your RDS cluster. OK, very nice. So let's talk about a classic use case for your read Replica. So in this example, we have a production database, and it is taking a normal load. So here we go. Our production database is having reads and writes to our main RDS database instance, and the new team comes in and says we want to run some reporting and some analytics on top of your data. And so if you plug in that reporting application onto the main RDS database instance, then it's going to overload it and possibly slow down the production application, and you don't want that.

So instead, what you do as a solutions architect is create a replica to run the new workload there. So you create a read Replica. There is some asynchronous replication that happens between your main RDS database instance and your read replica. And then your reporting application can just do reads from your replica and run the analytics there. The production application is completely unaffected in this case, and that's perfect. So remember, if you have a read replica, you need to ensure that it is only for select types of statements. and select is a sequel keyword. Select means read, and so you cannot use keywords such as "insert," "update," or "delete," which change the database itself.

Okay? Read Replicas is only for reading purposes. Next, let's talk about replication network costs, because this is something that very, very few people know. When your data moves from one availability zone to another in AWS, there is a network cost. So, for example, we have a Zoneand ACB UST one A and UST one B, correct? And we have our main RDS database instance in one A and our replica in one B. As we replicate the data from one A to two B asynchronously because the data goes from one availability zone to another, then it's going to cross an availability zone, and that's going to cost us a lot of money. However, if you want to save money, you can have your read replica be in the same AZ.

So let's look at this example. We have one AZ this time, so we are in East One A, and we have our RDS database instance and the read replica within the same AZ. Now, when we perform asynchronous replication within the same AZ, the network cost is free because the network stays within the same AZ. Okay? I think that makes a lot of sense, but you have to say it once to really see it. Finally, let's talk about RDS multi-AZ. Multi-AZ is mainly used for disaster recovery. So we have our application, and it performs reads and writes to our master database instance, which is in availability zone A. And what we're going to have is a synchronous replication to a standby instance in AZB, and it will replicate every single change in the master synchronously.

So that means that when your application writes to the master, that change also needs to be replicated to the standby to be accepted. And so what we get out of it is one DNS name. So your application talks to one DNS name, and in case there is a problem with the master, there will be an automatic failover to the standby database thanks to that one DNS name. So thanks to this, we increased the availability.

This is why it's called Multiaz. And there will be failure in case we lose an entire AZ or the network, or there is an instance or storage failure for the master database. In which case, obviously, this new database will become the new master. You don't need to do anything manually in your apps as long as they try to connect to your database automatically. At some point, it will failover to the standby that will be promoted as the master, and you'll be good. and it's not used for scaling. So, as you can see here, the standby database is just for standby. No one can read it. No one can write to it. It's just here as a failure in case anything goes on with your master database. So, quick question: is there a possibility to have the replicas set up as multi-AZ for disaster recovery? And, yes, you can configure your replicas as a multi-AZ if you want. and that is a common exam question. Okay, so that's it for the difference between read replicas and multi-AZ. But you need to absolutely understand this going into the exam because a lot of questions will be about it. Alright, that's it. I'll see you in the next lecture for some practice.

3. AWS RDS Hands On

Okay, so let's go ahead and play with RDS. So I'm going to go to the RDS service, and we are going to create our first database in RDS. So we'll go to the Databases tab, and we'll click on Create Database. Now we are getting into this new interface, and we need to create a database. We now have the option of using the standard Create or the simple Create. Obviously, we want to learn how RDS works. So we'll not go into the easy part, because this will set everything up for us. We want to know all the options and understand how we can tune them one by one.

So we'll enter the standard Create mode. Now, as we scroll down, we can see that we have six different engine types. At the moment, we have Amazon Aura, MySQL, MariaDB, Postgres, Equal, Oracle, and Microsoft SQL Server. So if you want to use the free tier with RDS, Aura does not work. Aurora is the new kind of offering by AWS for databases, and it is not compatible with the free tier. So we'll not use Aurora in this lecture. We'll be using MySQL because it is free-tier compatible. You could also use PostgreSQL if you wanted to, but for this hands-on, it will be MySQL. So we'll use MySQL Community and a recent version, for example, 5722. Let's go down, and then we can have templates. So do we want it to be ready for production, development, testing, or the free tier? So obviously, we want to remain within the free tier.

So I click on the free tier, and this will come with a few values already set up for us. But we'll still go ahead and scroll down and see what we can do with it. So first we need to name our database, which is a database instance identifier, and this needs to be unique across your region. So I'll just call it my first MySQL. Then we need to specify credentials for the master username. So in this case, I'll choose Stefan, and then for the master password, I'll choose something very simple, for example, "password," and I'll enter the password again. So this is for the master logging in your database, and it will have admin power in it. Now we need to scroll down and look at the GB instance size.

So because we are in the free tier, we want to only have the option to do a G2 micro. So all the other options are greyed out for the very reason that we have specified that we want the free tier. So it's a safety, but if you click on deftest or production, then we would have access to all the different kinds of instances. We can select from standard, memory optimized, and other options. So in this case, we'll continue with the DB TWO micro, which has one vCPU and 1 GB of RAM. Then we need to learn about how much storage we want for our database. In our case, we want SSD storage and 20 GB. This is something that is available only for features, so it can be up to 20, and sometimes you get these really weird UI quirks. So if you get this, just increase to 21 and then back to 20, and it will be fixed.

Now that we've enabled storage auto scaling, we can proceed. That means that if we keep on writing to our database and we reach this 20 GB of storage, it will automatically increase it for us. So we don't have to do it for now, but I will disable it and we'll go right back to 20. So, what do we do now for availability and durability? Do we want to have multiple AZs? So multi-AZ, as we saw, is a way to have a standby database instance ready for use in case an availability zone goes down. And so this is something we definitely want in production, but this is not something that's available to us when we do the free tier. Therefore, this option is disabled. However, if we wanted to have production and ensure that one AZ could go down and we could still use our database, multiple AWS deployments would be the way to go. Now, you launch your database in a VPCor virtual private cloud for connectivity, and as such, we'll use the default VC that has been created for us.

When we created our account to launch our database, we could specify additional connectivity configurations, and one that's very important is whether or not we want this database to be publicly accessible. So in most cases, you will not want your database to be accessible publicly because you just want it to be available within your virtual private cloud, or VPC.

However, because we want to connect to our database in this hands-on just to demonstrate that it works, we'll use yes and allow connections to our database directly from our machine. Now, for the security group, we can choose an existing security group or create a new one that will be directly created for us for this database. So I'll just enter my first RDS as security group Gand, and then where do we want this database to be created? There is no preference, but we could choose among three A, three B, or three C.

Okay, finally, the database port is the standard port for MySQL, which is 3306. We'll scroll down and look at additional configurations. So the initial database name will be Mydb. This way will be automatically created by RDS, the parameter group we don't touch. Right now we could have IAMDB authentication, which means that we could connect to a database directly using imusers and roles, but we won't enable it right now. We just need to remember that it is an option. For now, we'll just connect to our database using the standard username and password that we created before, but it's good to know that it's an option.

And then, do we want to have backups? Yes, we want to have automatic backups. And how long do we want to retain these backups? for seven days, all the way to 35 days. So I'll just keep it at seven days. The backup window So do we want to specify a specific window of time when we want RDS to perform our backups, or do we have no preference?

So I'll just keep no preference. Finally, we want enhanced monitoring to get more metrics, such as the number of threads and so on, from log exports. We don't need to specify anything if we want to export the logs into a service called AmazonCloud Watch Logs and use the Im role to do all of this; we only need to do it if one of these boxes is checked, so scroll down. Do we want to enable auto-upgrade to minor versions?

What do you mean? Because RDS is a managed service, we definitely want it to automatically upgrade our database for minor versions. automatically, and they will happen during the maintenance windows of the database. And for the maintenance window, what preference do we have? Do we want to have a specific day, start time, and duration, or do we have no preference? Finally, the last one, and we're all good to go. We'll have deletion protection, and if we click on this, that means that we won't be able to delete our database without first removing the deletion protection. So I'll leave this unticked for now. So here we go.

We see that this RDS is in the free tier. We are given TWO micro-instances. So this is good. So we have a single AZ rather than multiple AZs, 20 GB of SSD storage, 20 GB of automatic backup storage, and so on. So click on Create Database, and here we go. The database should be created, and this may take a few minutes to launch. So I'll be right back by clicking on the database right here. I'll be right back when this is done. So while my instance is still being created, I want to show you a little SQL programme I like, which is called SQL Electron. And SQL Electron is essentially your database's database engine.

And so it works for Linux, Macs, and Windows. That's why I like it. And it gives you a GUI. So a graphical user interface is needed to connect to your database. So I invite you to download the GUI and then install it on your computer. Basically, you go to the GitHub page, and here, if you're a Mac, you use DMG. If you're on Windows, you use the Wind package, and if you're on Linux, you can use the Sh package or the DBN and RPM. So once you download it and install it, my SQL Electron is installed, and I click Add. And from here, I can add a connection to my RDS database, give it a name, and create a MySQL database. Now you put the server address, the port, and so on. So for this, we can go back to our page, and now we can see that the instance is backing up. So it's been created. And if we scroll all the way down, we can see a connect block with the endpoint. And the endpoint is basically the URL I need to use to connect to my database.

And the port is 3, 3, 6, and it's publicly accessible, so I should be able to access it from within my computer. So let's hope for this: I copy this and put the server address right here, and then the username is going to be Stefan and the password is going to be Password. So it looks good. Now we'd be able to enable SSL if we wanted to have a secure connection, but for now we're good.

So we simply click "Test," and the connection test shows that we are connected. Happy days. I save it, and it connects to my database. And here I am, in my database, and we can see my DB on the left hand side. This is the database that was created first for us. You don't have to be a sequel expert to use Mysequel or a database, but this isn't a SQL course, so as soon as we connected, we knew everything worked, and that was the end of the hands-on. OK, what you should do is make note of all the connections and options you had when creating this RDS database, including the fact that there's a security group that was created for your instance, and you can click on it to go and see the details of your security group.

So we can see that it authorises my IP on port 3306, which is good, and you can see all the network and security configurations, if you're a backup, if you're multiaz, et cetera, et cetera. So this is quite nice. The last thing you can do is perform instance actions, and as you can see on the right hand side, we could stop it, reboot it, and create a read-only replica.

So if we wanted to create a read replica, we could just click here and have a second database that we could connect to just for reads. We can also take a snapshot to create a backup of ourselves and then go back in time using the backups to migrate a snapshot if you want to move it to another region. So I hope that was helpful. That was a quick overview of RDS, but we're able to create a database, MySQL can connect to it using SQL Electron, and basically, this is a database that's available for our application to use if they need one. Okay, so that was it; I hope you enjoyed it, and I will see you in the next lecture.

AWS Certified Solutions Architect - Associate certification practice test questions and answers, training course, study guide are uploaded in ETE files format by real users. Study and pass Amazon AWS Certified Solutions Architect - Associate certification exam dumps & practice test questions and answers are the best available resource to help students pass at the first attempt.