How to retain resource tags in AWS Backup restore jobs
UPDATE (2/3/2022): Source code extended to support AWS Backup for Amazon S3.
UPDATE (6/24/2022): Source code updated to read tags from recovery points inline with changes to AWS Backup boto3 APIs.
Update (2/23/2023): Fixed bug in source code related to support for Amazon S3 backup restores.
AWS customers use tags to track ownership of resources, drive cost allocation processes, control access to resources via IAM policies, implement compliance programs, and support operational activities. AWS has provided customers with comprehensive tagging best practices to implement an effective tagging strategy.
Customers operating in multi-account and multi-Region environments have global disaster recovery (DR) and business continuity management (BCM) needs. AWS Backup is a cost-effective, fully managed, policy-based service that simplifies data protection at scale. It enables customers to centralize and automate data protection across AWS services. Customers using AWS Backup can leverage cross-account and cross-Region backup, to securely copy backups to one or more AWS accounts within their organization in multiple Regions. Furthermore, customers can assign resources to a backup plan using tags, which is a simple and scalable method to back up multiple resources.
With data backup processes at scale, organizations want to ensure that the tags on their AWS resources are automatically replicated on their backups and also on the resources created from those backups. This helps with traceability to the original resources and avoids manual intervention for tagging newly restored resources. For example, organizations may require all their AWS resources to have an owner tag for cost allocation and security purposes. AWS Backup automatically copies tags from the resources it protects to the recovery points. However, currently the tags are not copied from recovery points to the corresponding restored resources.
In this blog post, we demonstrate how you can retain your tags on resources created by AWS Backup restore jobs using AWS Backup events to trigger a tag replication process. Using this solution, you can scale your inventory management and tagging strategy across your organization.
This solution uses an event-driven architecture consisting of Amazon EventBridge, AWS Lambda, Amazon S3, and AWS Backup. In this solution, we will initiate a restore job on an Amazon EBS snapshot and retain tags on the new EBS volume created by the job. Although we demonstrate the solution using an EBS volume, it can be applied to other AWS Backup supported resource types where the original tags are copied to the recovery point.
In order to retain the resource tags, you will deploy an AWS CloudFormation stack to your AWS account and Region where you intend to restore the resource or instance. The stack consists of a tag replicator AWS Identity and Access Management (IAM) role, S3 bucket parameters to copy and store an AWS-hosted Lambda code to a local S3 bucket, a Lambda function resource, IAM permissions to trigger a tag replicator process, and an EventBridge event rule to match the backup events.
We leverage backup events to trigger the tag replication process. The following is the EventBridge Event rule that matches the completion of the restore job event:
rAWSBackupEventBridgeRule: Type: AWS::Events::Rule Properties: Description: EventBridge rule to match AWS Backup events to trigger tag replicator Lambda function. State: "ENABLED" EventPattern: source: - 'aws.backup' detail-type: - 'Restore Job State Change' detail: status: - 'COMPLETED' Targets: - Arn: !GetAtt rTagReplicatorForAWSBackupLambda.Arn Id: "ProcessAWSBackupEventsUsingLambda"
If you want to read more about how to use EventBridge to monitor AWS Backup, see the documentation on monitoring AWS Backup events using EventBridge or refer to the blog on using Amazon CloudWatch Events and metrics for AWS Backup.
The following architecture diagram illustrates the solution discussed in this blog:
Figure 1: How to retain resource tags in AWS Backup restore jobs (architecture)
The following steps describe the workflow of the solution discussed in this blog.
- A backup administrator initiates and completes a restore job in AWS Backup.
- An Amazon EventBridge Event rule matches the job completion event and invokes a Lambda function in the AWS account.
- The Lambda function extracts the tags from the backup recovery point and adds them to the restored resource.
The following prerequisites are required to deploy the solution:
- A tagged Amazon EBS volume.
- Implement AWS Backup and create backup plans to create a snapshot of the EBS volume.
- AWS IAM permissions to initiate AWS Backup restore job and create EBS volume.
To simplify the walkthrough of this solution, we deploy the stack using an AWS CloudFormation quick-create link.
Note: You can implement and scale the solution outlined in this blog post using AWS Control Tower, AWS Organizations, and customizations for AWS Control Tower. To implement such a deployment, you can create a Lambda deployment artifact bucket for each Region where you deploy the Lambda code, and place the Lambda code in your S3 bucket.
The source code for this blog can be downloaded here:
Complete the following steps to implement this solution:
Create an AWS CloudFormation stack in the account where the recovery point exists.
- Choose Launch Stack. This button automatically launches the AWS CloudFormation service in your AWS account with a template. You are prompted to sign in if needed. You can view the CloudFormation template from within the console.
- Choose the AWS Region where you want to create the stack from the top-right corner of the AWS Management Console.
- The CloudFormation stack requires a few parameters, as shown in the following screenshot (Figure 2).
- Stack name: Enter a stack name. In this example, we use aws-backup-tag-replicator-stack.
- The URL of the Stack Binary File: The URL hosting the Lambda zip code. In this example, we use the AWS-hosted URL.
- Review the details of your parameters and check the box I acknowledge that AWS CloudFormation might create IAM resources. Then select Create stack to start building the resources.
Figure 2: AWS CloudFormation Quick create stack to deploy resources
Wait for the status of the CloudFormation stack to change from CREATE_IN_PROGRESS to CREATE_COMPLETE.
Figure 3: Stack updates from CREATE_IN_PROGRESS to CREATE_COMPLETE
Monitor tag replication
In this section, we demonstrate the solution discussed in this blog by monitoring tag replication to an EBS volume created by an AWS Backup restore job.
- Create an EBS volume with the following tag keys and values:
- Name = aws-backup-test
- Type = SSD-Demo
- Project = aws-backup (see the documentation on creating EBS volumes)
Figure 4: Create an EBS volume
- Create on-demand backup and specify EBS as the Resource type, and indicate the EBS volume ID.
Figure 5: Launch on-demand backup job
- Navigate to the Backups jobs page in the AWS Backup console and wait for the on-demand Status to change from Running to
Figure 6: On-demand backup job completed
- Initiate a restore job (see the documentation on restoring a backup) and confirm that the tags from the EBS recovery point are replicated to the newly created volume.
Figure 7: EBS volume and tags successfully restored
You have now successfully restored an Amazon EBS resource from a backup and retained the tags.
In this blog post, we discussed how to retain tags in AWS Backup jobs using a custom tag replication process that copies tags from recovery points to restored resources. We also outlined a sample scenario to replicate tags to a restored EBS volume. This solution supports other resources types that have the tags set in the recovery point. The solution presented scales your inventory management and tagging strategy across your organization.
To get started on AWS or to learn more about building a well-architected AWS environment, visit the AWS Backup Getting Started page for guidance. Thank you for reading this blog.
If you have any feedback or questions, please leave them in the comments section.
Additional resources to consider:
- Blog: Amazon CloudWatch Events and metric for AWS Backup
- Blog: Secure data recovery with cross-account backup and Cross-Region copy using AWS Backup
- Blog: Configuring notifications to monitor AWS Backup jobs
- Blog: Automate centralized backup at scale across AWS services using AWS Backup
- Blog: Create and share encrypted backups across accounts and Regions using AWS Backup