First Look at AWS Backup

One of the glaring misses in the AWS portfolio had been a consolidated, concise mechanism for backing up all yo’ stuffs without having to go 3rd party. While I am a *huge* fan of the Veeam product line…as of now you can’t use it to back up Amazon Relational Database Service (RDS) (as well as several other native services), so creating a backup strategy for your cloud services has generally been a mixed bag of concessions, stopgaps, and multi-product/process approaches if you are using more than just Amazon Elastic Compute Cloud (EC2) and Amazon Simple Storage Service (S3). Sure you can use the Amazon Relational Database Service (RDS) native backup options, but what about when you want to have a crash consistent (or even better application consistent!) backup of your whole stack from a certain point in time? Queue AWS Backup. In this article I’m going to talk about what it is and isn’t.

What it is:

Straight from the website: “AWS Backup is a fully managed backup service that makes it easy to centralize and automate the backup of data across AWS services in the cloud and on premises.”

Translation: AWS Backup is a one stop shop to run backups for the following services: Amazon Elastic File System (EFS), Amazon DynamoDB, Amazon Elastic Block Store (EBS), Amazon Relational Database Service (RDS) (except Aurora) and AWS Storage Gateway. By using resource tags (nice!) you can specify backup windows, retention periods, and data life cycle policies. AWS says that they will also backup on-prem data, but the caveat here is that it needs to be on the storage gateway.

AWS Backup Icons for Chris Blog

Effectively what AWS Backup does is manage the pre-existing backup mechanisms for the above services. If you were already running Amazon Relational Database Service (RDS) backups & wrote a script to trigger Amazon Elastic Block Store (EBS) snaps… then this will give you a one-stop-shop to manage said backups/restores.

One really nice things about AWS Backup is the Amazon Elastic File System (EFS) backup feature. Previously if you wanted to backup your Amazon Elastic File System (EFS) environment using native AWS services, you had to do an EFS-to-EFS backup solution that…. wasn’t great. It’s an AWS CloudFormation Template (CFT) that you deployed into your environment and subsequently configured. It *works*… but it’s a manual process and just another thing you need to keep an eye on. By incorporating all of the backup service offerings into one service, AWS has made it much easier to get point-in-time, crash consistent backups of the above services.

What it isn’t:

Because this isn’t a new technology under the covers, the limitations of the backup offerings of the above AWS services carry over into this new management console:

  • Backups are crash consistent, not application level consistent.
  • If you have other services other than those listed above, you’ll need to use a different backup strategy.
  • It’s not DR: While it is a good tool in an overarching BC/DR strategy, it won’t get you there on it’s own. If you want to go with a multi-region strategy you’ll need to look elsewhere.


AWS Backup is a great 1st step down the road of helping customers flesh out a better native BC/DR solution, but it is exactly that, a 1st step. There are a lot of features and functionalities that I want from a more robust backup solution. I expect that there is a lot of back and forth within AWS about how robust they can/should make this offering before they start stepping on the toes of their backup partners.

AWS Backup is an excellent option for someone who is:

  • Running only the above services
  • In a “less than highly complex” environment
  • Doesn’t need application level consistency
  • Doesn’t need multi-region DR