Understanding IAM roles and permissions in AWS Backup

Short description

AWS Backup uses three separate IAM entities that each serve a distinct purpose. Misunderstanding or misconfiguring any of these entities can result in failed jobs or "Access Denied" errors.

The three IAM entities are:

1. The logged-in user or role – The IAM principal making API calls (such as CreateBackupVault or CreateBackupPlan), whether through the AWS Management Console, AWS CLI, SDK, or API.
2. The job role – The IAM role attached to the actual backup, restore, or copy job.
3. The service-linked role (SLR) – A built-in role that AWS Backup uses to perform certain actions behind the scenes, including copy operations and Amazon Elastic File System (Amazon EFS) backups.

To understand and configure IAM permissions for AWS Backup, review the following:

• Understand the three IAM entities in AWS Backup
• Understand the AWS Backup Default service role
• Attach the correct managed policies to your job role
• Troubleshoot permission-related job failures

Resolution

Note: If you receive errors when you run AWS Command Line Interface (AWS CLI) commands, then see Troubleshooting errors for the AWS CLI. Also, make sure that you're using the most recent AWS CLI version.

Understand the three IAM entities in AWS Backup

Each of the three IAM entities operates independently. A failure in one doesn't necessarily indicate a problem with the others.

Logged-in user or role

This is the IAM user or role that you use to interact with the AWS Backup service. For example, if you're logged into the console and can't call CreateBackupVault, the issue is with this user's or role's permissions — not the job role.

For an exhaustive list of AWS Backup API actions and the permissions required for each, see Actions, resources, and condition keys for AWS Backup.

Job role

This is the IAM role that you attach to a backup, restore, or copy job. This role must have the necessary permissions to access the resources being backed up or restored, and must have a trust policy that allows AWS Backup to assume it.

Service-linked role (SLR)

This is a built-in role that AWS Backup manages on your behalf. It is completely different from the Default service role. The SLR is used for copy operations and Amazon EFS backups. The ARN structure for the SLR is:

arn:aws:iam::[account-id]:role/aws-service-role/backup.amazonaws.com/AWSServiceRoleForBackup

Important: If you're performing cross-account copies, the service-linked role must exist in the destination account. If it doesn't, your copy job might fail.

For more information, see Using service-linked roles for AWS Backup.

Understand the AWS Backup Default service role

AWS Backup can automatically create a Default service role for you. It's important to understand the difference between the actual Default role and a custom role that happens to share the same name.

This is the Default role (notice service-role in the path):

arn:aws:iam::[account-id]:role/service-role/AWSBackupDefaultServiceRole

This is NOT the Default role (this is a customer-created role):

arn:aws:iam::[account-id]:role/AWSBackupDefaultServiceRole

The difference is the service-role path segment. When AWS Backup expects the Default role to exist, it looks for the one with service-role in the ARN. If it can't find it, the job fails — even if you have a custom role named AWSBackupDefaultServiceRole in your account.

Note: You don't have to use the Default role. You can use a custom role instead. However, avoid naming custom roles AWSBackupDefaultServiceRole to prevent confusion.

For more information, see Default service roles for AWS Backup.

Attach the correct managed policies to your job role

AWS Backup provides four primary managed policies for backup, restore, and copy jobs:

Managed policy	Purpose
AWSBackupServiceRolePolicyForBackup	Allows backups and copies for all supported resources except Amazon S3
AWSBackupServiceRolePolicyForRestores	Allows restores for all supported resources except Amazon S3
AWSBackupServiceRolePolicyForS3Backup	Allows backups and copies for Amazon S3
AWSBackupServiceRolePolicyForS3Restore	Allows restores for Amazon S3

Note: The Default service role automatically includes AWSBackupServiceRolePolicyForBackup and AWSBackupServiceRolePolicyForRestores. The S3 policies are not included by default and must be attached separately if you need to back up or restore S3 buckets.

Even if you don't use the managed policies, you can review their JSON to determine the exhaustive permissions needed for the service you're trying to protect. For more information, see AWS managed policies for AWS Backup.

Troubleshoot permission-related job failures

When a backup, restore, or copy job fails due to permissions, follow this mental checklist:

1. Job role permissions, trust policy, and permission boundaries – Verify that the job role has the required permissions, that its trust policy allows AWS Backup to assume it, and that no permission boundaries are restricting access.
2. Vault access policies – Check that the backup vault access policy allows the required actions.
3. Service control policies (SCPs) – Check for any SCPs in your AWS Organizations that might contain explicit deny statements affecting AWS Backup operations.
4. KMS key policies – If your resources are encrypted, verify that the KMS key policy grants the necessary permissions. This is especially important for cross-account copies.

Related information

• Default service roles for AWS Backup
• AWS managed policies for AWS Backup
• Using service-linked roles for AWS Backup
• Actions, resources, and condition keys for AWS Backup
• Why does my AWS Backup cross-account copy job fail?
• How do I troubleshoot failed backup jobs in AWS Backup?
• Restore a backup by resource type