High Availability in RDS
Designing for high availability, fault tolerance and cost efficiency
Business Continuity and Disaster Recovery for SAP on AWS
The course is part of this learning path
** Not all content covered in the course introduction has been added to the course at this time. Additional content is scheduled to be added to this course in the future. **
In this section of the AWS Certified: SAP on AWS Specialty learning path, we introduce you to strategies for configuring high availability and disaster recovery for SAP workloads on AWS.
- Understand how to configure high availability with Amazon RDS
- Identify backup and disaster recovery strategies using the AWS Cloud
- Describe various approaches for business continuity and diaster recovery for SAP workloads on AWS
The AWS Certified: SAP on AWS Specialty certification has been designed for anyone who has experience managing and operating SAP workloads. Ideally you’ll also have some exposure to the design and implementation of SAP workloads on AWS, including migrating these workloads from on-premises environments. Many exam questions will require a solutions architect level of knowledge for many AWS services. All of the AWS Cloud concepts introduced in this course will be explained and reinforced from the ground up.
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
Course Introduction - RDS Backup Capabilities - Restoring an RDS Database - Amazon DynamoDB Backup Capabilities - Restoring an Amazon DynamoDB Database - Course Summary
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 150+ courses relating to Cloud reaching over 180,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.