AWS Storage Blog

Enhancing resource-level permissions for copying HAQM EBS snapshots

Businesses use HAQM Elastic Block Store (HAQM EBS) snapshots to capture point-in-time copies of application data volumes that can serve as baseline standards when creating new volumes. With snapshot copy, users are enabled to launch application workloads in different AWS Regions or meet data protection and disaster recovery requirements. Security and regulatory compliance remain top priorities as users migrate their AWS workloads across different AWS Regions and accounts, with a common request being resource-level permissions for API calls to enable granular access control.

Today, HAQM EBS announces enhanced resource-level permissions for the CopySnapshot action, allowing users to specify additional resource-level authorization in their  AWS Identity and Access Management (IAM) policies for source snapshots when copying snapshots. This enhancement helps users control which IAM identities can create EBS snapshots from source snapshots and define the conditions under which these snapshots can be used to copy EBS snapshots.”

In this post, we outline the changes to resource-level permissions, explore use cases for their implementation, and discuss the importance of adopting this improved permission model. We also provide a transition plan for you to migrate from the previous resource-level authorization model.

What is changing?

When copying a snapshot from a source snapshot, you need to use an IAM policy to grant permissions to perform the CopySnapshot action. Previously, the CopySnapshot action in your IAM policy needed authorization for the destination snapshot copy, and the source snapshot was not part of the resource context of the CopySnapshot action in your IAM policy. With this change, you can now enforce resource-level permissions for both the destination snapshot getting created and the source snapshot. To meet your specific permission requirements on the source snapshots, you can also use any of these six HAQM Elastic Compute Cloud (HAQM EC2)-specific condition keys: ec2:Encrypted, ec2:VolumeSize, ec2:Owner, ec2:ParentVolume, ec2:SnapshotTime, and ec2:Parentsnapshot. Furthermore, you can use global condition keys for the source snapshot in your IAM policy. If you have already added a resource statement using an HAQM Resource Name (ARN) for the snapshots being copied, then you must also explicitly specify a resource statement for your snapshot. Observe the following.

Previous policy: 

A policy that allows the snapshot being created to have a condition on the request tag. We did not have any IAM policy targeting the snapshot being copied. We can assume snap-1234567890abcdef0 is the snapshot being copied.

{
    "Effect": "Allow",
    "Action": "ec2:CopySnapshot"
        "Resource": "arn:aws:ec2:*::snapshot/*"
    "Condition": {
                "StringEquals": {
                    "aws:RequestTag/BestNHLTeam": "Kraken"
                }
            }  
}

Policy needed after this change:

A policy that allows both the destination snapshot and source snapshot resources is now necessary.

{
    "Effect": "Allow",
    "Action": "ec2:CopySnapshot"
    "Resource": "arn:aws:ec2:*::snapshot/snap-1234567890abcdef0"  
}

{
    "Effect": "Allow",
    "Action": "ec2:CopySnapshot"
    "Resource": "arn:aws:ec2:*::snapshot/*"  
}

To differentiate the wildcard from the source and the destination snapshots, you need to use the wildcard .../${*} for the snapshots being created, and the .../snap-* for the source snapshots. 

What can you do with more resource-level permission for source snapshots?

Transitioning to the new resource-level permission model offers two benefits:

1/ Enhanced granularity in access control

Resource-level permissions for source snapshots provide you with fine-grained control over which snapshots can be used to create snapshot copies. Specifying conditions allows you to set permissions for individual snapshots or categories of snapshots to help manage backups through snapshot copy. Moreover, you can specify conditions to limit certain source snapshots used for backup workloads. For example, if your organization takes EBS snapshots as regular backups and uses snapshot copy to move workloads to a second Region for a disaster recovery purpose, then with this new permission model you can restrict the copy operation owned by your database administrator, as well as limit the source snapshots to come from a primary Region.

1. Only allow the copy of snapshots from users who are database administrators.

// IAM policy for the snapshot being copied
{
    "Effect": "Allow",
    "Action": "ec2:CopySnapshot",
    "Resource": [
        "arn:aws:ec2:*::snapshot/snap-1234567890abcdef0",
        "arn:aws:ec2:*::snapshot/snap-9876543210fedcba0"
        
    ],
    "Condition": {
        "StringEquals": {
            "aws:PrincipalTag/role": "database-admin"
        }
    }
}
//IAM policy for the copied snapshot
{
    "Effect": "Allow",
    "Action": "ec2:CopySnapshot",
    "Resource": "arn:aws:ec2:*::snapshot/${*}"
}

2. Only allow snapshot copies from snapshots from a requested Region.

// IAM policy for the snapshot being copied
{
    "Effect": "Allow",
    "Action": "ec2:CopySnapshot",
    "Resource": [
        "arn:aws:ec2:*::snapshot/snap-1234567890abcdef0",
        "arn:aws:ec2:*::snapshot/snap-9876543210fedcba0"
    ],
    "Condition": {
        "StringEquals": {
            "aws:RequestedRegion": "<AWS Region>"
        }
    }
}

//IAM policy for the copied snapshot
{
    "Effect": "Allow",
    "Action": "ec2:CopySnapshot",
    "Resource": "arn:aws:ec2:*::snapshot/${*}"
}

3. Only allow the snapshot copies from snapshots with a specific tag.

// IAM policy for the snapshot being copied
{
    "Effect": "Allow",
    "Action": "ec2:CopySnapshot",
    "Resource": [
        "arn:aws:ec2:*::snapshot/snap-*"
    ],
    "Condition": {
        "StringEquals": {
            "aws:ResourceTag/classification": "not-sensitive",
            "aws:ResourceOrgId": "<your organization ID>"
        }
    }
},
//IAM policy for the copied snapshot
{
    "Effect": "Allow",
    "Action": "ec2:CopySnapshot",
    "Resource": "arn:aws:ec2:*::snapshot/${*}"
}

2/ Resource and cost optimization

This permission not only enhances your security and compliance requirements but also provides a powerful tool for resource prioritization and cost optimization. Specifying conditions such as snapshot age allows you to control which snapshots are prioritized for creating copies. For example, you can make sure that more recent snapshots are prioritized over others. This can help streamline your backup strategy, such as copying a snapshot to a secondary Region, while aligning resource usage with your business priorities.

Only allow the copy of a snapshot from snapshots that are newer than 2025-01-01.

// IAM policy for the snapshot being copied
{
    "Effect": "Allow",
    "Action": "ec2:CopySnapshot",
    "Resource": [
        "arn:aws:ec2:*::snapshot/snap-*"
    ],
    "Condition": {
        "DateGreaterThan": {
            "ec2:SnapshotTime": "2025-01-01T00:00:00Z"
        }
    }
}
,
//IAM policy for the copied snapshot
{
    "Effect": "Allow",
    "Action": "ec2:CopySnapshot",
    "Resource": "arn:aws:ec2:*::snapshot/${*}"
}

How do I prepare for the change?

Most AWS users aren’t impacted by this update. We have notified you by email and through your AWS Health Dashboard if we detected that you have a policy that would be impacted by this change. Impacted accounts are currently allowlisted, and your previous policy remains in place until June 30 2025. On June 30 2025, AWS starts removing accounts from the allowlist as you update your IAM policies, with September 30, 2025 being the final deadline for all accounts to migrate to the new permission model. After September 30, 2025, your requests to invoke CopySnapshot API may be denied if you haven’t taken any action to update your policy.

Timeline:

  • June 30, 2025: AWS begins removing accounts from the allowlist, starting with users who have updated IAM policies.
  • September 30, 2025: Final deadline for all accounts to migrate to the new permission model.

Identifying and updating impacted policies:

You can review your AWS CloudTrail logs or run the IAM get-account-authorization-details CLI command, or this script to list all IAM policies, such as CopySnapshot actions to identify the relevant policies. In general, policies needing updates fall into the following two categories.

Category 1: You do not have an allow statement for the source snapshot resource

If your policy’s “Resource” element only matched the snapshot getting created, then you need to add an allow statement for the source snapshot as well. See the following: snap-9876543210fedcba0 is the source snapshot.

{
    "Effect": "Allow",
    "Action": "ec2:CopySnapshot"
    "Resource": "arn:aws:ec2:*::snapshot/*"  
}

The updated code block would become the following.

{
  "Statement": [
   {
    "Effect": "Allow",
    "Action": "ec2:CopySnapshot"
    "Resource": "arn:aws:ec2:*::snapshot/snap-1234567890abcdef0"  
    }

    {
    "Effect": "Allow",
    "Action": "ec2:CopySnapshot"
    "Resource": "arn:aws:ec2:*::snapshot/*"  
    }
  ]
}

Category 2: Your “Resource” element allows both snapshots getting created and the source snapshots, but your condition only applies to snapshots getting created.

If your policy’s “Resource” element used a wildcard to match both the source snapshot and the snapshot getting created, and included “Condition” elements that are specific to the snapshots being created, then you must modify the “Resource” string to apply only to the snapshot getting created and add a new statement to authorize source snapshots. Here, you need to use wildcard .../${*} for the snapshots being created, and use .../snap-* for the source snapshots. 

The previous policy that would not work after this change.

... 
"Action": "ec2:CopySnapshot", 
"Resource": "*", 
"Condition": { "StringLike": { "aws:RequestTag/CSISnapshotName": "*" } }
...

The updated code block would become the following.

{
    "Effect": "Allow",
    "Action": "ec2:CopySnapshot", 
    "Resource": "arn:aws:ec2:*::snapshot/${*}",
    "Condition": { "StringLike": { "aws:RequestTag/CSISnapshotName": "*" } }
},

{
    "Effect": "Allow",
    "Action": "ec2:CopySnapshot",
    "Resource": "arn:aws:ec2:*::snapshot/snap-*"
}

Validating updates using DryRun mode

If you need to validate that your IAM policies are correct, then use the DryRun mode to test that your changes to IAM policies are correct. The DryRun mode allows you to see the authorization result under the new permission model even if your actual APIs are allowlisted to use the old permission model. To use DryRun, specify the --dry-run parameter in AWS Command Line Interface (AWS CLI) commands or HAQM EBS CopySnapshot API calls. Your CopySnapshot API calls that use DryRun always return an error response. If you receive an error with DryRunOperation, then this means your policy works with the new permission model. If you receive an error with UnauthorizedOperation, then you must make an update on your IAM policies. Refer to the AWS CLI documentation to find out more about the DryRun mode.

Conclusion

The updated resource-level permissions enhance security, control, and operational flexibility. If you currently use the old permission model and need to continue to do so, then you can reach out to AWS Support to seek an accommodation of your use case. If you are ready to migrate to the new permission policy before June 30, 2025, then you can also ask AWS Support to remove you from the allow-list. This change is part of a broader initiative to enable similar permissions for other actions such as CreateVolume.

For more details about the supported condition keys, visit the documentation. If you have feedback about this post, then submit it in the comments section or contact AWS Support. To learn more about HAQM EBS volumes and Snapshots, visit the HAQM EBS user guide.

TAGS: , ,
Atticus Wong

Atticus Wong

Atticus Wong is a Senior Technical Product Manager with the HAQM Elastic Block Store (EBS) team, focusing on Provisioned IOPS SSD volumes, observability, and security. Outside of work, he enjoys live music events, cooking, and traveling.

Tuhin Mukherjee

Tuhin Mukherjee

Tuhin Mukherjee is a Partner Solution Architect at HAQM Web Services (AWS), specializing in helping organizations successfully navigate their cloud transformation journeys. He works closely with AWS Partners and customers to architect, strategize, and implement complex migration and modernization initiatives. With extensive expertise in migration and disaster recovery services, Tuhin has guided numerous organizations across diverse industries in optimizing their cloud infrastructure and achieving their business objectives.