Protecting your data with AWS Backup
In January 2019, AWS launched AWS Backup, a fully managed backup service that makes it easy to centralize and automate the backup of data across AWS services. As of July 2019, AWS Backup integrates with:
- Amazon EBS
- Amazon EFS
- Amazon RDS (all engines except Amazon Aurora)
- Amazon DynamoDB
- AWS Storage Gateway (Volume Gateway)
Before the launch of AWS Backup, customers had to separately schedule backups from native service consoles. This overhead was also present when there was a need to change backup schedules, or initiate a restore across multiple AWS services. AWS Backup solves this problem by providing customers with a single pane of glass to create/maintain backup schedules, perform restores, and monitor backup/restore jobs.
Because AWS Backup natively integrates with EFS, any I/O operations initiated by AWS Backup will not count against EFS burst credits or the general-purpose mode limits. AWS Backup also provides an option to transition your EFS file system backups from warm storage to a lower-cost, cold-storage tier. The most up-to-date pricing information for EFS backups and restores can be found on the AWS Backup pricing page.
Other AWS Services
When using AWS Backup with EBS, RDS, DynamoDB and Storage Gateway, there’s no additional charge to use it. Customers continue to pay what they currently pay for snapshot storage and restore costs that are charged by the underlying service. AWS Backup will create an incremental snapshot for all services except for DynamoDB. When backing up DynamoDB, AWS Backup creates on-demand backups of DynamoDB tables, which are full backups.
Working with Resource Assignments
AWS Backup supports two ways to assign resources to a backup plan: by tag or by resource ID. Using tags is the recommended approach for several reasons:
- It’s an easy way to ensure that any new resources are automatically added to a backup plan, just by adding a tag.
- Because resource IDs are static, managing a backup plan can become burdensome, as resource IDs must be added or removed over time.
Here are some recommendations to help make the best use of tags with AWS Backup:
AWS Backup allows customers to assign resources via multiple tags to a backup plan. The plan backs up resources matching any of the tag keys that are specified in a backup plan’s resource assignment. In the example shown in the below screenshot, the backup plan backs up all supported resources that match either the Application:Ecommerce or the Application:Datawarehouse tags:
Tagging by Environment
Resources, schedules, retention and lifecycle rules are all contained within a backup plan. When planning a tagging strategy for use with AWS Backup, I recommend using a tagging strategy that incorporates these similarities.
A great way to accomplish this is to separate tags by environment (Production/Nonproduction or Production/QA/Test/Dev), where there is typically much commonality around scheduling and retention/lifecycle rules.
Organizational Tagging Strategy
If your organization has not yet implemented a comprehensive tagging strategy, it’s something that I highly recommend. Yes, it makes assigning resources to backup plans easier, but it also helps organizations manage, search, and report on resources within AWS environments at scale. For those who are new to tagging, I recommend reviewing AWS Tagging Strategies, which provides best practices for planning a tagging strategy.
Working with Schedules
When creating a backup plan, you must define at least one set of backup rules that define the schedule, window, lifecycle rules, and other features. A simple backup schedule can be created by using the dropdown menus.
For more complex scheduling needs, AWS Backup provides the ability to define cron expressions. Cron expressions are a great way to define complex schedules as part of a backup plan. AWS Backup uses the Amazon CloudWatch Events style of cron expressions, which makes it easy to define complex schedules.
When using cron expressions in AWS Backup, keep in mind the following:
- All time-based expressions in AWS Backup schedules are in the UTC time zone.
- When scheduling your backups via cron, the numerical values for Day-of-Week differ from UNIX/LINUX-based cron schedules. In the CloudWatch Events style of cron expressions, Sunday has the value of 1 and Saturday has a value of 7. For more information, see CloudWatch Events cron expressions.
- The minimum supported frequency of a backup schedule is once every 12 hours.
Let’s walkthrough a sample monthly Backup rule that makes use of cron expressions:
- I’ve used a cron expression in my Backup rule that starts the backup window at 0600 UTC on the first Saturday of every month. Backup windows are periods of time that define when the resources in a backup plan start. I’ve customized my backup window to be two hours in duration.
- I’ve defined a lifecycle policy to transition my EFS backups to cold storage 90 days after creation. Transition to cold storage will only apply to EFS backups, and there is a minimum of 90 days before any EFS backups can be transitioned to cold storage. I’ve also set the backups in this plan to expire 7 years after after they are created.
- I’ve set my Backup vault to the Default vault. A Backup vault is a logical container that is used by AWS Backup for storing, managing and protecting backups. I’ve also added a tag to each of my recovery points (snapshots) as they are created, which helps to identify snapshots outside of AWS Backup.
Here are some additional hints and tips for working with AWS Backup:
There may be cases where, for audit or compliance purposes, you must identify the relationship of a deleted resource with a recovery point in AWS Backup. For example, you may have EBS volume snapshots going back a number of years after an underlying Amazon EC2 instance was terminated. You must be able to provide evidence to an auditor that the EBS volume for your snapshot was associated with the terminated EC2 instance.
For situations like these, I recommend enabling AWS Config configuration recording of your AWS resources. This helps identify and track AWS resource relationships (including deleted resources) for up to seven years.
If you use any scripts or AWS Lambda functions to take snapshots of AWS resources that are also being protected by AWS Backup, I recommend ensuring that there is no overlap between AWS Backup and your scripts/Lambda functions, as this can lead to backup job failures.
Regional Resource Assignments
AWS Backup supports resource assignments within the same Region. Separate backup plans must be created to back up AWS resources within that Region. For an up-to-date listing of Regions currently supported by AWS Backup, see the AWS Region table.
Generally, the most comprehensive data-protection strategies include regular testing and validation of your restore procedures before you need them. Testing your restores also helps in preparing and maintaining recovery runbooks. That, in turn, ensures operational readiness during a disaster recovery exercise, or an actual data loss scenario.
When using AWS Backup with encrypted resources, such as EBS volumes, the AWS Backup IAM service role must be granted permissions to the AWS KMS keys used to encrypt your resources. For more information about adding the default service role AWSBackupDefaultServiceRole as a new KMS key user, see Editing Keys.
As your AWS footprint grows over time, the number of snapshots in your account will also grow. You will want to review your service limits on a regular basis to ensure you aren’t in danger of getting close to snapshot-related service limits, which can cause your backups to fail. An easy way to keep track of these and other service limits is to utilize AWS Trusted Advisor , as it will report on major service limits regardless of which support plan you subscribe to. In the event that you notice any service limits reaching the Yellow or Red Criteria, you can open a Service Limit Increase case for the protected service (i.e. RDS, EBS, etc.) through the AWS Support Center. You can find more information on managing service limits and requesting service limit increases in our AWS Support Knowledge Center
AWS Backup and APN Storage Partners
I’m often asked, “How does AWS Backup relate to our APN Storage Partner Solutions?” I think it’s important to understand that AWS Backup complements our Partners’ ability to deliver value to their customers.
For our Partners, AWS Backup makes it easier and faster to work with AWS services, providing them the ability to integrate with all of the AWS services that AWS Backup supports through a single API set. By providing a single point of interaction with all AWS services, AWS Backup can lower the development timeline and help accelerate time-to-customer value in our Partner solutions.
Through a single purpose-built API, AWS Backup enables partners to quickly support new AWS services that have native backup capabilities. It also supports services that don’t have a native backup API, such as Amazon EFS.
In this post, I’ve provided an overview of AWS Backup and offered suggestions for scheduling backups and assigning resources. I’ve also given hints and tips to help you get started using AWS Backup, and discussed how AWS Backup adds value to our APN Storage Partner Solutions. If you have any questions, comments or suggestions, please reach out to us in the AWS Backup Discussion Forums