Amazon Relational Database Service
The course is part of this learning path
This course explores the different strategies that are available for when you need to both back up and restore your AWS databases across Amazon Relational Database Service (RDS) and Amazon DynamoDB. During this course, you will learn about the different backup features that are available in Amazon RDS and DynamoDB, how to identify the differences between them, and when you should use one over the other. The course also explains how to copy and share RDS snapshots across regions and AWS accounts.
The concepts covered in this course are complemented with guided demonstrations from the AWS platform, to ensure you get a real-world understanding of them. If you have any feedback relating to this course, feel free to get in touch with us at firstname.lastname@example.org.
- Introduce you to the different backup features that are available in Amazon RDS and DynamoDB
- Identify the differences between the different backup features and when you should use one over the other
- Explain how to copy and share RDS snapshots across regions and AWS accounts
This course has been designed for those who are responsible for maintaining AWS database solutions at an operational level. It is also suitable for anyone looking to take the AWS Certified Database Specialty certification.
To get the most out of this course, you should be familiar with Amazon RDS and Amazon DynamoDB at a foundational level. For more information on these databases, please see our existing course here.
Hello and welcome to this short lecture where I want to focus at a high level on some of the data backup management points when working with your RDS database snapshots.
We know the importance and criticality of performing backups within your production environment, but once you have those backups, what should you do with them next, if anything at all?
You might want to copy, share, or export your snapshot depending on your business requirements and level of resiliency that you want to implement.
When working with RDS snapshots you can copy your snapshots, which you might want to do if you need to run or restore your database in a region. You can copy your snapshots using both your automated or manual snapshots, within the same region, or if required to a different AWS region altogether. You can also copy your snapshots across AWS accounts as well.
If the source snapshot that you are copying is an automated snapshot, then the target snapshot will be classed as a manual snapshot instead of automated.
If you copy a snapshot to a different region then you must ensure that the target region supports cross-region snapshot copies. For more information on those regions, please review the following URL.
When a snapshot is copied, then you should be aware that both the database option group and the parameter group configurations will not be copied, instead, in the target region, it will use the defaults in that region for both of these instead. As best practice, you should perform the following steps when copying to another region:
- Create a new option group and parameter group in the target region that replicates the same settings as the source database that the snapshot is taken from
- Copy the snapshot to the new region
- If you perform a restore from that snapshot modify the DB instance and select the new Option group and parameter groups
If you are working with an encrypted snapshot then there are a few things you need to be aware of. If a snapshot is taken from an encrypted database, then the snapshot will also be encrypted through the use of a KMS key. If you copy the snapshot to the same region as the source snapshot, then you can use the same KMS encryption key. However, if you copy the encrypted snapshot to a different region, then during the copy configuration you will need to specify a new KMS key in the target region, this is because KMS is a regional service, and KMS keys only exist in one region.
As a part of the copy process, you can choose to encrypt an unencrypted snapshot by selecting a KMS key. This provides the opportunity to create an encrypted version of an unencrypted database. You can take your source database, create a snapshot, copy the snapshot, and select a new KMS key to encrypt it with, and then restore the database using that encrypted snapshot. This will result in a new encrypted database instance.
Let’s now take a look at some principles around sharing a snapshot, rather than copying one.
Sharing snapshots allows other AWS accounts to access the snapshot, which can either be encrypted or unencrypted. When sharing your snapshot, you can either set the share to be public (if unencrypted) or private. A publicly shared snapshot is available to everyone, so be very careful with this option as you do not want to share any confidential information that may be present within your database. If you share it privately, you can specify which AWS accounts have access to the share, which is of course far more secure than the public option, and it also allows you to share encrypted snapshots.
It is worth mentioning that you can only share manual snapshots, and not automated snapshots. However, an easy way to get around this would be to copy the automated snapshot, which as I explained previously, then becomes a manual snapshot, so now you can share this new manual snapshot as needed.
By sharing your snapshots with another AWS account, it allows that account to take a copy of the snapshot, which they can then restore from within their own account. So sharing your snapshot is a useful way if you need to move your database from one account to another with relative ease.
When working with encryption, there are a few points to bear in mind when sharing encrypted snapshots.
- Firstly, as we already know, it is not possible to share an encrypted snapshot with the Public option
- You are not able to share a snapshot that has been encrypted with the default KMS key of the source account
- You can’t share snapshots that are encrypted with transparent data encryption (TDE) used with Oracle or Microsoft SQL Server
- If you have used a customer created CMK within KMS to encrypt your source database, then you must ensure that the same KMS key is allowed to be used by the target account. More information on how to share CMKs between different AWS accounts can be found in our existing course here
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 90+ courses relating to Cloud reaching over 100,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.