# Security in AWS Backup
Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations.
Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud:
+ **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS compliance programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to AWS Backup, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Security in the cloud** – Your responsibility for AWS Backup includes, but is not limited to, the following. You are also responsible for other factors including the sensitivity of your data, your organization's requirements, and applicable laws and regulations.
+ Responding to communications you receive from AWS.
+ Managing the credentials you and your team use. For more information, see [Identity and access management in AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-iam.html).
+ Configuring your backup plans and resource assignments to reflect your organization’s data protection policies. For more information, see [Managing backup plans](https://docs.aws.amazon.com/aws-backup/latest/devguide/getting-started.html).
+ Regularly testing your ability to find certain recovery points and restore them. For more information, see [Working with backups](https://docs.aws.amazon.com/aws-backup/latest/devguide/recovery-points.html).
+ Incorporating AWS Backup procedures in your organization’s disaster recovery and business continuity written procedures. For a start point, see [Getting started with AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/getting-started.html).
+ Ensuring that your employees are familiar with and have practiced using AWS Backup along with your organizational procedures in the event of an emergency. For more information, see the [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html).
This documentation helps you understand how to apply the shared responsibility model when using AWS Backup. The following topics show you how to configure AWS Backup to meet your security and compliance objectives. You also learn how to use other AWS services that help you monitor and secure your AWS Backup resources.
**Topics**
+ [Compliance validation](backup-compliance.md)
+ [Data protection](data-protection.md)
+ [Identity and access management](backup-iam.md)
+ [Infrastructure security](infrastructure-security.md)
+ [Integrity](backup-integrity.md)
+ [Legal holds](legalhold.md)
+ [Malware protection](malware-protection.md)
+ [Resilience](disaster-recovery-resiliency.md)
# Compliance validation for AWS Backup
To learn whether an AWS service is within the scope of specific compliance programs, see [AWS services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) and choose the compliance program that you are interested in. For general information, see [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/).
You can download third-party audit reports using AWS Artifact. For more information, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Your compliance responsibility when using AWS services is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. For more information about your compliance responsibility when using AWS services, see [AWS Security Documentation](https://docs.aws.amazon.com/security/).
# Data protection in AWS Backup
AWS Backup conforms to the AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/), which includes regulations and guidelines for data protection. AWS is responsible for protecting the global infrastructure that runs all the AWS services. AWS maintains control over data hosted on this infrastructure, including the security configuration controls for handling customer content and personal data. AWS customers and AWS Partner Network (APN) partners, acting either as data controllers or data processors, are responsible for any personal data that they put in the AWS Cloud.
For data protection purposes, we recommend that you protect AWS account credentials and set up individual user accounts with AWS Identity and Access Management (IAM). This helps ensure that each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
+ Use multi-factor authentication (MFA) with each account.
+ Use Secure Sockets Layer (SSL)/Transport Layer Security (TLS) to communicate with AWS resources.
+ Use AWS encryption solutions, along with all default security controls within AWS services.
We strongly recommend that you never put sensitive identifying information, such as your customers' account numbers, into free-form fields such as a **Name** field. This includes when you work with AWS Backup or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into AWS Backup or other services might get picked up for inclusion in diagnostic logs. When you provide a URL to an external server, don't include credentials information in the URL to validate your request to that server.
For more information about data protection, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*.
# Encryption for backups in AWS Backup
## Independent encryption
AWS Backup offers independent encryption for [resource types that support full AWS Backup management](backup-feature-availability.md#features-by-resource). Independent encryption means that recovery points (backups) you create through AWS Backup can have an encryption method other than one determined by the source resource's encryption. For example, your backup of an Amazon S3 bucket can have a different encryption method than the source bucket you encrypted with Amazon S3 encryption. This encryption is controlled through the AWS KMS key configuration in the backup vault where your backup in stored.
Backups of resource types that are not fully managed by AWS Backup typically inherit the encryption settings from their source resource. You can configure these encryption settings according to that service's instructions, such as [Amazon EBS encryption](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) in the *Amazon EBS User Guide*.
Your IAM role must have access to the KMS key being used to back up and restore the object. Otherwise the job is successful but the objects are not backed up or restored. The permissions in IAM policy and KMS key policy must be consistent. For more information, see [Specifying KMS keys in IAM policy statements](https://docs.aws.amazon.com/kms/latest/developerguide/cmks-in-iam-policies.html) in the *AWS Key Management Service Developer Guide*.
The following table lists each supported resource type, how encryption is configured for backups, and whether independent encryption for backups is supported. When AWS Backup independently encrypts a backup, it uses the industry-standard AES-256 encryption algorithm. For more information about encryption in AWS Backup, see [cross-Region](cross-region-backup.md) and [cross-account](create-cross-account-backup.md) backup.
| Resource type | How to configure encryption | Independent AWS Backup encryption |
| --- | --- | --- |
| Amazon Simple Storage Service (Amazon S3) | Amazon S3 backups are encrypted using a AWS KMS (AWS Key Management Service) key associated with the backup vault. The AWS KMS key can either be a customer-managed key or an AWS-managed key associated with the AWS Backup service. AWS Backup encrypts all backups even if the source Amazon S3 buckets are not encrypted. | Supported |
| VMware virtual machines | VM backups are always encrypted. The AWS KMS encryption key for virtual machine backups is configured in the AWS Backup vault in which the virtual machine backups are stored. | Supported |
| Amazon DynamoDB after enabling [Advanced DynamoDB backup](advanced-ddb-backup.md) | DynamoDB backups are always encrypted. The AWS KMS encryption key for DynamoDB backups is configured in the AWS Backup vault that the DynamoDB backups are stored in. | Supported |
| Amazon DynamoDB without enabling [Advanced DynamoDB backup](advanced-ddb-backup.md) | DynamoDB backups are automatically encrypted with the same encryption key that was used to encrypt the source DynamoDB table. Snapshots of unencrypted DynamoDB tables are also unencrypted. In order for AWS Backup to create a backup of an encrypted DynamoDB table, you must add the permissions `kms:Decrypt` and `kms:GenerateDataKey` to the IAM role used for backup. Alternately, you can use the AWS Backup default service role. | Not supported |
| Amazon Elastic File System (Amazon EFS) | Amazon EFS backups are always encrypted. The AWS KMS encryption key for Amazon EFS backups is configured in the AWS Backup vault that the Amazon EFS backups are stored in. | Supported |
| Amazon Elastic Block Store (Amazon EBS) | By default, Amazon EBS backups are either encrypted using the key that was used to encrypt the source volume, or they are unencrypted. During restore, you can choose to override the default encryption method by specifying a KMS key. | Not supported |
| Amazon Elastic Compute Cloud (Amazon EC2) AMIs | AMIs are unencrypted. EBS snapshots are encrypted by the default encryption rules for EBS backups (see entry for EBS). EBS snapshots of data and root volumes can be encrypted and attached to an AMI. | Not supported |
| Amazon Relational Database Service (Amazon RDS) | Amazon RDS snapshots are automatically encrypted with the same encryption key that was used to encrypt the source Amazon RDS database. Snapshots of unencrypted Amazon RDS databases are also unencrypted. | Not supported |
| Amazon Aurora | Aurora cluster snapshots are automatically encrypted with the same encryption key that was used to encrypt the source Amazon Aurora cluster. Snapshots of unencrypted Aurora clusters are also unencrypted. | Not supported |
| AWS Storage Gateway | Storage Gateway snapshots are automatically encrypted with the same encryption key that was used to encrypt the source Storage Gateway volume. Snapshots of unencrypted Storage Gateway volumes are also unencrypted. You don't need to use a customer managed key across all services to enable Storage Gateway. You only need to copy the Storage Gateway backup to a vault that configured a KMS key. This is because Storage Gateway does not have a service-specific AWS KMS managed key. | Not supported |
| Amazon FSx | Encryption features for Amazon FSx file systems differ based on the underlying file system. To learn more about your particular Amazon FSx file system, see the appropriate [FSx User Guide](https://docs.aws.amazon.com/fsx/). | Not supported |
| Amazon DocumentDB | Amazon DocumentDB cluster snapshots are automatically encrypted with the same encryption key that was used to encrypt the source Amazon DocumentDB cluster. Snapshots of unencrypted Amazon DocumentDB clusters are also unencrypted. | Not supported |
| Amazon Neptune | Neptune cluster snapshots are automatically encrypted with the same encryption key that was used to encrypt the source Neptune cluster. Snapshots of unencrypted Neptune clusters are also unencrypted. | Not supported |
| Amazon Timestream | Timestream table snapshot backups are always encrypted. The AWS KMS encryption key for Timestream backups is configured in the backup vault in which the Timestream backups are stored. | Supported |
| Amazon Redshift | Amazon Redshift clusters are automatically encrypted with the same encryption key that was used to encrypt the source Amazon Redshift cluster. Snapshots of unencrypted Amazon Redshift clusters are also unencrypted. | Not supported |
| Amazon Redshift Serverless | Redshift Serverless snapshots are automatically encrypted with the same encryption key that was used to encrypt the source. | Not supported |
| CloudFormation | CloudFormation backups are always encrypted. The CloudFormation encryption key for CloudFormation backups is configured in the CloudFormation vault in which the CloudFormation backups are stored. | Supported |
| SAP HANA databases on Amazon EC2 instances | SAP HANA database backups are always encrypted. The AWS KMS encryption key for SAP HANA database backups is configured in the AWS Backup vault in which the database backups are stored. | Supported |
**Tip**
[AWS Backup Audit Manager](https://docs.aws.amazon.com/aws-backup/latest/devguide/aws-backup-audit-manager.html) helps you automatically detect unencrypted backups.
## Encryption for copies of a backup to a different account or AWS Region
When you copy your backups across accounts or Regions, AWS Backup automatically encrypts those copies for most resource types, even if the original backup is unencrypted. AWS Backup encrypts the copy using the KMS key of the target vault.
Before you copy a backup from one account to another (cross-account copy job) or copy a backup from one Region to another (cross-Region copy job), note the following conditions, many of which depend on whether the resource type in the backup (recovery point) is [fully managed by AWS Backup or not fully managed](backup-feature-availability.md#features-by-resource).
+ A copy of a backup to another AWS Region is encrypted using the key of the destination vault.
+ For a copy of a recovery point (backup) of a resource that is **fully managed by AWS Backup**, you can choose to encrypt it with a [customer managed key (CMK)](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) or an AWS Backup managed key (`aws/backup`).
For a copy of a recovery point of a resource that is **not fully managed** by AWS Backup, the key associated to the destination vault must be a CMK or the managed key of the service that owns the underlying resource. For example, if you are copying an EC2 instance, a Backup managed key cannot be used. Instead, a CMK or Amazon EBS KMS key (`aws/ebs`) must be used to avoid copy job failure.
+ Cross-account copy with AWS managed keys isn't supported for resources that aren't fully managed by AWS Backup. The [key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) of an AWS managed key is immutable, which prevents copying the key across accounts. If your resources are encrypted with AWS managed keys and you want to perform a cross-account copy, you may [change the encryption keys](https://repost.aws/knowledge-center/update-encryption-key-rds) to a customer managed key, which can be used for cross-account copying. Or, you can follow the instructions in [ Protecting encrypted Amazon RDS instances with cross-account and cross-Region backups](https://aws.amazon.com/blogs/storage/protecting-encrypted-amazon-rds-instances-with-cross-account-and-cross-region-backups/) to continue using AWS managed keys.
+ Copies of unencrypted Amazon Aurora, Amazon DocumentDB, and Amazon Neptune clusters are also unencrypted.
## AWS Backup permissions, grants, and deny statements
To help avoid failed jobs, you can examine the AWS KMS key policy to ensure it has required permissions and does not have any deny statements that prevent successful operations.
Failed jobs can occur due to either one or more Deny statements applied to the KMS key or due to a [grant](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) revoked for the key.
In an AWS managed access policy such as [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupFullAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupFullAccess.html), there are Allow actions that permit AWS Backup to interface with AWS KMS to create a grant on a KMS key on a customer's behalf as part backup, copy, and storage operations.
At a minimum, the key policy requires the following permissions:
+ `kms:createGrant`
+ `kms:generateDataKey`
+ `kms:decrypt`
If Deny policies are necessary, you will need to allowlist the required roles for backup and restore operations.
These elements can look like:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "KmsPermissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": [
"kms:ListKeys",
"kms:DescribeKey",
"kms:GenerateDataKey",
"kms:ListAliases"
],
"Resource": "*"
},
{
"Sid": "KmsCreateGrantPermissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": [
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"kms:EncryptionContextKeys": "aws:backup:backup-vault"
},
"Bool": {
"kms:GrantIsForAWSResource": true
},
"StringLike": {
"kms:ViaService": "backup.*.amazonaws.com"
}
}
}
]
}
```
------
These permissions must be part of the key, whether it is AWS managed or customer managed.
1. Ensure required permissions are part of KMS key policy
1. Run KMS CLI `get-key-policy` ([https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html)) to view the key policy attached to the specified KMS key.
1. Review the returned permissions.
1. Ensure there are no Deny statements that affect operations
1. Run (or re-run) CLI `get-key-policy` ([https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html)) to view the key policy attached to the specified KMS key.
1. Review the policy.
1. Remove relevant Deny statements from the KMS key policy.
1. If needed, run [https://docs.aws.amazon.com/kms/latest/APIReference/API_PutKeyPolicy.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_PutKeyPolicy.html) to replace or update key policy with revised permissions and removed Deny statements.
Additionally, the key associated with the role initiating a cross-Region copy job must have `"kms:ResourcesAliases": "alias/aws/backup"` in the `DescribeKey` permission.
# Virtual machine hypervisor credential encryption
Virtual machines [ managed by a hypervisor](https://docs.aws.amazon.com//aws-backup/latest/devguide/working-with-hypervisors.html) use [AWS Backup Gateway](https://docs.aws.amazon.com/aws-backup/latest/devguide/working-with-gateways.html) to connect on-premises systems to AWS Backup. It is important that hypervisors have the same robust and reliable security. This security can be achieved by encrypting the hypervisor, either by AWS owned keys or by customer managed keys.
## AWS owned and customer managed keys
AWS Backup provides encryption for hypervisor credentials to protect sensitive customer login information using **AWS owned encryption** keys. You have the option of using **customer managed keys **instead.
By default, the keys used to encrypt credentials in your hypervisor are **AWS owned keys**. AWS Backup uses these keys to automatically encrypt hypervisor credentials. You can neither view, manage, or use AWS owned keys, nor can you audit their use. However, you don't have to take any action or change any programs to protect the keys that encrypt your data. For more information, see AWS owned keys in the [https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt).
Alternatively, credentials can be encrypted using *Customer managed keys*. AWS Backup supports the use of symmetric customer-managed keys that you create, own, and manage to perform your encryption. Because you have full control of this encryption, you can perform tasks such as:
+ Establishing and maintaining key policies
+ Establishing and maintaining IAM policies and grants
+ Enabling and disabling key policies
+ Rotating key cryptographic material
+ Adding tags
+ Creating key aliases
+ Scheduling keys for deletion
When you use a customer managed key, AWS Backup validates whether your role has permission to decrypt using this key (prior to a backup or restore job being run). You must add the `kms:Decrypt` action to the role used to start a backup or restore job.
Because the `kms:Decrypt` action cannot be added to the default backup role, you must use a role other than the default backup role to use customer managed keys.
For more information, see [customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) in the *AWS Key Management Service Developer Guide*.
## Grant required when using customer managed keys
AWS KMS requires a [ grant](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) to use your customer managed key. When you import a [ hypervisor configuration](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_ImportHypervisorConfiguration.html) encrypted with a customer managed key, AWS Backup creates a grant on your behalf by sending a [https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) request to AWS KMS. AWS Backup uses grants to access a KMS key in a customer account.
You can revoke access to the grant, or remove AWS Backup's access to the customer managed key at any time. If you do, all your gateways associated with your hypervisor can no longer access the hypervisor's username and password encrypted by the customer managed key, which will affect your backup and restore jobs. Specifically, backup and restore jobs you perform on the virtual machines in this hypervisor will fail.
Backup gateway uses the `RetireGrant` operation to remove a grant when you delete a hypervisor.
## Monitoring encryption keys
When you use an AWS KMS customer managed key with your AWS Backup resources, you can use [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) or [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) to track requests that AWS Backup sends to AWS KMS.
Look for AWS CloudTrail events with the following `"eventName"` fields to for monitor AWS KMS operations called by AWS Backup to access data encrypted by your customer managed key:
+ `"eventName": "CreateGrant"`
+ `"eventName": "Decrypt"`
+ `"eventName": "Encrypt"`
+ `"eventName": "DescribeKey"`
# Identity and access management in AWS Backup
Access to AWS Backup requires credentials. Those credentials must have permissions to access AWS resources, such as an Amazon DynamoDB database or an Amazon EFS file system. Moreover, recovery points created by AWS Backup for some AWS Backup-supported services cannot be deleted using the source service (such as Amazon EFS). You can delete those recovery points using AWS Backup.
The following sections provide details on how you can use [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) and AWS Backup to help secure access to your resources.
**Warning**
AWS Backup uses the same IAM role that you chose when assigning resources to manage your recovery point lifecycle. If you delete or modify that role, AWS Backup cannot manage your recovery point lifecycle. When this occurs, it will attempt to use a service-linked role to manage your lifecycle. In a small percentage of cases, this might also not work, leaving `EXPIRED` recovery points on your storage, which might create unwanted costs. To delete `EXPIRED` recovery points, manually delete them using the procedure in [Deleting backups](https://docs.aws.amazon.com/aws-backup/latest/devguide/deleting-backups.html).
**Topics**
+ [
# Authentication
](authentication.md)
+ [
# Access control
](access-control.md)
+ [
# IAM service roles
](iam-service-roles.md)
+ [
# Managed policies for AWS Backup
](security-iam-awsmanpol.md)
+ [
# Using service-linked roles for AWS Backup
](using-service-linked-roles.md)
+ [
# Cross-service confused deputy prevention
](cross-service-confused-deputy-prevention.md)
# Authentication
Access to AWS Backup or the AWS services that you are backing up requires credentials that AWS can use to authenticate your requests. You can access AWS as any of the following types of identities:
+ **AWS account root user** – When you sign up for AWS, you provide an email address and password that is associated with your AWS account. This is your *AWS account root user*. Its credentials provide complete access to all of your AWS resources.
**Important**
For security reasons, we recommend that you use the root user only to create an *administrator*. The administrator is an *IAM user* with full permissions to your AWS account. You can then use this admin user to create other IAM users and roles with limited permissions. For more information, see [IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users) and [Creating Your First IAM Admin User and Group](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html) in the *IAM User Guide*.
+ **IAM user** – An [IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) is an identity within your AWS account that has specific custom permissions (for example, permissions to create a backup vault to store your backups in). You can use an IAM user name and password to sign in to secure AWS webpages like the [AWS Management Console](https://console.aws.amazon.com/), [AWS Discussion Forums](https://forums.aws.amazon.com/), or the [AWS Support Center](https://console.aws.amazon.com/support/home#/).
In addition to a user name and password, you can also generate [access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) for each user. You can use these keys when you access AWS services programmatically, either through [one of the several SDKs](https://aws.amazon.com/developer/tools/) or by using the [AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/cli/). The SDK and AWS CLI tools use the access keys to cryptographically sign your request. If you don't use the AWS tools, you must sign the request yourself. For more information about authenticating requests, see [Signature Version 4 Signing Process](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) in the *AWS General Reference*.
+ **IAM role** – An [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) is another IAM identity that you can create in your account that has specific permissions. It is similar to an IAM user, but it is not associated with a specific person. An IAM role enables you to obtain temporary access keys that can be used to access AWS services and resources. IAM roles with temporary credentials are useful in the following situations:
+ Federated user access – Instead of creating an IAM user, you can use pre-existing user identities from Directory Service, your enterprise user directory, or a web identity provider. These are known as *federated users*. AWS assigns a role to a federated user when access is requested through an [identity provider](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html). For more information about federated users, see [Federated Users and Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html#intro-access-roles) in the *IAM User Guide*.
+ Cross-account administration – You can use an IAM role in your account to grant another AWS account permissions to administer your account's resources. For an example, see [Tutorial: Delegate Access Across AWS accounts Using IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) in the *IAM User Guide*.
+ AWS service access – You can use an IAM role in your account to grant an AWS service permissions to access your account's resources. For more information, see [Creating a Role to Delegate Permissions to an AWS Service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.
+ Applications running on Amazon Elastic Compute Cloud (Amazon EC2) – You can use an IAM role to manage temporary credentials for applications running on an Amazon EC2 instance and making AWS API requests. This is preferable to storing access keys within the EC2 instance. To assign an AWS role to an EC2 instance and make it available to all of its applications, you create an instance profile that is attached to the instance. An instance profile contains the role and enables programs running on the EC2 instance to get temporary credentials. For more information, see [Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) in the *IAM User Guide*.
# Access control
You can have valid credentials to authenticate your requests, but unless you have the appropriate permissions, you can't access AWS Backup resources such as backup vaults. You also can't back up AWS resources such as Amazon Elastic Block Store (Amazon EBS) volumes.
Every AWS resource is owned by an AWS account, and permissions to create or access a resource are governed by permissions policies. An account administrator can attach permissions policies to AWS Identity and Access Management (IAM) identities (that is, users, groups, and roles). And some services also support attaching permissions policies to resources.
An *account administrator* (or administrator user) is a user with administrator permissions. For more information, see [IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*.
When granting permissions, you decide who is getting the permissions, the resources they get permissions for, and the specific actions that you want to allow on those resources.
The following sections cover how access policies work and how you use them to protect your backups.
**Topics**
+ [
## Resources and operations
](#access-control-resources)
+ [
## Resource ownership
](#access-control-owner)
+ [
## Specifying policy elements: actions, effects, and principals
](#access-control-specify-backup-actions)
+ [
## Specifying conditions in a policy
](#specifying-conditions)
+ [
## API permissions: actions, resources, and conditions reference
](#backup-api-permissions-ref)
+ [
## Copy tags permissions
](#copy-tags)
+ [
## Access policies
](#access-policies)
## Resources and operations
A resource is an object that exists within a service. AWS Backup resources include backup plans, backup vaults, and backups. *Backup* is a general term that refers to the various types of backup resources that exist in AWS. For example, Amazon EBS snapshots, Amazon Relational Database Service (Amazon RDS) snapshots, and Amazon DynamoDB backups are all types of backup resources.
In AWS Backup, backups are also referred to as *recovery points*. When using AWS Backup, you also work with the resources from other AWS services that you are trying to protect, such as Amazon EBS volumes or DynamoDB tables. These resources have unique Amazon Resource Names (ARNs) associated with them. ARNs uniquely identify AWS resources. You must have an ARN when you need to specify a resource unambiguously across all of AWS, such as in IAM policies or API calls.
The following table lists resources, subresources, ARN format, and an example unique ID.
**AWS Backup resource ARNs**
| Resource type | ARN format | Example unique ID |
| --- | --- | --- |
| Backup plan | arn:aws:backup:region:account-id:backup-plan:\$1 | |
| Backup vault | arn:aws:backup:region:account-id:backup-vault:\$1 | |
| Recovery point for Amazon EBS | arn:aws:ec2:region::snapshot/\$1 | snapshot/snap-05f426fd8kdjb4224 |
| Recovery point for Amazon EC2 images | arn:aws:ec2:region::image/ami-\$1 | image/ami-1a2b3e4f5e6f7g890 |
| Recovery point for Amazon RDS | arn:aws:rds:region:account-id:snapshot:awsbackup:\$1 | awsbackup:job-be59cf2a-2343-4402-bd8b-226993d23453 |
| Recovery point for Aurora | arn:aws:rds:region:account-id:cluster-snapshot:awsbackup:\$1 | awsbackup:job-be59cf2a-2343-4402-bd8b-226993d23453 |
| Recovery point for Aurora DSQL | arn:aws-partition:backup:region:account-id:recovery-point:recovery-point-id | arn:aws:backup:us-east-1:012345678901:recovery-point:8a92c3f1-b475-4d9e-95e6-7c138f2d4b0a |
| Recovery point for Storage Gateway | arn:aws:ec2:region::snapshot/\$1 | snapshot/snap-0d40e49137e31d9e0 |
| Recovery point for DynamoDB without [Advanced DynamoDB backup](advanced-ddb-backup.md) | arn:aws:dynamodb:region:account-id:table/\$1/backup/\$1 | table/MyDynamoDBTable/backup/01547087347000-c8b6kdk3 |
| Recovery point for DynamoDB with [Advanced DynamoDB backup](advanced-ddb-backup.md) enabled | arn:aws:backup:region:account-id:recovery-point:\$1 | 12a34a56-7bb8-901c-cd23-4567d8e9ef01 |
| Recovery point for Amazon EFS | arn:aws:backup:region:account-id:recovery-point:\$1 | d99699e7-e183-477e-bfcd-ccb1c6e5455e |
| Recovery point for Amazon FSx | arn:aws:fsx:region:account-id:backup/backup-\$1 | backup/backup-1a20e49137e31d9e0 |
| Recovery point for virtual machine | arn:aws:backup:region:account-id:recovery-point:\$1 | 1801234a-5b6b-7dc8-8032-836f7ffc623b |
| Recovery point for Amazon S3 continuous backup | arn:aws:backup:region:account-id:recovery-point:\$1 | amzn-s3-demo-bucket-5ec207d0 |
| Recovery point for S3 periodic backup | arn:aws:backup:region:account-id:recovery-point:\$1 | amzn-s3-demo-bucket-20211231900000-5ec207d0 |
| Recovery point for Amazon DocumentDB | arn:aws:rds:region:account-id:cluster-snapshot:awsbackup:\$1 | awsbackup:job-ab12cd3e-4567-8901-fg1h-234567i89012 |
| Recovery point for Neptune | arn:aws:rds:region:account-id:cluster-snapshot:awsbackup:\$1 | awsbackup:job-ab12cd3e-4567-8901-fg1h-234567i89012 |
| Recovery point for Amazon Redshift | arn:aws:redshift:region:account-id:snapshot:resource/awsbackup:\$1 | awsbackup:job-ab12cd3e-4567-8901-fg1h-234567i89012 |
| Recovery point for Amazon Redshift Serverless | arn:aws:redshift-serverless:region:account-id:snapshot:resource/awsbackup:\$1 | awsbackup:job-ab12cd3e-4567-8901-fg1h-234567i89012 |
| Recovery point for Amazon Timestream | arn:aws:backup:region:account-id:recovery-point:\$1 | recovery-point:1a2b3cde-f405-6789-012g-3456hi789012\$1beta |
| Recovery point for AWS CloudFormation template | arn:aws:backup:region:account-id:recovery-point:\$1 | recovery-point:1a2b3cde-f405-6789-012g-3456hi789012 |
| Recovery point for SAP HANA database on Amazon EC2 instance | arn:aws:backup:region:account-id:recovery-point:\$1 | recovery-point:1a2b3cde-f405-6789-012g-3456hi789012 |
Resources that support full AWS Backup management all have recovery points in the format `arn:aws:backup:region:account-id::recovery-point:*`. making it easier for you to apply permissions policies to protect those recovery points. To see which resources support full AWS Backup management, see that section of the [Feature availability by resource](backup-feature-availability.md#features-by-resource) table.
AWS Backup provides a set of operations to work with AWS Backup resources. For a list of available operations, see AWS Backup [Actions](API_Operations.md).
## Resource ownership
The AWS account owns the resources that are created in the account, regardless of who created the resources. Specifically, the resource owner is the AWS account of the [principal entity](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts) (that is, the AWS account root user, an IAM user, or an IAM role) that authenticates the resource creation request. The following examples illustrate how this works:
+ If you use the AWS account root user credentials of your AWS account to create a backup vault, your AWS account is the owner of the vault.
+ If you create an IAM user in your AWS account and grant permissions to create a backup vault to that user, the user can create a backup vault. However, your AWS account, to which the user belongs, owns the backup vault resource.
+ If you create an IAM role in your AWS account with permissions to create a backup vault, anyone who can assume the role can create a vault. Your AWS account, to which the role belongs, owns the backup vault resource.
## Specifying policy elements: actions, effects, and principals
For each AWS Backup resource (see [Resources and operations](#access-control-resources)), the service defines a set of API operations (see [Actions](API_Operations.md)). To grant permissions for these API operations, AWS Backup defines a set of actions that you can specify in a policy. Performing an API operation can require permissions for more than one action.
The following are the most basic policy elements:
+ Resource – In a policy, you use an Amazon Resource Name (ARN) to identify the resource to which the policy applies. For more information, see [Resources and operations](#access-control-resources).
+ Action – You use action keywords to identify resource operations that you want to allow or deny.
+ Effect – You specify the effect when the user requests the specific action—this can be either allow or deny. If you don't explicitly grant access to (allow) a resource, access is implicitly denied. You can also explicitly deny access to a resource, which you might do to make sure that a user cannot access it, even if a different policy grants access.
+ Principal – In identity-based policies (IAM policies), the user that the policy is attached to is the implicit principal. For resource-based policies, you specify the user, account, service, or other entity that you want to receive permissions (applies to resource-based policies only).
To learn more about IAM policy syntax and descriptions, see [IAM JSON Policy Reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) in the *IAM User Guide*.
For a table showing all of the AWS Backup API actions, see [API permissions: actions, resources, and conditions reference](#backup-api-permissions-ref).
## Specifying conditions in a policy
When you grant permissions, you can use the IAM policy language to specify the conditions when a policy should take effect. For example, you might want a policy to be applied only after a specific date. For more information about specifying conditions in a policy language, see [Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
AWS supports global condition keys and service-specific condition keys. To see all global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
AWS Backup defines its own set of condition keys. To see a list of AWS Backup condition keys, see [Condition keys for AWS Backup](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsbackup.html#awsbackup-policy-keys) in the *Service Authorization Reference*.
## API permissions: actions, resources, and conditions reference
When you are setting up [Access control](#access-control) and writing a permissions policy that you can attach to an IAM identity (identity-based policies), you can use the following table as a reference. The table lists each AWS Backup API operation, the corresponding actions for which you can grant permissions to perform the action, and the AWS resource for which you can grant the permissions. You specify the actions in the policy's `Action` field, and you specify the resource value in the policy's `Resource` field. If `Resource` field is blank, you can use the wildcard (`*`) to include all resources.
You can use AWS-wide condition keys in your AWS Backup policies to express conditions. For a complete list of AWS-wide keys, see [Available Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys) in the *IAM User Guide*.
Use the scroll bars to see the rest of the table.
**AWS Backup API and required permissions for actions**
| AWS Backup API operations | Required permissions (API actions) | Resources |
| --- | --- | --- |
| [CreateBackupPlan](API_CreateBackupPlan.md) | backup:CreateBackupPlan | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [CreateBackupSelection](API_CreateBackupSelection.md) | backup:CreateBackupSelection | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [CreateBackupVault](API_CreateBackupVault.md) | `backup:CreateBackupVault` `backup-storage:MountCapsule` `kms:CreateGrant` `kms:GenerateDataKey` `kms:Decrypt` `kms:RetireGrant` `kms:DescribeKey` | arn:aws:backup:region:account-id:backup-vault:\$1 For `backup-storage`: \$1 For `kms`: `arn:aws:kms:region:account-id:key/keystring` |
| [DeleteBackupPlan](API_DeleteBackupPlan.md) | backup:DeleteBackupPlan | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [DeleteBackupSelection](API_DeleteBackupSelection.md) | backup:DeleteBackupSelection | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [DeleteBackupVault](API_DeleteBackupVault.md) | backup:DeleteBackupVault 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [DeleteBackupVaultAccessPolicy](API_DeleteBackupVaultAccessPolicy.md) | backup:DeleteBackupVaultAccessPolicy | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [DeleteBackupVaultNotifications](API_DeleteBackupVaultNotifications.md) | backup:DeleteBackupVaultNotifications 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [DeleteRecoveryPoint](API_DeleteRecoveryPoint.md) | backup:DeleteRecoveryPoint 1 | 2 |
| [DescribeBackupJob](API_DescribeBackupJob.md) | backup:DescribeBackupJob | |
| [DescribeBackupVault](API_DescribeBackupVault.md) | backup:DescribeBackupVault 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [DescribeProtectedResource](API_DescribeProtectedResource.md) | backup:DescribeProtectedResource | |
| [DescribeRecoveryPoint](API_DescribeRecoveryPoint.md) | backup:DescribeRecoveryPoint 1 | arn:aws:backup:region:account-id:backup-vault:\$1 2 |
| [DescribeRestoreJob](API_DescribeRestoreJob.md) | backup:DescribeRestoreJob | |
| [DescribeRegionSettings](API_DescribeRegionSettings.md) | backup:DescribeRegionSettings | |
| [ExportBackupPlanTemplate](API_ExportBackupPlanTemplate.md) | backup:ExportBackupPlanTemplate | |
| [GetBackupPlan](API_GetBackupPlan.md) | backup:GetBackupPlan | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [GetBackupPlanFromJSON](API_GetBackupPlanFromJSON.md) | backup:GetBackupPlanFromJSON | |
| [GetBackupPlanFromTemplate](API_GetBackupPlanFromTemplate.md) | backup:GetBackupPlanFromTemplate | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [GetBackupSelection](API_GetBackupSelection.md) | backup:GetBackupSelection | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [GetBackupVaultAccessPolicy](API_GetBackupVaultAccessPolicy.md) | backup:GetBackupVaultAccessPolicy 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [GetBackupVaultNotifications](API_GetBackupVaultNotifications.md) | backup:GetBackupVaultNotifications 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [GetRecoveryPointRestoreMetadata](API_GetRecoveryPointRestoreMetadata.md) | backup:GetRecoveryPointRestoreMetadata 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [GetSupportedResourceTypes](API_GetSupportedResourceTypes.md) | backup:GetSupportedResourceTypes | |
| [ListBackupJobs](API_ListBackupJobs.md) | backup:ListBackupJobs | |
| [ListBackupPlans](API_ListBackupPlans.md) | backup:ListBackupPlans | |
| [ListBackupPlanTemplates](API_ListBackupPlanTemplates.md) | backup:ListBackupPlanTemplates | |
| [ListBackupPlanVersions](API_ListBackupPlanVersions.md) | backup:ListBackupPlanVersions | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [ListBackupSelections](API_ListBackupSelections.md) | backup:ListBackupSelections | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [ListBackupVaults](API_ListBackupVaults.md) | backup:ListBackupVaults | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [ListProtectedResources](API_ListProtectedResources.md) | backup:ListProtectedResources | |
| [ListRecoveryPointsByBackupVault](API_ListRecoveryPointsByBackupVault.md) | backup:ListRecoveryPointsByBackupVault 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [ListRecoveryPointsByResource](API_ListRecoveryPointsByResource.md) | backup:ListRecoveryPointsByResource | |
| [ListRestoreJobs](API_ListRestoreJobs.md) | backup:ListRestoreJobs | |
| [ListTags](API_ListTags.md) | backup:ListTags | |
| [PutBackupVaultAccessPolicy](API_PutBackupVaultAccessPolicy.md) | backup:PutBackupVaultAccessPolicy 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [PutBackupVaultLockConfiguration](API_PutBackupVaultLockConfiguration.md) | backup:PutBackupVaultLockConfiguration 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [PutBackupVaultNotifications](API_PutBackupVaultNotifications.md) | backup:PutBackupVaultNotifications 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [StartBackupJob](API_StartBackupJob.md) | backup:StartBackupJob | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [StartRestoreJob](API_StartRestoreJob.md) | backup:StartRestoreJob | `arn:aws:backup:region:account-id:backup-vault:*` `arn:aws:backup:region:account-id:recovery-point:*` 3 |
| [StopBackupJob](API_StopBackupJob.md) | backup:StopBackupJob | |
| [TagResource](API_TagResource.md) | backup:TagResource | arn:aws:backup:region:account-id:recovery-point:\$1 |
| [UntagResource](API_UntagResource.md) | backup:UntagResource | |
| [UpdateBackupPlan](API_UpdateBackupPlan.md) | backup:UpdateBackupPlan | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [UpdateRecoveryPointLifecycle](API_UpdateRecoveryPointLifecycle.md) | backup:UpdateRecoveryPointLifecycle 1 | arn:aws:backup:region:account-id:backup-vault:\$1 2 |
| [UpdateRegionSettings](API_UpdateRegionSettings.md) | `backup:UpdateRegionSettings` `backup:DescribeRegionSettings` | |
1 Uses the existing vault access policy.
2 See [AWS Backup resource ARNs](#resource-arns-table) for resource-specific recovery point ARNs.
3 `StartRestoreJob` must have the key-value pair in the metadata for the resource. To get the metadata of the resource, call the `GetRecoveryPointRestoreMetadata` API.
For more information, see [Actions, resources, and condition keys for AWS Backup](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsbackup.html) in the *Service Authorization Reference*.
## Copy tags permissions
When AWS Backup performs a backup or copy job, it attempts to copy the tags from your source resource (or recovery point in the case of copy) to your recovery point.
**Note**
AWS Backup does **not** natively copy tags during restore jobs. For an event-driven architecture that will copy tags during restore jobs, see [How to retain resource tags in AWS Backup restore jobs](https://aws.amazon.com/blogs/storage/how-to-retain-resource-tags-in-aws-backup-restore-jobs/).
During a backup or copy job, AWS Backup aggregates the tags you specify in your backup plan (or copy plan, or on-demand backup) with the tags from your source resource. However, AWS enforces a limit of 50 tags per resource, which AWS Backup cannot exceed. When a backup or copy job aggregates tags from the plan and the source resource, it might discover more than 50 total tags, it will be unable to complete the job, and will fail the job. This is consistent with AWS-wide tagging best practices.
+ Your resource has more than 50 tags after aggregating your backup job tags with your source resource tags. AWS supports up to 50 tags per resource.
+ The IAM role you provide to AWS Backup lacks permissions to read the source tags or set the destination tags. For more information and sample IAM role policies, see [Managed Policies](https://docs.aws.amazon.com/aws-backup/latest/devguide/access-control.html#managed-policies).
You can use your backup plan (tags added to recovery points) to create tags that contradict your source resource tags. When the two conflict, the tags from your backup plan take precedence. Use this technique if you prefer not to copy a tag value from your source resource. Specify the same tag key, but different or empty value, using your backup plan.
**Permissions Required to assign tags to backups**
| Resource type | Required permission |
| --- | --- |
| Amazon EFS file system | `elasticfilesystem:DescribeTags` |
| Amazon FSx file system | `fsx:ListTagsForResource` |
| Amazon RDS database and Amazon Aurora cluster | `rds:AddTagsToResource` `rds:ListTagsForResource` |
| Storage Gateway volume | `storagegateway:ListTagsForResource` |
| Amazon EC2 instance and Amazon EBS volume | `EC2:CreateTags` `EC2:DescribeTags` |
DynamoDB does not support assigning tags to backups unless you first enable [Advanced DynamoDB backup](advanced-ddb-backup.md).
When an Amazon EC2 backup creates an Image Recovery Point and a set of snapshots, AWS Backup copies tags to the resulting AMI. AWS Backup also copies the tags from the volumes associated with the Amazon EC2 instance to the resulting snapshots.
## Access policies
A *permissions* policy describes who has access to what. Policies attached to an IAM identity are referred to as *identity-based* policies (IAM policies). Policies attached to a resource are referred to as *resource-based* policies. AWS Backup supports both identity-based policies and resource-based policies.
**Note**
This section discusses using IAM in the context of AWS Backup. It doesn't provide detailed information about the IAM service. For complete IAM documentation, see [What Is IAM?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) in the *IAM User Guide*. For information about IAM policy syntax and descriptions, see [IAM JSON Policy Reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) in the *IAM User Guide*.
### Identity-based policies (IAM policies)
Identity-based policies are policies that you can attach to IAM identities, such as users or roles. For example, you can define a policy that allows a user to view and back up AWS resources, but prevents them from restoring backups.
For more information about users, groups, roles, and permissions, see [Identities (Users, Groups, and Roles)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) in the *IAM User Guide*.
For information about how to use IAM policies to control access to backups, see [Managed policies for AWS Backup](security-iam-awsmanpol.md).
### Resource-based policies
AWS Backup supports resource-based access policies for backup vaults. This enables you to define an access policy that can control which users have what kind of access to any of the backups organized in a backup vault. Resource-based access policies for backup vaults provide an easy way to control access to your backups.
Backup vault access policies control user access when you use AWS Backup APIs. Some backup types, such as Amazon Elastic Block Store (Amazon EBS) and Amazon Relational Database Service (Amazon RDS) snapshots, can also be accessed using those services' APIs. You can create separate access policies in IAM that control access to those APIs in order to fully control access to backups.
To learn how to create an access policy for backup vaults, see [Vault access policies](create-a-vault-access-policy.md).
# IAM service roles
An AWS Identity and Access Management (IAM) role is similar to a user, in that it is an AWS identity with permissions policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. A service role is a role that an AWS service assumes to perform actions on your behalf. As a service that performs backup operations on your behalf, AWS Backup requires that you pass it a role to assume when performing backup operations on your behalf. For more information about IAM roles, see [IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) in the *IAM User Guide*.
The role that you pass to AWS Backup must have an IAM policy with the permissions that enable AWS Backup to perform actions associated with backup operations, such as creating, restoring, or expiring backups. Different permissions are required for each of the AWS services that AWS Backup supports. The role must also have AWS Backup listed as a trusted entity, which enables AWS Backup to assume the role.
When you assign resources to a backup plan, or if you perform an on-demand backup, copy, or restore, you must pass a service role that has access to perform the underlying operations on the specified resources. AWS Backup uses this role to create, tag, and delete resources in your account.
## Using AWS roles to control access to backups
You can use roles to control access to your backups by defining narrowly scoped roles and by specifying who can pass that role to AWS Backup. For example, you could create a role that only grants permissions to back up Amazon Relational Database Service (Amazon RDS) databases and only grant Amazon RDS database owners permission to pass that role to AWS Backup. AWS Backup provides several predefined managed policies for each of the supported services. You can attach these managed policies to roles that you create. This makes it easier to create service-specific roles that have the correct permissions that AWS Backup needs.
For more information about AWS managed policies for AWS Backup, see [Managed policies for AWS Backup](security-iam-awsmanpol.md).
## Default service role for AWS Backup
When using the AWS Backup console for the first time, you can choose to have AWS Backup create a default service role for you. This role has the permissions that AWS Backup needs to create and restore backups on your behalf.
**Note**
The default role is automatically created when you use the AWS Management Console. You can create the default role using the AWS Command Line Interface (AWS CLI), but it must be done manually.
If you prefer to use custom roles, such as separate roles for different resource types, you can also do that and pass your custom roles to AWS Backup. To view examples of roles that enable backup and restore for individual resource types, see the [Customer managed policies](security-iam-awsmanpol.md#customer-managed-policies) table.
The default service role is named `AWSBackupDefaultServiceRole`. This service role contains two managed policies, [AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html) and [AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html).
`AWSBackupServiceRolePolicyForBackup` includes an IAM policy that grants AWS Backup permissions to describe the resource being backed up, the ability to create, delete, describe, or add tags to a backup regardless of the AWS KMS key with which it is encrypted.
`AWSBackupServiceRolePolicyForRestores` includes an IAM policy that grants AWS Backup permissions to create, delete, or describe the new resource being created from a backup, regardless of the AWS KMS key with which it is encrypted. It also includes permissions to tag the newly created resource.
To restore an Amazon EC2 instance, you must launch a new instance.
## Creating the default service role in the console
Specific actions you take in the AWS Backup Console create the AWS Backup default service role.
**To create the AWS Backup default service role in your AWS account**
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. To create the role for your account, either assign resources to a backup plan or create an on-demand backup.
1. Create a backup plan and assign resources to the backup. See [Create a backup plan](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html).
1. Alternatively, create an on-demand backup. See [Create an on-demand backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-on-demand-backup.html).
1. Verify that you have created the `AWSBackupDefaultServiceRole` in your account by following these steps:
1. Wait a few minutes. For more information, see [Changes that I make are not always immediately visible](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency) in the *AWS Identity and Access Management User Guide.*
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the left navigation menu, choose **Roles**.
1. In the search bar, type `AWSBackupDefaultServiceRole`. If this selection exists, you have created the AWS Backup default role and completed this procedure.
1. If `AWSBackupDefaultServiceRole` still does not appear, add the following permissions to either the IAM user or IAM role you use to access the console.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"iam:CreateRole",
"iam:AttachRolePolicy",
"iam:PassRole"
],
"Resource":"arn:aws:iam::*:role/service-role/AWSBackupDefaultServiceRole"
},
{
"Effect":"Allow",
"Action":[
"iam:ListRoles"
],
"Resource":"*"
}
]
}
```
------
For China Regions, replace *aws* with *aws-cn*. For AWS GovCloud (US) Regions, replace *aws* with *aws-us-gov*.
1. If you cannot add permissions to your IAM user or IAM role, ask your administrator to manually create a role with a name *other than* `AWSBackupDefaultServiceRole` and attach that role to these managed policies:
+ `AWSBackupServiceRolePolicyForBackup`
+ `AWSBackupServiceRolePolicyForRestores`
# Managed policies for AWS Backup
Managed policies are standalone identity-based policies that you can attach to multiple users, groups, and roles in your AWS account. When you attach a policy to a principal entity, you give the entity the permissions that are defined in the policy.
*AWS managed policies* are created and administered by AWS. You can't change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to.
*Customer managed policies* give you fine-grained controls to set access to backups in AWS Backup. For example, you can use them to give your database backup administrator access to Amazon RDS backups but not Amazon EFS ones.
For more information, see [Managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html) in the *IAM User Guide*.
## AWS managed policies
AWS Backup provides the following AWS managed policies for common use cases. These policies make it easier to define the right permissions and control access to your backups. There are two types of managed policies. One type is designed to be assigned to users to control their access to AWS Backup. The other type of managed policy is designed to be attached to roles that you pass to AWS Backup. The following table lists all the managed policies that AWS Backup provides and describes how they are defined. You can find these managed policies in the **Policies** section of the IAM console.
**Topics**
+ [
### AWSBackupAuditAccess
](#AWSBackupAuditAccess)
+ [
### AWSBackupDataTransferAccess
](#AWSBackupDataTransferAccess)
+ [
### AWSBackupFullAccess
](#AWSBackupFullAccess)
+ [
### AWSBackupGatewayServiceRolePolicyForVirtualMachineMetadataSync
](#AWSBackupGatewayServiceRolePolicyForVirtualMachineMetadataSync)
+ [
### AWSBackupGuardDutyRolePolicyForScans
](#AWSBackupGuardDutyRolePolicyForScans)
+ [
### AWSBackupOperatorAccess
](#AWSBackupOperatorAccess)
+ [
### AWSBackupOrganizationAdminAccess
](#AWSBackupOrganizationAdminAccess)
+ [
### AWSBackupRestoreAccessForSAPHANA
](#AWSBackupRestoreAccessForSAPHANA)
+ [
### AWSBackupSearchOperatorAccess
](#AWSBackupSearchOperatorAccess)
+ [
### AWSBackupServiceLinkedRolePolicyForBackup
](#AWSBackupServiceLinkedRolePolicyForBackup)
+ [
### AWSBackupServiceLinkedRolePolicyForBackupTest
](#AWSBackupServiceLinkedRolePolicyForBackupTest)
+ [
### AWSBackupServiceRolePolicyForBackup
](#AWSBackupServiceRolePolicyForBackup)
+ [
### AWSBackupServiceRolePolicyForItemRestores
](#AWSBackupServiceRolePolicyForItemRestores)
+ [
### AWSBackupServiceRolePolicyForIndexing
](#AWSBackupServiceRolePolicyForIndexing)
+ [
### AWSBackupServiceRolePolicyForRestores
](#AWSBackupServiceRolePolicyForRestores)
+ [
### AWSBackupServiceRolePolicyForS3Backup
](#AWSBackupServiceRolePolicyForS3Backup)
+ [
### AWSBackupServiceRolePolicyForS3Restore
](#AWSBackupServiceRolePolicyForS3Restore)
+ [
### AWSBackupServiceRolePolicyForScans
](#AWSBackupServiceRolePolicyForScans)
+ [
### AWSServiceRolePolicyForBackupReports
](#AWSServiceRolePolicyForBackupReports)
+ [
### AWSServiceRolePolicyForBackupRestoreTesting
](#AWSServiceRolePolicyForBackupRestoreTesting)
### AWSBackupAuditAccess
This policy grants permissions for users to create controls and frameworks that define their expectations for AWS Backup resources and activities, and to audit AWS Backup resources and activities against their defined controls and frameworks. This policy grants permissions to AWS Config and similar services to describe user expectations perform the audits.
This policy also grants permissions to deliver audit reports to Amazon S3 and similar services, and enables users to find and open their audit reports.
To view the permissions for this policy, see [AWSBackupAuditAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupAuditAccess.html) in the *AWS Managed Policy Reference*.
### AWSBackupDataTransferAccess
This policy provides permissions for the AWS Backup storage plane data transfer APIs, allowing the AWS Backint agent to complete backup data transfer with the AWS Backup storage plane. You can attach this policy to roles assumed by Amazon EC2 instances running SAP HANA with the Backint agent.
To view the permissions for this policy, see [AWSBackupDataTransferAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupDataTransferAccess.html) in the *AWS Managed Policy Reference*.
### AWSBackupFullAccess
The backup administrator has full access to AWS Backup operations, including creating or editing backup plans, assigning AWS resources to backup plans, and restoring backups. Backup administrators are responsible for determining and enforcing backup compliance by defining backup plans that meet their organization's business and regulatory requirements. Backup administrators also ensure that their organization's AWS resources are assigned to the appropriate plan.
To view the permissions for this policy, see [AWSBackupFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupFullAccess.html) in the *AWS Managed Policy Reference*.
### AWSBackupGatewayServiceRolePolicyForVirtualMachineMetadataSync
This policy provides Backup gateway permission to sync the metadata of Virtual Machines on your behalf
To view the permissions for this policy, see [AWSBackupGatewayServiceRolePolicyForVirtualMachineMetadataSync](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupGatewayServiceRolePolicyForVirtualMachineMetadataSync.html) in the *AWS Managed Policy Reference*.
### AWSBackupGuardDutyRolePolicyForScans
This policy must be added to a new scanning role that grants Amazon GuardDuty permission to read and scan your backups. You'll need to attach this scanning role to your backup plan within the malware protection or scan settings. When AWS Backup initiates a scan, it passes this scanning role to Amazon GuardDuty.
To view the permissions for this policy, see [AWSBackupGuardDutyRolePolicyForScans](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupGuardDutyRolePolicyForScans.html) in the *AWS Managed Policy Reference*.
### AWSBackupOperatorAccess
Backup operators are users that are responsible for ensuring the resources that they are responsible for are properly backed up. Backup operators have permissions to assign AWS resources to the backup plans that the backup administrator creates. They also have permissions to create on-demand backups of their AWS resources and to configure the retention period of on-demand backups. Backup operators do not have permissions to create or edit backup plans or to delete scheduled backups after they are created. Backup operators can restore backups. You can limit the resource types that a backup operator can assign to a backup plan or restore from a backup. You do this by allowing only certain service roles to be passed to AWS Backup that have permissions for a certain resource type.
To view the permissions for this policy, see [AWSBackupOperatorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupOperatorAccess.html) in the *AWS Managed Policy Reference*.
### AWSBackupOrganizationAdminAccess
The organization administrator has full access to AWS Organizations operations, including creating, editing, or deleting backup policies, assigning backup policies to accounts and organizational units, and monitoring backup activities within the organization. Organization administrators are responsible for protecting accounts in their organization by defining and assigning backup policies that meet their organization's business and regulatory requirements.
To view the permissions for this policy, see [AWSBackupOrganizationAdminAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupOrganizationAdminAccess.html) in the *AWS Managed Policy Reference*.
### AWSBackupRestoreAccessForSAPHANA
This policy provides AWS Backup permission to restore a backup of SAP HANA on Amazon EC2.
To view the permissions for this policy, see [AWSBackupRestoreAccessForSAPHANA](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupRestoreAccessForSAPHANA.html) in the *AWS Managed Policy Reference*.
### AWSBackupSearchOperatorAccess
The search operator role has access to create backup indexes and to create searches of indexed backup metadata.
This policy contains the necessary permissions for those functions.
To view the permissions for this policy, see [AWSBackupSearchOperatorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupSearchOperatorAccess.html) in the *AWS Managed Policy Reference*.
### AWSBackupServiceLinkedRolePolicyForBackup
This policy is attached to the service-linked role named AWSServiceRoleforBackup to allow AWS Backup to call AWS services on your behalf to manage your backups. For more information, see [Using roles to back up and copy](using-service-linked-roles-AWSServiceRoleForBackup.md).
To view the permissions for this policy, see [ AWSBackupServiceLinkedRolePolicyforBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceLinkedRolePolicyForBackup.html) in the *AWS Managed Policy Reference*.
### AWSBackupServiceLinkedRolePolicyForBackupTest
To view the permissions for this policy, see [AWSBackupServiceLinkedRolePolicyForBackupTest](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceLinkedRolePolicyForBackupTest.html) in the *AWS Managed Policy Reference*.
### AWSBackupServiceRolePolicyForBackup
Provides AWS Backup permissions to create backups of all supported resource types on your behalf.
To view the permissions for this policy, see [AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html) in the *AWS Managed Policy Reference*.
### AWSBackupServiceRolePolicyForItemRestores
**Description**
This policy grants users permissions to restore individual files and items in a snapshot (periodic backup recovery point) to a new or existing Amazon S3 bucket or new Amazon EBS volume. These permissions include: read permissions to Amazon EBS for snapshots managed by AWS Backup read/write permissions to Amazon S3 buckets, and generate and describe permissions for AWS KMS keys.
**Using this policy**
You can attach `AWSBackupServiceRolePolicyForItemRestores` to your users, groups, and roles.
**Policy details**
+ **Type:** AWS managed policy
+ **Creation time:** 21 November 2024, 22:45 UTC
+ **Edited time:** First instance
+ **ARN:** `arn:aws:iam::aws:policy/AWSBackupServiceRolePolicyForItemRestores`
**Policy version:** v1 (default)
This policy’s version defines the permissions for the policy. When the user or role with the policy makes a request to access an AWS resource, AWS checks the default version of the policy to determine whether to allow the request or not.
**JSON policy document:**
#### AWSBackupServiceRolePolicyForItemRestores JSON
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EBSReadOnlyPermissions",
"Effect": "Allow",
"Action": [
"ec2:DescribeSnapshots"
],
"Resource": "arn:aws:ec2:*::snapshot/*"
},
{
"Sid": "KMSReadOnlyPermissions",
"Effect": "Allow",
"Action": "kms:DescribeKey",
"Resource": "*"
},
{
"Sid": "EBSDirectReadAPIPermissions",
"Effect": "Allow",
"Action": [
"ebs:ListSnapshotBlocks",
"ebs:GetSnapshotBlock"
],
"Resource": "arn:aws:ec2:*::snapshot/*"
},
{
"Sid": "S3ReadonlyPermissions",
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::*"
},
{
"Sid": "S3PermissionsForFileLevelRestore",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts"
],
"Resource": "arn:aws:s3:::*/*"
},
{
"Sid": "KMSDataKeyForS3AndEC2Permissions",
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:*:*:key/*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"ec2.*.amazonaws.com",
"s3.*.amazonaws.com"
]
}
}
}
]
}
```
------
### AWSBackupServiceRolePolicyForIndexing
**Description**
This policy grants users permissions to index snapshot, also known as periodic, recovery points. These permissions include: read permissions to Amazon EBS for snapshots managed by AWS Backup read/write permissions to Amazon S3 buckets, and generate and describe permissions for AWS KMS keys.
**Using this policy**
You can attach `AWSBackupServiceRolePolicyForIndexing` to your users, groups, and roles.
**Policy details**
+ **Type:** AWS managed policy
+ **Edited time:** First instance
+ **ARN:** `arn:aws:iam::aws:policy/AWSBackupServiceRolePolicyForIndexing`
**Policy version:** v1 (default)
This policy’s version defines the permissions for the policy. When the user or or role with the policy makes a request to access an AWS resource, AWS checks the default version of the policy to determine whether to allow the request or not.
**JSON policy document:**
#### AWSBackupServiceRolePolicyForIndexing JSON
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EBSReadOnlyPermissions",
"Effect": "Allow",
"Action": [
"ec2:DescribeSnapshots"
],
"Resource": "arn:aws:ec2:*::snapshot/*"
},
{
"Sid": "KMSReadOnlyPermissions",
"Effect": "Allow",
"Action": "kms:DescribeKey",
"Resource": "*"
},
{
"Sid": "EBSDirectReadAPIPermissions",
"Effect": "Allow",
"Action": [
"ebs:ListSnapshotBlocks",
"ebs:GetSnapshotBlock"
],
"Resource": "arn:aws:ec2:*::snapshot/*"
},
{
"Sid": "KMSDataKeyForEC2Permissions",
"Effect": "Allow",
"Action": "kms:Decrypt",
"Resource": "arn:aws:kms:*:*:key/*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"ec2.*.amazonaws.com"
]
}
}
}
]
}
```
------
### AWSBackupServiceRolePolicyForRestores
Provides AWS Backup permissions to restore backups of all supported resource types on your behalf.
To view the permissions for this policy, see [AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) in the *AWS Managed Policy Reference*.
For EC2 instance restores, you must also include the following permissions to launch the EC2 instance:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPassRole",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::123456789012:role/role-name",
"Effect": "Allow"
}
]
}
```
------
### AWSBackupServiceRolePolicyForS3Backup
This policy contains the permissions necessary for AWS Backup to back up any S3 bucket. This includes access to all objects in a bucket and any associated AWS KMS key.
To view the permissions for this policy, see [AWSBackupServiceRolePolicyForS3Backup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForS3Backup.html) in the *AWS Managed Policy Reference*.
### AWSBackupServiceRolePolicyForS3Restore
This policy contains permissions necessary for AWS Backup to restore an S3 backup to a bucket. This includes read and write permissions to the buckets and the usage of any AWS KMS key in regards to S3 operations.
To view the permissions for this policy, see [AWSBackupServiceRolePolicyForS3Restore](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForS3Restore.html) in the *AWS Managed Policy Reference*.
### AWSBackupServiceRolePolicyForScans
The policy should be attached to the IAM role that you use in your backup plan's resource selection. This role grants AWS Backup permission to initiate scans in Amazon GuardDuty.
To view the permissions for this policy, see [AWSBackupServiceRolePolicyForScans](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForScans.html) in the *AWS Managed Policy Reference*.
### AWSServiceRolePolicyForBackupReports
AWS Backup uses this policy for the [AWSServiceRoleForBackupReports](https://docs.aws.amazon.com/aws-backup/latest/devguide/using-service-linked-roles-AWSServiceRoleForBackupReports.html) service-linked role. This service-linked role gives AWS Backup permissions to monitor and report on the compliance of your backup settings, jobs, and resources with your frameworks.
To view the permissions for this policy, see [AWSServiceRolePolicyForBackupReports](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRolePolicyForBackupReports.html) in the *AWS Managed Policy Reference*.
### AWSServiceRolePolicyForBackupRestoreTesting
To view the permissions for this policy, see [AWSServiceRolePolicyForBackupRestoreTesting](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRolePolicyForBackupRestoreTesting.html) in the *AWS Managed Policy Reference*.
## Customer managed policies
The following sections describe the recommended backup and restore permissions for the AWS services and third-party application supported by AWS Backup. You can use the existing AWS managed policies as a model as you create your own policy documents, and then customize them to further restrict access to your AWS resources.
**Important**
When using custom IAM roles for AWS Backup, you must include resource-specific permissions in addition to AWS Backup permissions. For example, when calling `backup:ListTags` on an Amazon RDS resource, your custom IAM role must also include `rds:ListTagsForResource` permission. While these permissions are included in the default AWS Backup service role, they must be explicitly added to customer-managed policies. The underlying resource permissions required depend on the specific AWS service and operation being performed.
### Amazon Aurora
**Backup**
Start with the following statements from [AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html):
+ `DynamoDBBackupPermissions`
+ `RDSClusterModifyPermissions`
+ `GetResourcesPermissions`
+ `BackupVaultPermissions`
+ `KMSPermissions`
**Restore**
Start with the `RDSPermissions` statement from [AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html).
### Amazon Aurora DSQL
**Backup**
Start with the following statements from [AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html):
+ `DSQLBackupPermissions`
+ `GetResourcesPermissions`
+ `BackupVaultPermissions`
+ `KMSPermissions`
**Restore**
Start with the `DSQLRestorePermissions` statement from [AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html).
### Amazon DynamoDB
**Backup**
Start with the following statements from [AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html):
+ `DynamoDBPermissions`
+ `DynamoDBBackupResourcePermissions`
+ `DynamodbBackupPermissions`
+ `KMSDynamoDBPermissions`
**Restore**
Start with the following statements from [AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html):
+ `DynamoDBPermissions`
+ `DynamoDBBackupResourcePermissions`
+ `DynamoDBRestorePermissions`
+ `KMSPermissions`
### Amazon EBS
**Backup**
Start with the following statements from [AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html):
+ `EBSResourcePermissions`
+ `EBSTagAndDeletePermissions`
+ `EBSCopyPermissions`
+ `EBSSnapshotTierPermissions`
+ `GetResourcesPermissions`
+ `BackupVaultPermissions`
**Restore**
Start with the `EBSPermissions` statement from [AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html).
Add the following statement.
```
{
"Effect":"Allow",
"Action": [
"ec2:DescribeSnapshots",
"ec2:DescribeVolumes"
],
"Resource":"*"
},
```
### Amazon EC2
**Backup**
Start with the following statements from [AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html):
+ `EBSCopyPermissions`
+ `EC2CopyPermissions`
+ `EC2Permissions`
+ `EC2TagPermissions`
+ `EC2ModifyPermissions`
+ `EBSResourcePermissions`
+ `GetResourcesPermissions`
+ `BackupVaultPermissions`
**Restore**
Start with the following statements from [AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html):
+ `EBSPermissions`
+ `EC2DescribePermissions`
+ `EC2RunInstancesPermissions`
+ `EC2TerminateInstancesPermissions`
+ `EC2CreateTagsPermissions`
Add the following statement.
```
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::account-id:role/role-name"
},
```
Replace *role-name* with the name of the EC2 instance profile role that will be attached to the restored EC2 instance. This is not the AWS Backup service role, but rather the IAM role that provides permissions to applications running on the EC2 instance.
### Amazon EFS
**Backup**
Start with the following statements from [AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html):
+ `EFSPermissions`
+ `GetResourcesPermissions`
+ `BackupVaultPermissions`
**Restore**
Start with the `EFSPermissions` statement from [AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html).
### Amazon FSx
**Backup**
Start with the following statements from [AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html):
+ `FsxBackupPermissions`
+ `FsxCreateBackupPermissions`
+ `FsxPermissions`
+ `FsxVolumePermissions`
+ `FsxListTagsPermissions`
+ `FsxDeletePermissions`
+ `FsxResourcePermissions`
+ `KMSPermissions`
**Restore**
Start with the following statements from [AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html):
+ `FsxPermissions`
+ `FsxTagPermissions`
+ `FsxBackupPermissions`
+ `FsxDeletePermissions`
+ `FsxDescribePermissions`
+ `FsxVolumeTagPermissions`
+ `FsxBackupTagPermissions`
+ `FsxVolumePermissions`
+ `DSPermissions`
+ `KMSDescribePermissions`
### Amazon Neptune
**Backup**
Start with the following statements from [AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html):
+ `DynamoDBBackupPermissions`
+ `RDSClusterModifyPermissions`
+ `GetResourcesPermissions`
+ `BackupVaultPermissions`
+ `KMSPermissions`
**Restore**
Start with the `RDSPermissions` statement from [AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html).
### Amazon RDS
**Backup**
Start with the following statements from [AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html):
+ `DynamoDBBackupPermissions`
+ `RDSBackupPermissions`
+ `RDSClusterModifyPermissions`
+ `GetResourcesPermissions`
+ `BackupVaultPermissions`
+ `KMSPermissions`
**Restore**
Start with the `RDSPermissions` statement from [AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html).
### Amazon S3
**Backup**
Start with [AWSBackupServiceRolePolicyForS3Backup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForS3Backup.html).
Add the `BackupVaultPermissions` and `BackupVaultCopyPermissions` statements if you need to copy backups to a different account.
**Restore**
Start with [AWSBackupServiceRolePolicyForS3Restore](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForS3Restore.html).
### AWS Storage Gateway
**Backup**
Start with the following statements from [AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html):
+ `StorageGatewayPermissions`
+ `EBSTagAndDeletePermissions`
+ `GetResourcesPermissions`
+ `BackupVaultPermissions`
Add the following statement.
```
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSnapshots"
],
"Resource":"*"
},
```
**Restore**
Start with the following statements from [AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html):
+ `StorageGatewayVolumePermissions`
+ `StorageGatewayGatewayPermissions`
+ `StorageGatewayListPermissions`
### Virtual machine
**Backup**
Start with the `BackupGatewayBackupPermissions` statement from [AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html).
**Restore**
Start with the `GatewayRestorePermissions` statement from [AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html).
### Encrypted backup
**To restore an encrypted backup, do one of the following**
+ Add your role to the allowlist for the AWS KMS key policy
+ Add the following statements from [AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) to your IAM role for restores:
+ `KMSDescribePermissions`
+ `KMSPermissions`
+ `KMSCreateGrantPermissions`
## Policy updates for AWS Backup
View details about updates to AWS managed policies for AWS Backup since this service began tracking these changes.
| Change | Description | Date |
| --- | --- | --- |
| [AWSServiceRolePolicyForBackupRestoreTesting](#AWSServiceRolePolicyForBackupRestoreTesting) – Update to an existing policy | AWS Backup added the following permission to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions allow AWS Backup Restore Testing to delete RDS Tenant Databases after restore test completion. | March 18, 2026 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions allow AWS Backup to initiate malware scans on your recovery points. | February 23, 2026 |
| [AWSBackupGuardDutyRolePolicyForScans](#AWSBackupGuardDutyRolePolicyForScans) – New policy | AWS Backup added a new AWS managed policy that provides Amazon GuardDuty permission to read and scan customer backups. AWS Backup passes a role with this policy to GuardDuty when initiating the operations `StartMalwareScan`. This is necessary to provide all necessary permissions needed for malware scans on recovery points of Amazon EC2,Amazon EBS, and Amazon S3 resources. For more information, see the managed policy [AWSBackupGuardDutyRolePolicyForScans](#AWSBackupGuardDutyRolePolicyForScans). | November 19, 2025 |
| [AWSBackupServiceRolePolicyForScans](#AWSBackupServiceRolePolicyForScans) – New policy | AWS Backup added a new AWS managed policy that provides AWS Backup permission to initiate malware scans on your recovery points. This is necessary to provide all necessary permissions needed for malware scans on recovery points of Amazon EC2,Amazon EBS, and Amazon S3 resources. For more information, see the managed policy [AWSBackupServiceRolePolicyForScans](#AWSBackupServiceRolePolicyForScans). | November 19, 2025 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | Added `malware-protection.guardduty.amazonaws.com` to `IamPassRolePermissions`, which is necessary to initiate malware scan jobs. | November 19, 2025 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions are necessary to initiate malware scan jobs. | November 19, 2025 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions allow AWS Backup to backup and restore Amazon EKS clusters. | November 10, 2025 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions allow AWS Backup to backup and restore Amazon EKS clusters. | November 10, 2025 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions allow AWS Backup to create backups of Amazon EKS clusters and their associated resources on behalf of customers. | November 10, 2025 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions allow AWS Backup to create backups of Amazon EKS clusters and their associated resources on behalf of customers. | November 10, 2025 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions allow AWS Backup to perform restore operations for Amazon EKS clusters and their associated resources on behalf of customers. | November 10, 2025 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | AWS Backup added the following permission to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) This permission allows AWS Backup to synchronize delegated administrator information with Organizations for cross-account management features. | September 9, 2025 |
| [AWSBackupGuardDutyRolePolicyForScans](#AWSBackupGuardDutyRolePolicyForScans) – New policy | AWS Backup added a new AWS managed policy that provides Amazon GuardDuty permission to read and scan customer backups. AWS Backup passes a role with this policy to GuardDuty when initiating the operations `StartMalwareScan`. This is necessary to provide all necessary permissions needed for malware scans on recovery points of Amazon EC2,Amazon EBS, and Amazon S3 resources. For more information, see the managed policy [AWSBackupGuardDutyRolePolicyForScans](#AWSBackupGuardDutyRolePolicyForScans). | November 24, 2025 |
| [AWSBackupServiceRolePolicyForScans](#AWSBackupServiceRolePolicyForScans) – New policy | AWS Backup added a new AWS managed policy that provides AWS Backup permission to initiate malware scans on your recovery points. This is necessary to provide all necessary permissions needed for malware scans on recovery points of Amazon EC2,Amazon EBS, and Amazon S3 resources. For more information, see the managed policy [AWSBackupServiceRolePolicyForScans](#AWSBackupServiceRolePolicyForScans). | November 24, 2025 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions are necessary for AWS Backup to perform orchestrated multi-Region restore operations for DSQL resources on behalf of customers. | July 17, 2025 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions are necessary for AWS Backup integration with AWS Account Management and AWS Organizations so customers have the option of Multi-party approval (MPA) as part of their logically air-gapped vaults. | June 17, 2025 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy: | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions are necessary to allow customers to restore Amazon FSx for OpenZFS Multi-availability zone (Multi-AZ) snapshots through AWS Backup. | May 27, 2025 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions allow AWS Backup to backup and restore Amazon Aurora DSQL resources. | May 21, 2025 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions allow AWS Backup to backup and restore Amazon Aurora DSQL resources. | May 21, 2025 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions allow AWS Backup to create, delete, retrieve, and manage Amazon Aurora DSQL snapshots on behalf of customers. | May 21, 2025 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions allow AWS Backup to create, delete, retrieve, encrypt, decrypt, and manage Amazon Aurora DSQL snapshots on behalf of customers. | May 21, 2025 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions allow AWS Backup to manage Aurora DSQL backups at customer-specified intervals. | May 21, 2025 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions are necessary for designated customers to have full access to Amazon Redshift Serverless backups, including required read permissions as well as the ability to delete Amazon Redshift Serverless recovery points (snapshot backups). | March 31, 2025 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions are necessary for designated customers to have all necessary backup permissions to Amazon Redshift Serverless, including required read permissions. | March 31, 2025 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions are necessary for AWS Backup to manage Amazon Redshift Serverless snapshots at customer specified intervals. | March 31, 2025 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions are necessary to allow AWS Backup to create, delete, retrieve, and manage Amazon Redshift Serverless snapshots on behalf of customers. | March 31, 2025 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | AWS Backup added the following permissions to this policy: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html) These permissions are necessary to allow AWS Backup to restore Amazon Redshift and Amazon Redshift Serverless snapshots on behalf of the customer. | March 31, 2025 |
| [AWSBackupSearchOperatorAccess](#AWSBackupSearchOperatorAccess) – Added a new AWS managed policy | AWS Backup added the AWSBackupSearchOperatorAccess AWS managed policy. | February 27, 2025 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – Update to an existing policy | AWS Backup added the permission `rds:AddTagsToResource` to support Amazon RDS multi-tenant snapshot cross-account copy of backups. This permission is necessary to complete operations when a customer chooses to create a cross-account copy of a multi-tenant RDS snapshot. | January 8, 2025 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | AWS Backup added the permissions `rds:CreateTenantDatabase` and `rds:DeleteTenantDatabase` to this policy to support the restore process of Amazon RDS resources. These permissions are necessary to complete customer operations for restoring multi-tenant snapshots. | January 8, 2025 |
| [AWSBackupServiceRolePolicyForItemRestores](#AWSBackupServiceRolePolicyForItemRestores) – Added a new AWS managed policy | AWS Backup added the AWSBackupServiceRolePolicyForItemRestores AWS managed policy. | November 26, 2024 |
| [AWSBackupServiceRolePolicyForIndexing](#AWSBackupServiceRolePolicyForIndexing) – Added a new AWS managed policy | AWS Backup added the AWSBackupServiceRolePolicyForIndexing AWS managed policy. | November 26, 2024 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | AWS Backup added permission `backup:TagResource` to this policy. The permission is necessary to obtain tagging permissions during the creation of a recovery point. | May 17, 2024 |
| [AWSBackupServiceRolePolicyForS3Backup](#AWSBackupServiceRolePolicyForS3Backup) – Update to an existing policy | AWS Backup added permission `backup:TagResource` to this policy. The permission is necessary to obtain tagging permissions during the creation of a recovery point. | May 17, 2024 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – Update to an existing policy | AWS Backup added permission `backup:TagResource` to this policy. The permission is necessary to obtain tagging permissions during the creation of a recovery point. | May 17, 2024 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | Added the permission `rds:DeleteDBInstanceAutomatedBackups`. This permission is necessary for AWS Backup to support continuous backup and point-in-time-restore of Amazon RDS instances. | May 1, 2024 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | AWS Backup updated the Amazon Resource Name (ARN) in permission `storagegateway:ListVolumes` from `arn:aws:storagegateway:*:*:gateway/*` to `*` in order to accommodate a change in the Storage Gateway API model. | May 1, 2024 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – Update to an existing policy | AWS Backup updated the Amazon Resource Name (ARN) in permission `storagegateway:ListVolumes` from `arn:aws:storagegateway:*:*:gateway/*` to `*` in order to accommodate a change in the Storage Gateway API model. | May 1, 2024 |
| [AWSServiceRolePolicyForBackupRestoreTesting](#AWSServiceRolePolicyForBackupRestoreTesting) – Update to an existing policy | Added the following permissions to describe and list recovery points and protected resources in order to conduct restore testing plans: `backup:DescribeRecoveryPoint`, `backup:DescribeProtectedResource`, `backup:ListProtectedResources`, and `backup:ListRecoveryPointsByResource`. Added the permission `ec2:DescribeSnapshotTierStatus` to support Amazon EBS archive tier storage. Added the permission `rds:DescribeDBClusterAutomatedBackups` to support Amazon Aurora continuous backups. Added the following permissions to support restore testing of Amazon Redshift backups: `redshift:DescribeClusters` and `redshift:DeleteCluster`. Added the permission `timestream:DeleteTable` to support restore testing of Amazon Timestream backups. | February 14, 2024 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | Added the permissions `ec2:DescribeSnapshotTierStatus` and `ec2:RestoreSnapshotTier`. These permissions are necessary for users to have the option to restore Amazon EBS resources stored with AWS Backup from archive storage. For EC2 instance restores, you must also include permissions as shown in the following policy statement to launch the EC2 instance: | November 27, 2023 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | Added the permissions `ec2:DescribeSnapshotTierStatus` and `ec2:ModifySnapshotTier` to support an additional storage option for backed up Amazon EBS resources to be transitioned to the archive storage tier. These permissions are necessary for users to have the option to transition Amazon EBS resources stored with AWS Backup to archive storage. | November 27, 2023 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – Update to an existing policy | Added the permissions `ec2:DescribeSnapshotTierStatus` and `ec2:ModifySnapshotTier` to support an additional storage option for backed up Amazon EBS resources to be transitioned to the archive storage tier. These permissions are necessary for users to have the option to transition Amazon EBS resources stored with AWS Backup to archive storage. Added the permissions `rds:DescribeDBClusterSnapshots` and `rds:RestoreDBClusterToPointInTime`, which is necessary for PITR (point-in-time restores) of Aurora clusters. |
| [AWSServiceRolePolicyForBackupRestoreTesting](#AWSServiceRolePolicyForBackupRestoreTesting) – New policy | Provides the permissions necessary to conduct restore testing. The permissions include the actions `list, read, and write` for the following services to be included in restore tests: Aurora, DocumentDB, DynamoDB, Amazon EBS, Amazon EC2, Amazon EFS, FSx for Lustre, FSx for Windows File Server, FSx for ONTAP, FSx for OpenZFS, Amazon Neptune, Amazon RDS, and Amazon S3. | November 27, 2023 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | Added `restore-testing.backup.amazonaws.com` to `IamPassRolePermissions` and `IamCreateServiceLinkedRolePermissions`. This addition is necessary for AWS Backup to conduct restore tests on behalf of customers. | November 27, 2023 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | Added the permissions `rds:DescribeDBClusterSnapshots` and `rds:RestoreDBClusterToPointInTime`, which is necessary for PITR (point-in-time restores) of Aurora clusters. | September 6, 2023 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | Added the permission `rds:DescribeDBClusterAutomatedBackups`, which is necessary for continuous backup and point-in-time restore of Aurora clusters. | September 6, 2023 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – Update to an existing policy | Added the permission `rds:DescribeDBClusterAutomatedBackups`, which is necessary for continuous backup and point-in-time restore of Aurora clusters. | September 6, 2023 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | Added the permission `rds:DescribeDBClusterAutomatedBackups`. This permission is necessary for AWS Backup support of continuous backup and point-in-time restore of Aurora clusters. Added the permission `rds:DeleteDBClusterAutomatedBackups` to allow AWS Backup lifecycle to delete and disassociate Amazon Aurora continuous recovery points when a retention period finishes. This permission is necessary for the Aurora recovery point to avoid a transition into an `EXIPIRED` state. Added the permission `rds:ModifyDBCluster` which allows AWS Backup to interact with Aurora clusters. This addition allows users the ability to enable or disable continuous backups based on desired configurations. | September 6, 2023 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | Added the action `ram:GetResourceShareAssociations` to grant the user permission to get resource share associations for new vault type. | August 8, 2023 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – Update to an existing policy | Added the action `ram:GetResourceShareAssociations` to grant the user permission to get resource share associations for new vault type. | August 8, 2023 |
| [AWSBackupServiceRolePolicyForS3Backup](#AWSBackupServiceRolePolicyForS3Backup) – Update to an existing policy | Added the permission `s3:PutInventoryConfiguration` to enhance backup performance speeds by using a bucket inventory. | August 1, 2023 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | Added the following actions to grant the user permissions to add tags to restore resources: `storagegateway:AddTagsToResource`, `elasticfilesystem:TagResource`, `ec2:CreateTags` for only `ec2:CreateAction` that includes either `RunInstances` or `CreateVolume`, `fsx:TagResource`, and `cloudformation:TagResource`. | May 22, 2023 |
| [AWSBackupAuditAccess](#AWSBackupAuditAccess) – Update to an existing policy | Replaced the resource selection within the API `config:DescribeComplianceByConfigRule` with a wildcard resource to make it easier for a user to select resources. | April 11, 2023 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | Added the following permission to restore Amazon EFS using a customer managed key: `kms:GenerateDataKeyWithoutPlaintext`. This helps to ensure users have required permissions to restore Amazon EFS resources. | March 27, 2023 |
| [AWSServiceRolePolicyForBackupReports](#AWSServiceRolePolicyForBackupReports) – Update to an existing policy | Updated the `config:DescribeConfigRules` and `config:DescribeConfigRuleEvaluationStatus` actions to allow AWS Backup Audit Manager to access AWS Backup Audit Manager-managed AWS Config rules. | March 9, 2023 |
| [AWSBackupServiceRolePolicyForS3Restore](#AWSBackupServiceRolePolicyForS3Restore) – Update to an existing policy | Added the following permissions: `kms:Decrypt`, `s3:PutBucketOwnershipControls`, and `s3:GetBucketOwnershipControls` to the policy `AWSBackupServiceRolePolicyForS3Restore`. These permissions are necessary to support restores of objects when KMS encryption is used in the original backup and for restoring objects when object ownership is configured on the original bucket instead of ACL. | February 13, 2023 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | Added the following permissions to schedule backups using VMware tags of virtual machines and to support schedule-based bandwidth throttling: `backup-gateway:GetHypervisorPropertyMappings`, `backup-gateway:GetVirtualMachine`, `backup-gateway:PutHypervisorPropertyMappings`, `backup-gateway:GetHypervisor`, `backup-gateway:StartVirtualMachinesMetadataSync`, `backup-gateway:GetBandwidthRateLimitSchedule`, and `backup-gateway:PutBandwidthRateLimitSchedule`. | December 15, 2022 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – Update to an existing policy | Added the following permissions to schedule backups using VMware tags of virtual machines and to support schedule-based bandwidth throttling: `backup-gateway:GetHypervisorPropertyMappings`, `backup-gateway:GetVirtualMachine`, `backup-gateway:GetHypervisor`, and `backup-gateway:GetBandwidthRateLimitSchedule`. | December 15, 2022 |
| [AWSBackupGatewayServiceRolePolicyForVirtualMachineMetadataSync](#AWSBackupGatewayServiceRolePolicyForVirtualMachineMetadataSync) – New policy | Provides permissions for AWS Backup Gateway to sync the metadata of virtual machines in on-premise networks with Backup Gateway. | December 15, 2022 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | Added the following permissions to support Timestream backup jobs: `timestream:StartAwsBackupJob`, `timestream:GetAwsBackupStatus`, `timestream:ListTables`, `timestream:ListDatabases`, `timestream:ListTagsForResource`, `timestream:DescribeTable`, `timestream:DescribeDatabase`, and `timestream:DescribeEndpoints`. | December 13, 2022 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | Added the following permissions to support Timestream restore jobs: `timestream:StartAwsRestoreJob`, `timestream:GetAwsRestoreStatus`, `timestream:ListTables`, `timestream:ListTagsForResource`, `timestream:ListDatabases`, `timestream:DescribeTable`, `timestream:DescribeDatabase`, `s3:GetBucketAcl`, and `timestream:DescribeEndpoints`. | December 13, 2022 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | Added the following permissions to support Timestream resources: `timestream:ListTables`, `timestream:ListDatabases`, `s3:ListAllMyBuckets` and `timestream:DescribeEndpoints`. | December 13, 2022 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – Update to an existing policy | Added the following permissions to support Timestream resources: `timestream:ListDatabases`, `timestream:ListTables`, `s3:ListAllMyBuckets`, and `timestream:DescribeEndpoints`. | December 13, 2022 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – Update to an existing policy | Added the following permissions to support Timestream resources: `timestream:ListDatabases`, `timestream:ListTables`, `timestream:ListTagsForResource`, `timestream:DescribeDatabase`, `timestream:DescribeTable`, `timestream:GetAwsBackupStatus`, `timestream:GetAwsRestoreStatus`, and `timestream:DescribeEndpoints`. | December 13, 2022 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | Added the following permissions to support Amazon Redshift resources: `redshift:DescribeClusters`, `redshift:DescribeClusterSubnetGroups`, `redshift:DescribeNodeConfigurationOptions`, `redshift:DescribeOrderableClusterOptions`, `redshift:DescribeClusterParameterGroups`, `redshift:DescribeClusterTracks`, `redshift:DescribeSnapshotSchedules`, and `ec2:DescribeAddresses`. | November 27, 2022 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – Update to an existing policy | Added the following permissions to support Amazon Redshift resources: `redshift:DescribeClusters`, `redshift:DescribeClusterSubnetGroups`, `redshift:DescribeNodeConfigurationOptions`, `redshift:DescribeOrderableClusterOptions`, `redshift:DescribeClusterParameterGroups,`, `redshift:DescribeClusterTracks`. `redshift:DescribeSnapshotSchedules`, and `ec2:DescribeAddresses`. | November 27, 2022 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | Added the following permissions to support Amazon Redshift restore jobs: `redshift:RestoreFromCluster Snapshot`, `redshift:RestoreTableFromClusterSnapshot`, `redshift:DescribeClusters`, and `redshift:DescribeTableRestoreStatus`. | November 27, 2022 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | Added the following permissions to support Amazon Redshift backup jobs: `redshift:CreateClusterSnapshot`, `redshift:DescribeClusterSnapshots`, `redshift:DescribeTags`, `redshift:DeleteClusterSnapshot`, `redshift:DescribeClusters`, and `redshift:CreateTags`. | November 27, 2022 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | Added the following permission to support CloudFormation resources: `cloudformation:ListStacks`. | November 27, 2022 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – Update to an existing policy | Added the following permission to support CloudFormation resources: `cloudformation:ListStacks`. | November 27, 2022 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – Update to an existing policy | Added the following permissions to support CloudFormation resources: `redshift:DescribeClusterSnapshots`, `redshift:DescribeTags`, `redshift:DeleteClusterSnapshot`, and `redshift:DescribeClusters`. | November 27, 2022 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | Added the following permissions to support CloudFormation application stack backup jobs: `cloudformation:GetTemplate`, `cloudformation:DescribeStacks`, and `cloudformation:ListStackResources`. | November 16, 2022 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | Added the following permissions to support CloudFormation application stack backup jobs: `cloudformation:CreateChangeSet` and `cloudformation:DescribeChangeSet` | November 16, 2022 |
| [AWSBackupOrganizationAdminAccess](#AWSBackupOrganizationAdminAccess) – Update to an existing policy | Added the following permissions to this policy to allow organization administrators to usethe Delegated Administrator feature: `organizations:ListDelegatedAdministrator`, `organizations:RegisterDelegatedAdministrator`, and `organizations:DeregisterDelegatedAdministrator` | November 27, 2022 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | Added the following permissions to support SAP HANA on Amazon EC2 instances: `ssm-sap:GetOperation`, `ssm-sap:ListDatabases`, `ssm-sap:BackupDatabase`, `ssm-sap:UpdateHanaBackupSettings`, `ssm-sap:GetDatabase`, and `ssm-sap:ListTagsForResource`. | November 20, 2022 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | Added the following permissions to support SAP HANA on Amazon EC2 instances: `ssm-sap:GetOperation`, `ssm-sap:ListDatabases`, `ssm-sap:GetDatabase`, and `ssm-sap:ListTagsForResource`. | November 20, 2022 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – Update to an existing policy | Added the following permissions to support SAP HANA on Amazon EC2 instances: `ssm-sap:GetOperation`, `ssm-sap:ListDatabases`, `ssm-sap:GetDatabase`, and `ssm-sap:ListTagsForResource`. | November 20, 2022 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – Update to an existing policy | Added the following permission to support SAP HANA on Amazon EC2 instances: `ssm-sap:GetOperation`. | November 20, 2022 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | Added the following permission to support Backup gateway restore jobs to an EC2 instance: `ec2:CreateTags`. | November 20, 2022 |
| [AWSBackupDataTransferAccess](#AWSBackupDataTransferAccess) – Update to an existing policy | Added the following permissions to support secure storage data transfer for SAP HANA On Amazon EC2 resources: `backup-storage:StartObject`, `backup-storage:PutChunk`, `backup-storage:GetChunk`, `backup-storage:ListChunks`, `backup-storage:ListObjects`, `backup-storage:GetObjectMetadata`, and `backup-storage:NotifyObjectComplete`. | November 20, 2022 |
| [AWSBackupRestoreAccessForSAPHANA](#AWSBackupRestoreAccessForSAPHANA) – Update to an existing policy | Added the following permissions for resource owners to perform restore of SAP HANA On Amazon EC2 resources: `backup:Get*`, `backup:List*`, `backup:Describe*`, `backup:StartBackupJob`, `backup:StartRestoreJob`, `ssm-sap:GetOperation`, `ssm-sap:ListDatabases`, `ssm-sap:BackupDatabase`, `ssm-sap:RestoreDatabase`, `ssm-sap:UpdateHanaBackupSettings`, `ssm-sap:GetDatabase`, and `ssm-sap:ListTagsForResource`. | November 20, 2022 |
| [AWSBackupServiceRolePolicyForS3Backup](#AWSBackupServiceRolePolicyForS3Backup) – Update to an existing policy | Added the permission `s3:GetBucketAcl` to support backup operations of AWS Backup for Amazon S3. | August 24, 2022 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | Added the following actions to grant access to create a database instance to support multi-Availability Zone (Multi-AZ) functionality: `rds:CreateDBInstance`. | July 20, 2022 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – Update to an existing policy | Added the `s3:GetBucketTagging` permission to grant the user permission to select buckets to backup with a resource wildcard. Without this permission, users who select which buckets to backup with a resource wildcard are unsuccessful. | May 6, 2022 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | Added volume resources in the scope of existing `fsx:CreateBackup` and `fsx:ListTagsForResource` actions, and added new action `fsx:DescribeVolumes` to support FSx for ONTAP volume level backups. | April 27, 2022 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | Added the following actions to grant the users permissions to restore FSx for ONTAP volumes `fsx:DescribeVolumes`, `fsx:CreateVolumeFromBackup`, `fsx:DeleteVolume`, and `fsx:UntagResource`. | April 27, 2022 |
| [AWSBackupServiceRolePolicyForS3Backup](#AWSBackupServiceRolePolicyForS3Backup) – Update to an existing policy | Added the following actions to grant the user permissions to receive notifications of changes to their Amazon S3 buckets during backup operations: `s3:GetBucketNotification` and `s3:PutBucketNotification`. | February 25, 2022 |
| [AWSBackupServiceRolePolicyForS3Backup](#AWSBackupServiceRolePolicyForS3Backup) – New policy | Added the following actions to grant the user permissions to back up their Amazon S3 buckets: `s3:GetInventoryConfiguration`, `s3:PutInventoryConfiguration`, `s3:ListBucketVersions`, `s3:ListBucket`, `s3:GetBucketTagging`, `s3:GetBucketVersioning`, `s3:GetBucketNotification`,`s3:GetBucketLocation`, and `s3:ListAllMyBuckets` Added the following actions to grant the user permissions to back up their Amazon S3 objects: `s3:GetObject`,`s3GetObjectAcl`, `s3:GetObjectVersionTagging`, `s3:GetObjectVersionAcl`, `s3:GetObjectTagging`, and `s3:GetObjectVersion`. Added the following actions to grant the user permissions to back up their encrypted Amazon S3 data: `kms:Decrypt` and `kms:DescribeKey`. Added the following actions to grant the user permissions to take incremental backups of their Amazon S3 data using Amazon EventBridge rules: `events:DescribeRule`, `events:EnableRule`, `events:PutRule`, `events:DeleteRule`, `events:PutTargets`, `events:RemoveTargets`, `events:ListTargetsByRule`, `events:DisableRule`, `cloudwatch:GetMetricData`, and `events:ListRules`. | February 17, 2022 |
| [AWSBackupServiceRolePolicyForS3Restore](#AWSBackupServiceRolePolicyForS3Restore) – New policy | Added the following actions to grant the user permissions to restore their Amazon S3 buckets: `s3:CreateBucket`, `s3:ListBucketVersions`, `s3:ListBucket`, `s3:GetBucketVersioning`, `s3:GetBucketLocation`, and `s3:PutBucketVersioning`. Added the following actions to grant the user permissions to restore their Amazon S3 buckets: `s3:GetObject`, `s3:GetObjectVersion`, `s3:DeleteObject`, `s3:PutObjectVersionAcl`, `s3:GetObjectVersionAcl`, `s3:GetObjectTagging`, `s3:PutObjectTagging`, `s3:GetObjectAcl`, `s3:PutObjectAcl`, `s3:PutObject`, and `s3:ListMultipartUploadParts`. Added the following actions to grant the user permissions to encrypt their restored Amazon S3 data: `kms:Decrypt`, `kms:DescribeKey`, and `kms:GenerateDataKey`. | February 17, 2022 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – Update to an existing policy | Added `s3:ListAllMyBuckets` to grant the user permissions to view a list of their buckets and choose which ones to assign to a backup plan. | February 14, 2022 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – Update to an existing policy | Added `backup-gateway:ListVirtualMachines` to grant the user permissions to view a list of their virtual machines and choose which ones to assign to a backup plan. Added `backup-gateway:ListTagsForResource` to grant the user permissions to list the tags for their virtual machines. | November 30, 2021 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | Added `backup-gateway:Backup` to grant the user permissions restore their virtual machine backups. AWS Backup also added `backup-gateway:ListTagsForResource` to grant the user permissions to list the tags assigned to their virtual machine backups. | November 30, 2021 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | Added `backup-gateway:Restore` to grant the user permissions restore their virtual machine backups. | November 30, 2021 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | Added the following actions to grant the users permissions to use AWS Backup Gateway to back up, restore, and manage their virtual machines: `backup-gateway:AssociateGatewayToServer`, `backup-gateway:CreateGateway`, `backup-gateway:DeleteGateway`, `backup-gateway:DeleteHypervisor`, `backup-gateway:DisassociateGatewayFromServer`, `backup-gateway:ImportHypervisorConfiguration`, `backup-gateway:ListGateways`, `backup-gateway:ListHypervisors`, `backup-gateway:ListTagsForResource`, `backup-gateway:ListVirtualMachines`, `backup-gateway:PutMaintenanceStartTime`, `backup-gateway:TagResource`, `backup-gateway:TestHypervisorConfiguration`, `backup-gateway:UntagResource`, `backup-gateway:UpdateGatewayInformation`, and `backup-gateway:UpdateHypervisor`. | November 30, 2021 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – Update to an existing policy | Added the following actions to grant the user permissions to back up their virtual machines: `backup-gateway:ListGateways`, `backup-gateway:ListHypervisors`, `backup-gateway:ListTagsForResource`, and `backup-gateway:ListVirtualMachines`. | November 30, 2021 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – Update to an existing policy | Added `dynamodb:ListTagsOfResource` to grant the user permissions to list tags of their DynamoDB tables to back up using AWS Backup's advanced DynamoDB backup features. | November 23, 2021 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | Added `dynamodb:StartAwsBackupJob` to grant the user permissions to back up their DynamoDB tables using advanced backup features. Added `dynamodb:ListTagsOfResource` to grant the user to permissions to copy tags from their source DynamoDB tables to their backups. | November 23, 2021 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | Added `dynamodb:RestoreTableFromAwsBackup` to grant the user permissions restore their DynamoDB tables backed up using AWS Backup's advanced DynamoDB advanced backup features. | November 23, 2021 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | Added `dynamodb:RestoreTableFromAwsBackup` to grant the user permissions restore their DynamoDB tables backed up using AWS Backup's advanced DynamoDB advanced backup features. | November 23, 2021 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – Update to an existing policy | Removed the actions `backup:GetRecoveryPointRestoreMetadata` and `rds:DescribeDBSnapshots` because they were redundant. AWS Backup did not need both `backup:GetRecoveryPointRestoreMetadata` and `backup:Get*` as part of `AWSBackupOperatorAccess`. Also, AWS Backup did not need both `rds:DescribeDBSnapshots` and `rds:describeDBSnapshots` as part of `AWSBackupOperatorAccess`. | November 23, 2021 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – Update to an existing policy | Added the new actions `elasticfilesystem:DescribeFileSystems`, `dynamodb:ListTables`, `storagegateway:ListVolumes`, `ec2:DescribeVolumes`, `ec2:DescribeInstances`, `rds:DescribeDBInstances`, `rds:DescribeDBClusters`, and `fsx:DescribeFileSystems` to allow customers to view and choose from a list of their AWS Backup-supported resources when selecting which resources to assign to a backup plan. | November 10, 2021 |
| [AWSBackupAuditAccess](#AWSBackupAuditAccess) – New policy | Added `AWSBackupAuditAccess` to grant the user permissions to use AWS Backup Audit Manager. Permissions include the ability to configure compliance frameworks and generate reports. | August 24, 2021 |
| [AWSServiceRolePolicyForBackupReports](#AWSServiceRolePolicyForBackupReports) – New policy | Added `AWSServiceRolePolicyForBackupReports` to grant permissions for a service-linked role to automate the monitoring of backup settings, jobs, and resources for compliance with frameworks configured by the user. | August 24, 2021 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | Added `iam:CreateServiceLinkedRole` to create a service-linked role (on a best-effort basis) to automate the deletion of expired recovery points for you. Without this service-linked role, AWS Backup cannot delete expired recovery points after customers delete the original IAM role they used to create their recovery points. | July 5, 2021 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – Update to an existing policy | Added the new action `dynamodb:DeleteBackup` to grant `DeleteRecoveryPoint` permission to automate the deletion of expired DynamoDB recovery points based on your backup plan lifecycle settings. | July 5, 2021 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – Update to an existing policy | Removed the actions `backup:GetRecoveryPointRestoreMetadata` and `rds:DescribeDBSnapshots` because they were redundant. AWS Backup did not need both `backup:GetRecoveryPointRestoreMetadata` and `backup:Get*` as part of `AWSBackupOperatorAccess` Also, AWS Backup did not need both `rds:DescribeDBSnapshots` and `rds:describeDBSnapshots` as part of `AWSBackupOperatorAccess` | May 25, 2021 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – Update to an existing policy | Removed the actions `backup:GetRecoveryPointRestoreMetadata` and `rds:DescribeDBSnapshots` because they were redundant. AWS Backup did not need both `backup:GetRecoveryPointRestoreMetadata` and `backup:Get*` as part of `AWSBackupOperatorAccess`. Also, AWS Backup did not need both `rds:DescribeDBSnapshots` and `rds:describeDBSnapshots` as part of `AWSBackupOperatorAccess`. | May 25, 2021 |
| [AWSBackupServiceRolePolicyForRestores]() – Update to an existing policy | Added the new action `fsx:TagResource` to grant `StartRestoreJob` permission to allow you to apply tags to Amazon FSx file systems during the restore process. | May 24, 2021 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – Update to an existing policy | Added the new actions `ec2:DescribeImages` and `ec2:DescribeInstances` to grant `StartRestoreJob` permission to allow you to restore Amazon EC2 instances from recovery points. | May 24, 2021 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | Added the new action `fsx:CopyBackup` to grant `StartCopyJob` permission to allow you to copy Amazon FSx recovery points across Regions and accounts. | April 12, 2021 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – Update to an existing policy | Added the new action `fsx:CopyBackup` to grant `StartCopyJob` permission to allow you to copy Amazon FSx recovery points across Regions and accounts. | April 12, 2021 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – Update to an existing policy | Updated to comply with the following requirement: For AWS Backup to create a backup of an encrypted DynamoDB table, you must add the permissions `kms:Decrypt` and `kms:GenerateDataKey` to the IAM role used for backup. | March 10, 2021 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – Update to an existing policy | Updated to comply with the following requirements: To use AWS Backup to configure continuous backups for your Amazon RDS database, verify the API permission `rds:ModifyDBInstance` exists in the IAM role defined by your Backup plan configuration. To restore Amazon RDS continuous backups, you must add the permission `rds:RestoreDBInstanceToPointInTime` to the IAM role you submitted for restore job. In the AWS Backup console, to describe the range of times available for point-in-time recovery, you must include the `rds:DescribeDBInstanceAutomatedBackups` API permission in your IAM-managed policy. | March 10, 2021 |
| AWS Backup started tracking changes | AWS Backup started tracking changes for its AWS-managed policies. | March 10, 2021 |
# Using service-linked roles for AWS Backup
AWS Backup uses AWS Identity and Access Management (IAM)[ service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts). A service-linked role is a unique type of IAM role that is linked directly to AWS Backup. Service-linked roles are predefined by AWS Backup and include all the permissions that the service requires to call other AWS services on your behalf.
**Topics**
+ [
# Using roles to back up and copy
](using-service-linked-roles-AWSServiceRoleForBackup.md)
+ [
# Using roles for AWS Backup Audit Manager
](using-service-linked-roles-AWSServiceRoleForBackupReports.md)
+ [
# Using roles for restore testing
](using-service-linked-roles-AWSServiceRoleForBackupRestoreTesting.md)
# Using roles to back up and copy
AWS Backup uses AWS Identity and Access Management (IAM)[ service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts). A service-linked role is a unique type of IAM role that is linked directly to AWS Backup. Service-linked roles are predefined by AWS Backup and include all the permissions that the service requires to call other AWS services on your behalf.
A service-linked role makes setting up AWS Backup easier because you don’t have to manually add the necessary permissions. AWS Backup defines the permissions of its service-linked roles, and unless defined otherwise, only AWS Backup can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.
You can delete a service-linked role only after first deleting its related resources. This protects your AWS Backup resources because you can't inadvertently remove permission to access the resources.
For information about other services that support service-linked roles, see [AWS Services That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes **in the **Service-Linked Role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
## Service-linked role permissions for AWS Backup
AWS Backup uses the service-linked role named **AWSServiceRoleForBackup** to create and delete backups of your AWS resources on your behalf.
The AWSServiceRoleForBackup service-linked role trusts the following services to assume the role:
+ `backup.amazonaws.com`
To view the permissions for this policy, see [ AWSBackupServiceLinkedRolePolicyforBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceLinkedRolePolicyForBackup.html) in the *AWS Managed Policy Reference*.
You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#service-linked-role-permissions) in the *IAM User Guide*.
## Creating a service-linked role for AWS Backup
You don't need to manually create a service-linked role. When you list resources to back up, set up cross-account backup, or perform backups in the AWS Management Console, the AWS CLI, or the AWS API, AWS Backup creates the service-linked role for you.
**Important**
This service-linked role can appear in your account if you completed an action in another service that uses the features supported by this role. To learn more, see [A New Role Appeared in My IAM Account](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you list resources to back up, set up cross-account backup, or perform backups, AWS Backup creates the service-linked role for you again.
## Editing a service-linked role for AWS Backup
AWS Backup does not allow you to edit the AWSServiceRoleForBackup service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Edit a service-linked role description](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-service-linked-role.html#edit-service-linked-role-iam-console) in the *IAM User Guide*.
## Deleting a service-linked role for AWS Backup
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up your service-linked role before you can manually delete it.
### Cleaning up a service-linked role
Before you can use IAM to delete a service-linked role, you must first delete any resources used by the role. First, you must delete all your recovery points. Then, you must delete all your backup vaults.
**Note**
If the AWS Backup service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes, then try the operation again.
**To delete AWS Backup resources used by the AWSServiceRoleForBackup (console)**
1. To delete all your recovery points and backup vaults (except for your default vault), follow the procedure in [ Delete a vault](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-a-vault.html#delete-a-vault).
1. To delete your default vault, use the following command in the AWS CLI:
```
aws backup delete-backup-vault --backup-vault-name Default --region us-east-1
```
**To delete AWS Backup resources used by the AWSServiceRoleForBackup (AWS CLI)**
1. To delete all your recovery points, use [delete-recovery-point](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/delete-recovery-point.html).
1. To delete all your backup vaults, use [delete-backup-vault](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/delete-backup-vault.html).
**To delete AWS Backup resources used by the AWSServiceRoleForBackup (API)**
1. To delete all your recovery points, use `[DeleteRecoveryPoint](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteRecoveryPoint.html)`.
1. To delete all your backup vaults, use `[DeleteBackupVault](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVault.html)`.
### Manually delete the service-linked role
Use the IAM console, the AWS CLI, or the AWS API to delete the AWSServiceRoleForBackup service-linked role. For more information, see [Delete a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html#id_roles_manage_delete_slr) in the *IAM User Guide*.
## Supported Regions for AWS Backup service-linked roles
AWS Backup supports using service-linked roles in all of the Regions where the service is available. For more information, see [AWS Backup supported features and Regions](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html#features-by-region).
# Using roles for AWS Backup Audit Manager
AWS Backup uses AWS Identity and Access Management (IAM)[ service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts). A service-linked role is a unique type of IAM role that is linked directly to AWS Backup. Service-linked roles are predefined by AWS Backup and include all the permissions that the service requires to call other AWS services on your behalf.
A service-linked role makes setting up AWS Backup easier because you don’t have to manually add the necessary permissions. AWS Backup defines the permissions of its service-linked roles, and unless defined otherwise, only AWS Backup can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.
You can delete a service-linked role only after first deleting its related resources. This protects your AWS Backup resources because you can't inadvertently remove permission to access the resources.
For information about other services that support service-linked roles, see [AWS Services That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes **in the **Service-Linked Role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
## Service-linked role permissions for AWS Backup
AWS Backup uses the service-linked role named **AWSServiceRoleForBackupReports** – Provides AWS Backup with permission to create controls, frameworks, and reports.
The AWSServiceRoleForBackupReports service-linked role trusts the following services to assume the role:
+ `reports.backup.amazonaws.com`
To view the permissions for this policy, see [AWSServiceRolePolicyForBackupReports](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRolePolicyForBackupReports.html) in the *AWS Managed Policy Reference*.
You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#service-linked-role-permissions) in the *IAM User Guide*.
## Creating a service-linked role for AWS Backup
You don't need to manually create a service-linked role. When you create a framework or a report plan in the AWS Management Console, the AWS CLI, or the AWS API, AWS Backup creates the service-linked role for you.
**Important**
This service-linked role can appear in your account if you completed an action in another service that uses the features supported by this role. To learn more, see [A New Role Appeared in My IAM Account](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you create a framework or a report plan, AWS Backup creates the service-linked role for you again.
## Editing a service-linked role for AWS Backup
AWS Backup does not allow you to edit the AWSServiceRoleForBackupReports service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Edite a service-linked role description](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-service-linked-role.html#edit-service-linked-role-iam-console) in the *IAM User Guide*.
## Deleting a service-linked role for AWS Backup
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up your service-linked role before you can manually delete it.
### Cleaning up a service-linked role
Before you can use IAM to delete a service-linked role, you must first delete any resources used by the role. You must delete all frameworks and report plans.
**Note**
If the AWS Backup service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes, then try the operation again.
**To delete AWS Backup resources used by the AWSServiceRoleForBackupReports (console)**
1. To delete all frameworks, see [Deleting frameworks](https://docs.aws.amazon.com/aws-backup/latest/devguide/deleting-frameworks.html).
1. To delete all report plans, see [Deleting report plans](https://docs.aws.amazon.com/aws-backup/latest/devguide/delete-report-plan.html).
**To delete AWS Backup resources used by the AWSServiceRoleForBackupReports (AWS CLI)**
1. To delete all frameworks, use [delete-framework](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/delete-framework.html).
1. To delete all report plans, use [delete-report-plan](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/delete-report-plan.html).
**To delete AWS Backup resources used by the AWSServiceRoleForBackupReports (API)**
1. To delete all frameworks, use [DeleteFramework](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteFramework.html).
1. To delete all report plans, use [DeleteReportPlan](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteReportPlan.html).
### Manually delete the service-linked role
Use the IAM console, the AWS CLI, or the AWS API to delete the AWSServiceRoleForBackupReports service-linked role. For more information, see [Delete a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html#id_roles_manage_delete_slr) in the *IAM User Guide*.
## Supported Regions for AWS Backup service-linked roles
AWS Backup supports using service-linked roles in all of the Regions where the service is available. For more information, see [AWS Backup supported features and Regions](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html#features-by-region).
# Using roles for restore testing
AWS Backup uses AWS Identity and Access Management (IAM)[ service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts). A service-linked role is a unique type of IAM role that is linked directly to AWS Backup. Service-linked roles are predefined by AWS Backup and include all the permissions that the service requires to call other AWS services on your behalf.
A service-linked role makes setting up AWS Backup easier because you don’t have to manually add the necessary permissions. AWS Backup defines the permissions of its service-linked roles, and unless defined otherwise, only AWS Backup can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.
You can delete a service-linked role only after first deleting its related resources. This protects your AWS Backup resources because you can't inadvertently remove permission to access the resources.
For information about other services that support service-linked roles, see [AWS Services That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes **in the **Service-Linked Role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
## Service-linked role permissions for AWS Backup
AWS Backup uses the service-linked role named **AWSServiceRoleForBackupRestoreTesting** – Provides backup permissions to conduct restore testing.
The **AWSServiceRoleForBackupRestoreTesting** service-linked role trusts the following services to assume the role:
+ `restore-testing.backup.amazonaws.com`
To view the permissions for this policy, see [AWSServiceRolePolicyForBackupRestoreTesting](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRolePolicyForBackupRestoreTesting.html) in the *AWS Managed Policy Reference*.
You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#service-linked-role-permissions) in the *IAM User Guide*.
## Creating a service-linked role for AWS Backup
You don't need to manually create a service-linked role. When you conduct restore testing in the AWS Management Console, the AWS CLI, or the AWS API, AWS Backup creates the service-linked role for you.
**Important**
This service-linked role can appear in your account if you completed an action in another service that uses the features supported by this role. To learn more, see [A New Role Appeared in My IAM Account](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you conduct restore testing, AWS Backup creates the service-linked role for you again.
## Editing a service-linked role for AWS Backup
AWS Backup does not allow you to edit the AWSServiceRoleForBackupRestoreTesting service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Edit a service-linked role description](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-service-linked-role.html#edit-service-linked-role-iam-console) in the *IAM User Guide*.
## Deleting a service-linked role for AWS Backup
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up your service-linked role before you can manually delete it.
### Cleaning up a service-linked role
Before you can use IAM to delete a service-linked role, you must first delete any resources used by the role. You must delete all restore testing plans.
**Note**
If the AWS Backup service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes, then try the operation again.
**To delete AWS Backup resources used by the AWSServiceRoleForBackupRestoreTesting (console)**
+ To delete all restore testing plans, see [Restore testing](https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html).
**To delete AWS Backup resources used by the AWSServiceRoleForBackupRestoreTesting (AWS CLI)**
+ To delete restore testing plans, use `delete-restore-testing-plan`.
**To delete AWS Backup resources used by the AWSServiceRoleForBackupRestoreTesting (API)**
+ To delete restore testing plans, use `DeleteRestoreTestingPlan`.
### Manually delete the service-linked role
Use the IAM console, the AWS CLI, or the AWS API to delete the **AWSServiceRoleForBackupRestoreTesting** service-linked role. For more information, see [Delete a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html#id_roles_manage_delete_slr) in the *IAM User Guide*.
## Supported Regions for AWS Backup service-linked roles
AWS Backup supports using service-linked roles in all of the Regions where the service is available. For more information, see [AWS Backup supported features and Regions](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html#features-by-region).
# Cross-service confused deputy prevention
The confused deputy problem is a security issue where an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action. In AWS, cross-service impersonation can result in the confused deputy problem. Cross-service impersonation can occur when one service (the *calling service*) calls another service (the *called service*). The calling service can be manipulated to use its permissions to act on another customer's resources in a way it should not otherwise have permission to access. To prevent this, AWS provides tools that help you protect your data for all services with service principals that have been given access to resources in your account.
We recommend using the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition context keys in resource policies to limit the permissions that AWS Backup gives another service to the resource. If you use both global condition context keys, the `aws:SourceAccount` value and the account in the `aws:SourceArn` value must use the same account ID when used in the same policy statement.
The value of `aws:SourceArn` must be a AWS Backup vault when using AWS Backup to publish Amazon SNS topics on your behalf.
The most effective way to protect against the confused deputy problem is to use the `aws:SourceArn` global condition context key with the full ARN of the resource. If you don't know the full ARN of the resource or if you are specifying multiple resources, use the `aws:SourceArn` global context condition key with wildcards (`*`) for the unknown portions of the ARN. For example, `arn:aws::servicename::123456789012:*`.
The following example policy shows how you can use the `aws:SourceArn` and `aws:SourceAccount` global condition context keys in AWS Backup to prevent the confused deputy problem. This policy grants the service principal backup-storage.amazonaws.com ability to perform KMS actions only when the service principal is acting on behalf of AWS account 123456789012 on the backup vaults:
# Infrastructure security in AWS Backup
As a managed service, AWS Backup is protected by AWS global network security. For more information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*.
You use AWS published API calls to access AWS Backup through the network. Clients must support Transport Layer Security (TLS) 1.2 or later. Clients must also support cipher suites with perfect forward secrecy (PFS) such as Ephemeral Diffie-Hellman (DHE) or Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). Most modern systems such as Java 7 and later support these modes.
Additionally, requests must be signed by using an access key ID and a secret access key that is associated with an IAM principal. Or you can use the [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) to generate temporary security credentials to sign requests.
# Integrity of Data in AWS Backup
## AWS Backup data integrity goal
AWS Backup seeks to maintain integrity during transmission, storage, and processing of your data. AWS Backup treats stored resource data as content-agnostic critical information, in that we offer the same high level of security to customers, regardless of the type of data you store. We are vigilant about our customers' security and have implemented sophisticated technical and physical measures against unauthorized access. You retain complete control over how your data is classified, the Regions in which you store your data, and how you control, archive, and protect your data against disclosure.
## AWS Backup data integrity implementation
AWS Backup works in concert with other AWS and Amazon services to maintain integrity of the data it stores and with which it interacts. The tools used may vary and can include (but are not limited to):
+ Continuous object validation against their checksum to prevent object corruption
+ Internal checksums to confirm integrity of data in transit and at rest
+ Checksums calculated on data in backups created from the primary store
+ Checksums are always verified to be correct before using the corresponding data. If we find data that doesn't match its checksum, we replace it with a correct copy. If we fail to replace the correct copy, we will fail the corresponding jobs
+ Automatic attempt to restore normal levels of object storage redundancy in the event of disk corruption or detection of device failure
+ Redundant storage of data across multiple physical locations
+ Object durability enhancement across multiple availability zones during the initial write, combined with further replication in the event of device unavailability or detected bit-rot
+ Checksums on all network traffic to detect corruption of data packets when storing or retrieving data
AWS Backup natively stores data for Amazon DynamoDB with advanced features, Amazon EFS, Amazon S3, Amazon Timestream, and virtual machines running with VMware connected through Backup gateway. AWS Backup facilitates backups of data stored with other services, including Amazon Aurora, Amazon DocumentDB, Amazon DynamoDB, Amazon EBS, Amazon EC2, Amazon FSx for Windows File Server, Amazon FSx for Lustre, Amazon FSx for OpenZFS, Amazon FSx for NetApp ONTAP, Amazon Neptune, Amazon RDS, and Amazon Redshift.
## Objective confirmation and audit of AWS Backup data integrity
The data stored directly by AWS Backup and the data stored in partnership with fellow AWS services with which AWS Backup interacts is subjected to the rigorous process of Amazon Simple Storage Service (Amazon S3) underpinning this data integrity. This integrity is confirmed by an independent, third-party auditor through an annual SOC audit report which is available through [AWS Artifact](https://aws.amazon.com/artifact/).
# Legal holds and AWS Backup
## Legal hold overview
A legal hold is an administrative tool that helps prevent backups from being deleted while under a hold. While the hold is in place, backups under a hold cannot be deleted and lifecycle policies that would alter the backup status (such as transition to a `Deleted` state) are delayed until the legal hold is removed.
Legal holds can be applied to one or more backups (also known as recovery points) created by AWS Backup if their lifecycles allow it. Legal holds do not apply to [continuous backups](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html).
When a legal hold is created, it can take into account specific filtering criteria, such as resource types and resource IDs. Additionally, you can define the creation date range of backups you wish to include in a legal hold.
Legal holds apply only to the original backup on which they are placed. When a backup is copied across Regions or accounts (if the resource supports it), it does not retain or carry its legal hold with it. A legal hold, like other resources, has a unique ARN (Amazon Resource Name) associated with it. Only recovery points created by AWS Backup can be part of a legal hold.
Note that while [AWS Backup Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html) provides additional protections and immutability to a vault, a legal hold provides additional protection against deletion of individual backups (recovery points). The legal hold does not expire and retains the data within the backup indefinitely. The hold remains active until it is released by a user with sufficient permissions.
## Multiple legal holds
A backup can have more than one legal hold. Legal holds and backups have a many:many relationship, meaning that a backup can have more than legal hold and a legal hold can include more than one backup.
A backup cannot be deleted as long as it has at least one legal hold. After all legal holds on a backup are removed, it is subject to its retention lifecycle properties. Maintain at least one legal hold to prevent backup deletion. Legal holds can be applied to a recovery point retained past its backup lifecycle retention date (due to an existing legal hold).
Each account can have a maximum of 50 legal holds active at one time.
## Create a legal hold
A legal hold can be added to an existing backup (recovery point).
Backups (recovery points) with a status of `EXPIRED` or `DELETING` will not be included in the legal hold. Recovery points (backups) with the status of `CREATING` may not be included in the legal hold, depending on the time of completion.
Legal holds can be added by users who have the required IAM permissions.
### Create a legal hold using the console
**To create a legal hold**
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. In the dashboard in the left of the console, find My Account. Choose **Legal holds**.
1. Choose **Add legal hold**.
1. Three panels are shown: **Legal hold details**, **Legal hold scope**, and **Legal hold tags**.
1. Under **Legal hold details**, enter a legal hold title and a description for the hold in the text boxes provided.
1. In the panel **Legal hold scope**, choose how you wish to select the resource to include in the hold. When you create a hold, you choose the method used to select the resources that are within the legal hold. You can choose to include one of the following:
+ Specific resource types and IDs
+ Select backup vaults
+ All resources types or all backup vaults within your account
1. Specify the date range of your legal hold. Enter the dates in the YYYY:MM:DD format (dates are inclusive).
1. Optionally, you can add tags for the hold under **Legal hold tags**. Tags can help categorize the hold for future reference and organization. You can add up to 50 tags total.
1. When you are satisfied with the configuration of your new legal hold, click the button **Add new hold**.
### Create a legal hold using the AWS CLI
You can create a legal hold using the [create-legal-hold](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/create-legal-hold.html) command.
```
aws backup create-legal-hold --title "my title" \
--description "my description" \
--recovery-point-selection "VaultNames=string,DateRange={FromDate=timestamp,ToDate=timestamp}"
```
## View legal holds
You can see legal hold details in the AWS Backup console or programmatically.
### View legal holds using the console
To view all legal holds within an account using the Backup console,
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. Using the left part of the dashboard, under **My account**, click **Legal holds**.
1. The **legal hold** table displays the title, status, description, ID, and creation date of existing holds. Click on the carat (down arrow) next to the table header to filter the table by the selected column.
### View legal holds programatically
To view all legal holds programmatically, you can use the following API calls: [ListLegalHolds](API_ListLegalHolds.md) and [GetLegalHold](API_GetLegalHold.md).
The following JSON template can be used for `GetLegalHold`.
```
GET /legal-holds/{legalHoldId} HTTP/1.1
Request
empty body
Response
{
Title: string,
Status: LegalHoldStatus,
Description: string, // 280 chars max
CancelDescription: string, // this is provided during cancel // 280 chars max
LegalHoldId: string,
LegalHoldArn: string,
CreatedTime: number,
CanceledTime: number,
ResourceSelection: {
VaultArns: [ string ]
Resources: [ string ]
},
ResourceFilters: {
DateRange: {
FromDate: number,
ToDate: number
}
}
}
```
The following JSON template can be used for `ListLegalHolds`.
```
GET /legal-holds/
&maxResults=MaxResults
&nextToken=NextToken
Request
empty body
url params:
MaxResults: number // optional,
NextToken: string // optional
status: Valid values: CREATING | ACTIVE | CANCELED | CANCELING
maxResults: 1-1000
Response
{
NextToken: token,
LegalHolds: [
Title: string,
Status: string,
Description: string, // 280 chars max
CancelDescription: string, // this is provided during cancel // 280 chars max
LegalHoldId: string,
LegalHoldArn: string,
CreatedTime: number,
CanceledTime: number,
]
}
```
The following are the possible status values.
| Status | Description |
| --- | --- |
| CREATING | Requested recovery points are in the process of being held, and delete requests of those recovery points may be successful since the hold hasn't finished being created. |
| ACTIVE | The legal hold has been created, All recovery points listed under this legal hold are held. |
| CANCELLING | Legal holds are in the process of being removed, and delete requests of recovery points under the hold may succeed. |
| CANCELED | Legal hold is fully released and no longer has any effect. Recovery points can be deleted. |
## View recovery points in legal holds
You can see recovery points in legal holds in the AWS Backup console or programmatically.
### View recovery points in legal holds using the console
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. Using the left part of the dashboard, under **My account**, click **Legal holds**.
1. Select a legal hold, then you can view **Legal hold details**, **Resources selected for this hold**, **Recovery points on hold**, and **Tags** for this hold.
### View recovery points in legal holds programmatically
To view recovery points in a legal hold programmatically, you can use the [ListRecoveryPointsByLegalHold](API_ListRecoveryPointsByLegalHold.md) API call.
The following is an example request and response for `ListRecoveryPointsByLegalHold`.
```
GET /legal-holds/{legalHoldId}/recovery-points HTTP/1.1
Request
empty body
Response
{
"RecoveryPoints": [
{
"RecoveryPointArn": "string",
"ResourceArn": "string",
"ResourceType": "string",
"BackupVaultName": "string"
}
],
"NextToken": "string"
}
```
## Release a legal hold
Legal holds remain in effect until they are removed by a user with sufficient permissions. Removing a legal hold is also known as cancelling, deleting, or releasing a legal hold. Removing a legal hold eliminates it from all backups to which it was attached. Any backups that expired during the legal hold are deleted within 24 hours after the legal hold is removed.
### Release a legal hold using the console
**To release a hold using the console**
1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).
1. Enter the description you would like associated with the release.
1. Review the details, then click **Release hold**.
1. When the Release hold dialogue box appears, confirm your intent to release the hold by typing `confirm` into the text box.
1. Check the box that acknowledges you are cancelling the hold.
On the **Legal holds** page you can see all your holds. If the release was successful, the status of that hold will be shown as `Released`.
### Release a legal hold programmatically
To remove a hold programmatically, use the API call [CancelLegalHold](API_CancelLegalHold.md).
Use the following JSON template.
```
DELETE /legal-holds/{legalHoldId}
Request
{
CancelDescription: String
DeleteAfterDays: number // optional
}
DeleteAfterDays: optional.
Defaults to 180 days. how long to keep legal hold record after canceled.
This applies to the actual legal hold record only.
Recovery points are unlocked as soon as cancelation processes and are not subject to this date.
Response
Empty body
200 if successful
other standard codes
```
# Malware protection in AWS Backup
Malware scanning of your backups is provided by Amazon GuardDuty Malware Protection. Using Amazon GuardDuty Malware Protection for AWS Backup allows you to automate scanning of recovery points through existing backup workflows, or initiate on-demand scans of previously created backups. This AWS native solution helps ensure your backups are clean from potential malware, allowing you to meet compliance requirements and respond to malicious incidents faster by ensuring the recovery of clean data.
To see a list of supported resource types and regions, visit the [feature availability page](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html).
**Topics**
+ [
## Integration with Amazon GuardDuty
](#malware-guardduty-integration)
+ [Instant access](backup-instant-access.md)
+ [
## How to use malware scanning
](#malware-how-to-use)
+ [
## Access
](#malware-access)
+ [
## Incremental vs full scans
](#malware-scan-types)
+ [
## Monitoring your malware scans
](#malware-monitoring)
+ [
## Understanding scan results
](#malware-scan-results)
+ [
## Troubleshooting scan failures
](#malware-troubleshooting)
+ [
## Metering
](#malware-metering)
+ [
## Quotas
](#malware-quotas)
+ [
## Console and CLI usage steps for malware scan types
](#malware-console-cli-usage)
## Integration with Amazon GuardDuty
AWS Backup integrates with Amazon GuardDuty Malware Protection to provide threat detection for your recovery points. When you start a malware scan, AWS Backup automatically calls Amazon GuardDuty's `StartMalwareScan` API after each backup completes, passing the recovery point details and your scanner role credentials. Amazon GuardDuty then begins reading, decrypting, and scanning all files and objects within the backup.
When Amazon GuardDuty accesses your backup data, that access is logged in AWS CloudTrail for visibility.
For more information about this integration, see the [Amazon GuardDuty Malware Protection documentation](https://docs.aws.amazon.com/guardduty/latest/ug/malware-protection-backup.html).
# Backup instant access permissions
When using Amazon GuardDuty Malware Protection for AWS Backup with S3 backups, Amazon GuardDuty accesses your S3 backups through three APIs: CreateBackupAccessPoint, DescribeBackupAccessPoint, and DeleteBackupAccessPoint.
Amazon GuardDuty uses CreateBackupAccessPoint to access your encrypted backup data. During the scan job, GuardDuty uses DescribeBackupAccessPoint to verify successful access point creation. Once the scan completes, GuardDuty calls DeleteBackupAccessPoint to remove its access to your backup.
This workflow applies to both S3 backups and EC2/EBS backups stored in a logically air-gapped vault.
## How to use malware scanning
When you use Amazon GuardDuty Malware Protection with AWS Backup, you can automatically scan your backups for malware. This integration helps you detect malicious code in your backups and identify clean recovery points for restore operations.
Amazon GuardDuty Malware Protection supports two primary workflows for scanning your backups:
+ **Automatic malware scanning through backup plans** – Enable malware scanning in backup plans to automate malware detection with AWS Backup. When enabled, AWS Backup automatically initiates an Amazon GuardDuty scan after each successful backup completion. You can configure either full or incremental scanning for specific backup plan rules, which determines how frequently your backups are scanned. For more information about scan types, see [Incremental vs full scans](#malware-scan-types) below. AWS Backup recommends enabling automatic malware scanning in backup plans for proactive threat detection after backup creation.
+ **On-demand scans** – Run on-demand scans to manually scan existing backups, choosing between full or incremental scan types. AWS Backup recommends using on-demand scans to identify your last clean backup. When scanning before a restore operation, use a full scan to examine the entire backup with the latest threat detection model.
## Access
Before you start with malware protection, your account must have required permissions for the operations.
AWS Backup malware scanning requires two IAM roles to scan your recovery points for potential malware:
+ First, the [AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html) or [AWSBackupServiceRolePolicyForScans](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForScans.html) managed policy must be attached to your existing or new backup role. This is the same role found in the resource assignment for your backup plan in the console, or through the [BackupSelection API](API_CreateBackupSelection.md). This managed policy allows AWS Backup to initiate malware scans with Amazon GuardDuty.
+ Second, a new scanner role is required with [AWSBackupGuardDutyRolePolicyForScans](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupGuardDutyRolePolicyForScans.html) managed policy that trusts `malware-protection.guardduty.amazonaws.com`. This is the same role found in the malware protection portion of your backup plan in the console or through the scan settings in your [BackupPlan API](API_CreateBackupPlan.md). This role is passed by AWS Backup to Amazon GuardDuty when a scan is initiated, providing access to backups.
## Incremental vs full scans
With malware scanning, you have the option to choose between incremental and full scans based on your security requirements and cost considerations.
**Incremental scans** analyze only the data that changed between the target and base recovery point. These scans are faster and more cost-effective for regular scanning, making them ideal for frequent periodic backups where you want to scan newly backed up data.
Even when incremental scanning is selected, AWS Backup performs a full scan in these situations:
+ **First-time scans:** The initial scan of a resource is always a full scan, allowing Amazon GuardDuty to establish a baseline of potential threats. Subsequent scans will then be incremental.
+ **Expired baseline:** If your baseline recovery point was scanned more than 365 days ago, a full scan occurs. Because Amazon GuardDuty retains finding information for only 365 days, a new baseline must be established to ensure accurate scanning results.
+ **Deleted baseline:** If your base recovery point is deleted before your next incremental scan starts, a full scan occurs automatically.
**Full scans** examine the entire recovery point regardless of previous scans. While these scans provide comprehensive coverage, they take longer to complete and incur higher costs. You can run full scans on-demand or schedule them through your backup plans. AWS Backup recommends configuring periodic full scans in your backup plans at extended intervals to ensure your entire backup data is regularly scanned with the latest malware signature model.
For optimal security versus cost management, consider your backup frequency when choosing scan types.
**Note**
Malware scanning is not currently supported for Amazon S3 continuous recovery points. To scan Amazon S3 continuous backups, configure periodic backups for your Amazon S3 resources and enable malware scanning on those periodic backups. You can use a [combination of continuous and periodic backups](https://docs.aws.amazon.com/aws-backup/latest/devguide/s3-backups.html) for your Amazon S3 buckets.
**Note**
Incremental malware scanning is not supported for Amazon EC2 recovery points in a [logically air-gapped vault](https://docs.aws.amazon.com/aws-backup/latest/devguide/logicallyairgappedvault.html) or copied Amazon EC2 recovery points.
## Monitoring your malware scans
After scanning is enabled, both AWS Backup and Amazon GuardDuty provide monitoring and notification mechanisms you can use to track your results:
+ **AWS Backup Console:** The AWS Backup console is powered by `ListScanJobs` and `DescribeScanJob` APIs. You can visit the Malware protection section to view the list of scan jobs, representing job status and scan results. AWS Backup also supports a `ListScanJobSummaries` API, though not available in the console.
+ **AWS Backup Audit Manager:** You can set up a scanning report to view all AWS Backup initiated malware scan jobs over the last 24 hours.
+ **Amazon GuardDuty Console:** If base Amazon GuardDuty is enabled, you can view details in the Malware Scan results and investigate malware on the Amazon GuardDuty findings page. You can view information such as the threat and file name, file path, objects/files scanned, bytes scanned, etc. Note that this detailed threat information is not available through AWS Backup, and you must have the appropriate Amazon GuardDuty permissions to view this information.
+ **Amazon EventBridge:** Both AWS Backup and Amazon GuardDuty emit EventBridge events, allowing backup and security administrators to be alerted synchronously. You can set up custom rules to receive notifications when scans complete or malware is detected.
+ **AWS CloudTrail:** Both AWS Backup and Amazon GuardDuty emit CloudTrail events, allowing you to monitor API access.
## Understanding scan results
Your scan jobs from AWS Backup will have a scan state and scan result.
### Scan States
The scan state indicates the job state and can have values of: `CREATED`, `COMPLETED`, `COMPLETED_WITH_ISSUES`, `RUNNING`, `FAILED`, or `CANCELED`.
There are multiple situations in which your scan job will finish with state `COMPLETED_WITH_ISSUES`:
For Amazon S3 backups, there are object size/type limitations which will prevent objects from being scanned. When at least one object is skipped within a scan, the corresponding scan job will be marked as `COMPLETED_WITH_ISSUES`. For Amazon EC2/Amazon EBS backups, there are volume size/quantity limitations which result in volumes being skipped during scanning. These situations will result in an Amazon EC2/Amazon EBS backup job to result in `COMPLETED_WITH_ISSUES`.
If your job finishes with state `COMPLETED_WITH_ISSUES` and you need further information about the reasons, you will need to get those details from the corresponding scan job through Amazon GuardDuty.
**Note**
Incremental scan jobs only scan the difference in data between two backups. Therefore, if an incremental scan job does not encounter any of the situations described above, it will finish in state `COMPLETE` and will not inherit the `COMPLETED_WITH_ISSUES` from the base recovery point.
In rare cases, Amazon GuardDuty may experience internal issues when scanning files and objects, and retry attempts may be exhausted. When this happens, the scan job appears as `FAILED` in AWS Backup and `COMPLETED_WITH_ISSUES` in Amazon GuardDuty. This status difference allows you to view available scan results in Amazon GuardDuty while indicating that not all supported files and objects were successfully scanned.
### Scan Results
The scan results indicate an aggregated result from Amazon GuardDuty and can have values of: `THREATS_FOUND`, or `NO_THREATS_FOUND`.
Scan results indicate whether potential malware was detected in your recovery points. A `NO_THREATS_FOUND` status means no potential malware was detected, while `THREATS_FOUND` indicates potential malware was discovered. For detailed threat information, access the full Amazon GuardDuty findings through the Amazon GuardDuty console or APIs. Scan results are also available through EventBridge events, allowing you to build automated workflows that respond to infected backups.
Amazon GuardDuty retains findings for 365 days, tracking files or objects across incremental scans to monitor if threats are removed or malware signatures change. For example, if malware is detected in backup 2, the scan result shows `THREATS_FOUND`. When you perform an incremental scan on backup 3 using backup 2 as a base, the scan result remains `THREATS_FOUND` unless the threat has been removed from the data.
## Troubleshooting scan failures
Common scan failures include insufficient IAM permissions, service limits, and resource access issues.
**Permission errors** occur when the backup role lacks `AWSBackupServiceRolePolicyForScans` permissions or the scanner role doesn't have `AWSBackupGuardDutyRolePolicyForScans` with proper trust relationships.
**Service limit errors** happen when you exceed the 150 concurrent scans per account or 5 concurrent scans per resource type - scan jobs will remain in `CREATED` state until capacity becomes available.
**Access denied errors** may indicate encrypted recovery points without proper AWS KMS permissions or deleted parent recovery points for incremental scans.
**Timeout failures** can occur with very large recovery points or during high Amazon GuardDuty load periods.
To troubleshoot, check the scan job status using `DescribeScanJob` API, verify IAM role configurations, ensure recovery points exist and are accessible, and consider switching to full scans if incremental scan parent references are missing.
Monitor your concurrent scan usage and implement jittering in automated workflows to avoid hitting service limits.
## Metering
Malware protection is provided and billed by Amazon GuardDuty. You will not see any AWS Backup charges related to using this feature. All usage can be viewed under Amazon GuardDuty's billing. To learn more, visit [Amazon GuardDuty pricing](https://aws.amazon.com/guardduty/pricing/).
## Quotas
Both AWS Backup and Amazon GuardDuty have quota limits for Amazon GuardDuty Malware Protection for AWS Backup.
For more information, visit [AWS Backup quotas](https://docs.aws.amazon.com/aws-backup/latest/devguide/aws-backup-limits.html) and [Amazon GuardDuty quotas](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_limits.html).
## Console and CLI usage steps for malware scan types
The following sections show the steps for configuring different malware scan types using both the console and AWS CLI.
### How to set up malware scans
**Console**
1. Navigate to AWS Backup console → Backup plans
1. Create new backup plan or select existing plan
1. Enable **Malware protection** toggle
1. Select **Scanner role** to choose a new scanner role. Make sure both backup role and scanner role have appropriate permissions as discussed in [Access](#malware-access).
1. Select **Scannable resource types**. This will filter malware scanning to the resource selection criteria you have chosen. As an example, if your scannable resource type selection is Amazon EBS, but your plan's resource selection includes Amazon EBS and Amazon S3, then only Amazon EBS malware scans will take place.
1. Set **Scan type** for each backup rule. You can choose between full, incremental, and no scan. The scan type selection means that scan will occur at the schedule frequency of the associated backup rule.
1. Save backup plan
**AWS CLI**
**CreateBackupPlan**
You can create a backup plan with malware scanning enabled using the [create-backup-plan](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/create-backup-plan.html) command.
```
aws backup create-backup-plan \
--region us-west-2 \
--cli-input-json '{
"BackupPlan": {
"BackupPlanName": "scan-initial-test-demo",
"Rules": [
{
"RuleName": "full",
"TargetBackupVaultName": "Default",
"ScheduleExpression": "cron(0 * * * ? *)",
"StartWindowMinutes": 120,
"CompletionWindowMinutes": 6000,
"Lifecycle": {
"DeleteAfterDays": 3,
"OptInToArchiveForSupportedResources": true
},
"RecoveryPointTags": {
"key1": "foo",
"key2": "foo"
},
"EnableContinuousBackup": true,
"ScanActions": [
{
"MalwareScanner": "GUARDDUTY",
"ScanMode": "FULL_SCAN"
}
]
},
{
"RuleName": "incremental",
"TargetBackupVaultName": "Default",
"ScheduleExpression": "cron(30 * * * ? *)",
"StartWindowMinutes": 100,
"CompletionWindowMinutes": 5000,
"Lifecycle": {
"DeleteAfterDays": 2,
"OptInToArchiveForSupportedResources": true
},
"RecoveryPointTags": {
"key1": "foo",
"key2": "foo"
},
"EnableContinuousBackup": true,
"ScanActions": [
{
"MalwareScanner": "GUARDDUTY",
"ScanMode": "INCREMENTAL_SCAN"
}
]
}
],
"ScanSettings": [
{
"MalwareScanner": "GUARDDUTY",
"ResourceTypes": ["EBS", "EC2", "S3"],
"ScannerRoleArn": "arn:aws:iam::300949271314:role/TestBackupScannerRole"
}
]
}
}'
```
**UpdateBackupPlan**
You can update a backup plan with malware scanning enabled using the [update-backup-plan](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/update-backup-plan.html) command.
```
aws backup update-backup-plan \
--region us-west-2 \
--cli-input-json '{
"BackupPlanId": "d1391282-68cf-4fce-93ad-e08bc5178bac",
"BackupPlan": {
"BackupPlanName": "scan-initial-test-demo",
"Rules":
[
{"RuleName": "full",
"TargetBackupVaultName": "Default",
"ScheduleExpression": "cron(0 * * * ? *)",
"StartWindowMinutes": 60,
"CompletionWindowMinutes": 3000,
"Lifecycle":
{
"DeleteAfterDays": 6,
"OptInToArchiveForSupportedResources": false},
"RecoveryPointTags":
{"key1": "foo",
"key2": "foo"},
"EnableContinuousBackup": false,
"ScanActions":
[
{"MalwareScanner": "GUARDDUTY",
"ScanMode": "FULL_SCAN"}
]
},
{
"RuleName": "incremental",
"TargetBackupVaultName": "Default",
"ScheduleExpression": "cron(30 * * * ? *)",
"StartWindowMinutes": 120,
"CompletionWindowMinutes": 6000,
"Lifecycle":
{
"DeleteAfterDays": 9,
"OptInToArchiveForSupportedResources": false},
"RecoveryPointTags":
{"key1": "foo",
"key2": "foo"},
"EnableContinuousBackup": false,
"ScanActions":
[
{
"MalwareScanner": "GUARDDUTY",
"ScanMode": "INCREMENTAL_SCAN"
}
]
}
],
"ScanSettings":
[
{
"MalwareScanner": "GUARDDUTY",
"ResourceTypes":
["ALL", "EBS"],
"ScannerRoleArn": "arn:aws:iam::300949271314:role/TestBackupScannerRole"
}
]
}
}'
```
**Key Notes**
+ Target ARN entry is required before scan options become enabled (Console)
+ Both backup IAM role and scanner IAM role required for all configurations
+ Use `aws backup list-scan-jobs` to view all scan jobs (AWS CLI)
+ Cost implications vary by scan type (incremental vs full) and frequency
**AWS CLI Key Notes**
+ Use `aws backup list-scan-jobs` to view all scan jobs (AWS CLI)
+ Scan results available via `describe-recovery-point` API with ScanResults field
+ Both backup IAM role and scanner IAM role required for all configurations
+ JSON backup plan structure includes ScanSettings at plan level and ScanActions in rules
# Resilience in AWS Backup
AWS Backup takes its resilience — and your data security — extremely seriously.
AWS Backup stores your backups with *at least* as much resilience and durability as your resource’s original AWS service would give you, if you backed it up there.
AWS Backup is designed to use the AWS global infrastructure to replicate your backups across multiple Availability Zones for durability of 99.999999999% (11 nines) in any given year, provided that you adhere to the current AWS Backup documentation.
AWS Backup encrypts your backup plans at rest and continuously backs them up. You can also restrict access to your backup plans using AWS Identity and Access Management (IAM) credentials and policies. For more information, see [Authentication](https://docs.aws.amazon.com/aws-backup/latest/devguide/authentication.html), [Access Control](https://docs.aws.amazon.com/aws-backup/latest/devguide/access-control.html), and [ Security Best Practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html).
The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. AWS Backup stores your backups across Availability Zones. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures. For more information, see [AWS Backup Service Level Agreement (SLA)](https://aws.amazon.com/backup/sla/).
Furthermore, AWS Backup empowers you to copy your backups across Regions for even greater resilience. For more information about the AWS Backup cross-Region copy feature, see [Creating a Backup Copy](https://docs.aws.amazon.com/aws-backup/latest/devguide/recov-point-create-a-copy.html).
For more information about AWS Regions and Availability Zones, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/).