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

Lectures

Course Introduction - RDS Backup Capabilities - Restoring an RDS Database - Amazon DynamoDB Backup Capabilities - Restoring an Amazon DynamoDB Database - Course Summary