RDS vs. EC2
Amazon RDS Costs
Amazon RDS Performance Insights
Which database service should I use?
Using Automation to Deploy AWS Databases
Data Lakes in AWS
The course is part of this learning path
This section of the AWS Certified Solutions Architect - Professional learning path introduces you to the AWS database services relevant to the SAP-C02 exam. We then understand the service options available and learn how to select and apply AWS database services to meet specific design scenarios relevant to the AWS Certified Solutions Architect - Professional exam.
Want more? Try a Lab Playground or do a Lab Challenge!
- Understand the various database services that can be used when building cloud solutions on AWS
- Learn how to build databases using Amazon RDS, DynamoDB, Redshift, DocumentDB, Keyspaces, and QLDB
- Learn how to create ElastiCache and Neptune clusters
- Understand which AWS database service to choose based on your requirements
- Discover how to use automation to deploy databases in AWS
- Learn about data lakes and how to build a data lake in AWS
Hello, and welcome to this lecture that is going to focus on the first of the database services that I'll be looking at in this course, that being the Amazon Relational Database Service commonly known as RDS. Let me examine the different methods of performing a backup of RDS databases first.
When you are looking into backup your RDS database, you effectively have three different options or methods of doing so involving both automatic and manual procedures. Firstly RDS offers the ability to provide automatic backups of your RDS instance. Notice I said instance and not just the RDS database table itself. Secondly, you can perform a manual backup using snapshots. And lastly, you can use the AWS backup service to also create a backup of your RDS database. And even though you're using an AWS managed service in this case which can automate backups for you using AWS backup, it is still considered a manual backup from an RDS perspective.
Let me look at each of these methods in more detail, starting with RDS automated backups. As with most automation within AWS, automated backups offers a level of assurance that the task is going to be completed and removes the unreliability of the human nature in people to perform the backup themselves.
When configuring your automatic backups for your RDS database, you have a number of different parameters to apply to the automatic backup settings, such as retention period, and the backup window as seen here. The automated backups themselves are performed daily and the backup retention period determines how long RDS will keep and maintain your backups for, and this can be set between zero and 35 days.
For automatic backups to take place, the retention period must be set to at least one day. If the retention is set to zero, then automatic backups will not take place. If you create your database using the AWS CLI, then a default retention period of one day will be configured. Whereas if using a console, the default is seven days.
The backup window allows you to define a time period in which the backup snapshots should be taken. And this allows you to set it at a time when the database itself will be of low utilization to prevent the backup process impacting the performance of the database itself.
During the first few seconds of the automatic backup process, your storage IO might temporarily be stopped. However, if you're using a Multi-AZ configuration, then the backup will not affect your storage IO as the backup will be taken from the standby instance for the database and not the primary.
For more information on Multi-AZ configurations please see our existing course here. If the backup fails to complete inside the time window you specified, the backup will extend past the timeframe to ensure it completes. However, you must ensure that any backup window that you schedule does not overlap with the maintenance window that you configure for your database.
Failure to select your own backup window will result in AWS scheduling its own 30-minute time period based across an eight-hour window. And this window is depending on which region you are deploying your RDS database in. And all window times are based on the UTC time zone.
Once the configuration is complete and your RDS database is being backed up, you are able to restore back to any point in time during retention period, known as point-in-time-recovery. And I'll cover more on this when we come to looking at restoring your RDS database.
As a part of the automated daily backup process, RDS also captures any transaction logs that have been created as, and when updates to your database was made. And this is to ensure that it can perform a point-in-time recovery. If you're curious as to where these backups are stored, RDS automatically stores them on Amazon S3. And so they remain highly available and highly durable.
You can also see from the screenshot that it states automated snapshots are only supported for the InnoDB storage engine and not MyISAM. This is because MyISAM does not support reliable crash recovery which could result in corruption when trying to perform a point-in-time-recovery. Whereas InnoDB is a crash-recoverable storage engine.
So now we have all of these automated backups. What happens when you delete your database? What happens to the automated backups then? When you delete your database instance you'll be given the option to perform a final database snapshot. By doing so you'll be able to restore your database to the configuration of that instance at that point, if needed at a later stage.
When you delete your database instance you can retain your automated backups if you are running MySQL, MariaDB, PostgreSQL, Oracle, and Microsoft SQL server engines. But they'll only last as long as the retention period would allow them to. So they will eventually expire.
So as a result, if you want to maintain a backup to restore from at a later stage, then ensure you select to create that final database backup when prompted before deleting your instance as this will not automatically expire. Also, if you have created any manual backups snapshots these will also be retained.
So let me talk more about the manual backups, which, as I mentioned earlier, is the second method of backing up your RDSdatabase. In addition to the automatic backups that I just explained and discussed you can also create your own user-initiated manual backups known as database snapshots these snapshots back up your database instance in the state at the time of the backup. They do not offer the ability to perform point-in-time recovery, instead, the database will be restored to how it was at the point in time the backup was taken.
When you create your first backup, a full backup is taken capturing the whole database instance. Any subsequent backups that are taken of the same database instance, then an incremental backup will be taken. And this means that only the data that has changed since the last backup will be backed up. And this helps to save on storage space.
Unlike automated backups, database snapshots are not restricted by any retention periods. As a result, your database snapshots will remain for as long as required without expiration until you explicitly delete them.
Let's now look at how you create a database snapshot for an RDS database, which is a very simple process from within the AWS management console. However it can also be accomplished via the createDBSnapshot API, or via the AWS CLI command online using create-db-snapshot.
Okay, so I'm logged into the AWS management console as you can see, and I'm within the RDS dashboard. Now under databases, I have a single instance here. Now to create a manual snapshot of this database, all I need to do is to ensure that I have the database selected, then go across to actions and down to take snapshot. Now, here I can enter the snapshot name, so I can just call this Mysnapshot. And then I just need to go across to take snapshot.
Now, as we can see, the snapshot is in the status of creating, it has the snapshot name and the instance that the snapshot was taken off. And remember, these manual snapshots will create a backup of the database as it stands right now.
Okay, that's completed. We can now say the status is showing as available. And you can scroll along to see other values of this snapshot as well, for example, the engine that was used, the VPC, the storage, the availability zone, etc, etc. And you can select the snapshot to get additional information too.
Down here under recent events, it will show you the time that the snapshot was being created and also when the snapshot had been successfully created. So it's very simple and easy to create a manual snapshot of your database. Now, if you wanted to do this using the command line and we can do this by using a simple command, let's take a look.
So the command I need to type in is aws rds create-db-snapshot. Then I need to enter the database snapshot identifier. And this will be the name of the snapshot. So I'm just gonna call this CLISnapshot. I then need to enter the name of the database instance identifier. And this is the name of the database instance that I want to create a snapshot from.
So if we go back to the console to double check that we can see that it's my-db-instance. So what this command will do it'll create a database snapshot using this as the name of the snapshot and it will take this from this database instance. And then we go, that snapshot is now created. So if we go back to the management console and look under our snapshots we should see this new name of clisnapshot. Let's take a look.
So if we go cross to our snapshots. And there we have it, the clisnapshot. And as you see at the moment, the status is currently creating. So it's very easy to create a manual snapshot either through the AWS management console or using the AWS CLI. As I mentioned at the beginning of this lecture, you can also use AWS backup to perform the backup of your RDS databases which are classed as manual backups like the database snapshot that we just created.
For those unfamiliar with AWS backup, AWS backup acts as a central hub to manage backups across your environment, across multiple regions, centralizing management and providing full audit capabilities in addition to assisting with specific compliance controls.
Having a managed service to monitor and control your backups allows for all logins to be consolidated in a single place. In addition to seeing the status of completed backups and perform any restores required. The service itself uses backup features from existing services. So for example, when using AWS backup with RDS, AWS backup would manage these through the database snapshot functionality as we did previously.
When using AWS backup you will need to create backup policies or backup plans, and they simply determine the exact requirements that you need for your backups. Once you've created your backup plans you can then assign resources to them. And this allows you to create multiple backup plans each with different criteria to meet the backup needs of different types of resources.
At the time of writing this course, AWS backup supports all database engines, other than Aurora. However, this would likely change over time. So be sure to check with the AWS documentation for all supported database engines.
Course Introduction - Restoring an RDS Database - Copying & Sharing RDS Snapshots - Amazon DynamoDB Backup Capabilities - Restoring an Amazon DynamoDB Database - Course Summary
Danny has over 20 years of IT experience as a software developer, cloud engineer, and technical trainer. After attending a conference on cloud computing in 2009, he knew he wanted to build his career around what was still a very new, emerging technology at the time — and share this transformational knowledge with others. He has spoken to IT professional audiences at local, regional, and national user groups and conferences. He has delivered in-person classroom and virtual training, interactive webinars, and authored video training courses covering many different technologies, including Amazon Web Services. He currently has six active AWS certifications, including certifications at the Professional and Specialty level.