Copy an EBS Volume to Another AWS Account: Cross-Account Volume Clones Setup Guide

Refreshing a dev or test account with real production data has always meant snapshot the volume, copy the snapshot cross-account, share it, wait, then restore a new volume from it — four separate operations before anyone can attach a disk. As of September 10, 2026, AWS added cross-account support to Amazon EBS Volume Clones, which collapses that into two: share the volume through AWS RAM, then copy it directly in the target account. No snapshot step, no separate restore step, and the copy is available for attachment almost immediately instead of after a snapshot-and-restore round trip.

Why this is different from snapshot-based cross-account copy

The old pattern — create a snapshot, ModifySnapshotAttribute to share it, copy the snapshot into the target account, then create-volume --snapshot-id — still works and still has its uses (long-term retention, cross-region). What's new here is a direct volume-to-volume path: the source volume is shared as a live resource via AWS RAM, and the target account clones it straight into a new volume with copy-volumes, skipping the intermediate snapshot object entirely. AWS frames the main use case plainly: cloning a production database volume into an isolated dev account so engineers get a real, current copy of prod data without prod credentials or prod blast radius.

The constraint carried over from same-account Volume Clones is that the copy must land in the same Availability Zone as the source — which across accounts means matching AZ IDs (like use1-az1), not AZ names (us-east-1a), because AWS maps zone names to physical locations differently per account.

Prerequisites

• Source and target accounts both need ec2:CopyVolumes and ram:CreateResourceShare / ram:AcceptResourceShareInvitation permissions as appropriate.
• The source account needs kms:DescribeKey on the default Amazon EBS encryption key — this is required even for unencrypted volumes, since AWS validates encryption state during the share.
• If the source volume uses a customer managed KMS key, that key has to be shared with the target account separately (Step 4 below) — sharing the volume alone doesn't share the key.
• You can't share or copy a volume encrypted with the default AWS managed key for EBS across accounts. If your volume is on that key, re-encrypt it with a customer managed key first (a same-account copy-volumes with --kms-key-id set to a CMK does this).
• Know your target AZ ID up front: aws ec2 describe-availability-zones --region us-east-1 --query "AvailabilityZones[].[ZoneName,ZoneId]" in the source account tells you which AZ ID the source volume is actually in.

Step 1: Share the volume with the target account via AWS RAM

In the source account, find the volume's ARN, then create a resource share naming the target account as a principal:

1aws ram create-resource-share \
2  --name my-prod-volume-share \
3  --resource-arns arn:aws:ec2:us-east-1:111111111111:volume/vol-1234567890abcdef0 \
4  --principals 222222222222 \
5  --permission-arns arn:aws:ram::aws:permission/AWSRAMPermissionEBSVolumeCopyAccess \
6  --region us-east-1

The --permission-arns flag matters — omit it and you get AWSRAMDefaultPermissionEBSVolume, which only lets the target account view the volume's metadata, not copy it. AWSRAMPermissionEBSVolumeCopyAccess is the one that grants copy rights. This is a common first mistake: the share succeeds, the target account can see the volume, and copy-volumes still fails with an access error because the wrong managed permission was attached.

Step 2: Accept the share and confirm visibility in the target account

If source and target are in the same AWS Organizations org with resource sharing enabled, the share is accepted automatically. Otherwise, the target account has to explicitly accept it — check pending invitations with aws ram get-resource-share-invitations and accept with aws ram accept-resource-share-invitation --resource-share-invitation-arn <arn>.

Once accepted, confirm the volume shows up from the target account:

1aws ec2 describe-volumes \
2  --filters Name=owner-id,Values=111111111111 \
3  --region us-east-1

The response includes an OwnerId of 111111111111 (the source account) even though you're querying from the target account — that's expected, and it's how you distinguish a shared volume from one you own.

Step 3: Copy the shared volume (unencrypted or default-key path)

From the target account, run copy-volumes against the shared volume's ID:

1aws ec2 copy-volumes \
2  --source-volume-id vol-1234567890abcdef0 \
3  --volume-type gp3 \
4  --size 100 \
5  --throughput 250 \
6  --region us-east-1

If the source is unencrypted, the copy lands unencrypted by default. If it's encrypted and you don't specify --kms-key-id, the copy is encrypted with your account's own default EBS key, not the source account's key — cross-account copies never silently reuse the source account's key. This is worth pausing on, because it's the opposite of the same-account behavior, where the copy quietly inherits the source's key.

Step 4: Re-encrypt with a shared customer managed key (encrypted source volumes)

If you want the copy encrypted with the source account's CMK instead of your own default key, the source account has to add your account to that key's key policy first (grant kms:CreateGrant, kms:GenerateDataKey, kms:GenerateDataKeyWithoutPlaintext, kms:ReEncrypt*, and kms:Decrypt to your account/role). Once that's in place, pass the key explicitly:

1aws ec2 copy-volumes \
2  --source-volume-id vol-1234567890abcdef0 \
3  --kms-key-id arn:aws:kms:us-east-1:111111111111:key/abcd1234-a123-456a-a12b-a123b4cd56ef \
4  --region us-east-1

More commonly, though, you'll want to re-encrypt with a CMK that already lives in your own target account — swap the ARN above for a key in 222222222222 and skip the cross-account KMS policy grant entirely. That's usually the simpler, more isolated choice for a dev/test refresh, since it means the dev account doesn't need standing access to a production KMS key at all.

Step 5: Wait for initialization, then attach

The copy enters creating, then available quickly — you can attach it to an instance in the matching AZ right away, but it delivers only baseline performance (the lowest of 3,000 IOPS/125 MiB/s, or your provisioned rate) until background initialization finishes copying the actual data blocks. Check progress with:

1aws ec2 describe-volume-status \
2  --volume-ids vol-0abcdef1234567890 \
3  --region us-east-1

For a 1 TiB source volume, budget up to 6 hours for full initialization; each additional TiB up to 16 TiB adds roughly 1.2 hours.

Best practices

• Default to a CMK in the target account for the re-encryption key, not a shared source-account key, unless you have a specific reason the dev/test account needs access to production's KMS key material.
• Quiesce writes before copying if you need an application-consistent copy, not just crash-consistent — fsfreeze on Linux or VSS on Windows, same as you'd do before any snapshot.
• Use AZ IDs, not AZ names, when coordinating the target AZ across accounts — us-east-1a in one account is not necessarily the same physical zone as us-east-1a in another.
• Set up the EventBridge sharedVolumeCopy notification if this becomes a repeatable refresh workflow, rather than polling describe-volume-status by hand each time.
• Remove the resource share (or the account principal) once a one-off clone is done, so the source volume isn't sitting shared indefinitely for an account that only needed one snapshot's worth of data.

Common mistakes to avoid

• Sharing with the default AWSRAMDefaultPermissionEBSVolume and expecting copy-volumes to work. It won't — that permission is view-only; you need AWSRAMPermissionEBSVolumeCopyAccess.
• Assuming the copy inherits the source account's KMS key by default. It doesn't, cross-account — you get your own account's default EBS key unless you explicitly pass --kms-key-id.
• Trying to share a volume on the AWS managed EBS key. That's the one encryption state that can't be shared or copied cross-account at all — re-encrypt to a CMK first.
• Starting a second copy while one is still in progress. Only one copy operation can run per shared volume at a time, across every account it's shared with — a second request errors until the first finishes.
• Forgetting the source account also needs kms:DescribeKey on the default EBS key, even for a completely unencrypted volume — the share API checks encryption state regardless.

Troubleshooting

copy-volumes fails with an access/permission error even though describe-volumes shows the volume. You almost certainly shared with the view-only default RAM permission instead of AWSRAMPermissionEBSVolumeCopyAccess. Check the resource share's permission ARN and reattach the correct one.

Copy request fails with CopyVolumesLimitExceeded. You've hit the quota of 5 in-progress volume copies per Region for your account. Wait for one to finish or request a quota increase via Service Quotas.

Encrypted volume copy fails with a KMS access-denied error. The source account shared the volume but not the KMS key. Volume sharing and key sharing are two separate actions — check the CMK's key policy for the target account/role explicitly.

Copy succeeds but lands in the wrong Availability Zone from what you expected. You matched AZ names instead of AZ IDs across accounts. Re-check with describe-availability-zones in both accounts and compare ZoneId, not ZoneName.

FAQ

Does this replace cross-account snapshot copying? Not entirely — snapshots are still the right tool for long-term retention, cross-Region copies, and backup/DR, since Volume Clones are same-Region and same-AZ only. This is specifically for "give another account a fresh, live copy of this data right now."

Can the target account modify or delete the source volume? No. A shared volume only grants view and copy rights in the target account — it can't attach, modify, delete, or snapshot the volume you shared.

What does cross-account copying actually cost? Sharing through AWS RAM is free. The account that initiates the copy pays a one-time fee based on the volume's size, plus standard EBS storage/IOPS charges on the new volume going forward — charged to the target (consuming) account, not the source.

Can I copy a volume that's currently attached and in use? Yes — the source volume must be available or in-use (not mid-modification), and the copy is a crash-consistent point-in-time capture that doesn't affect the source volume's performance while it runs.

Is this available in every Region? It's available everywhere EBS Volume Clones are supported — all commercial Regions, AWS GovCloud (US), AWS China Regions, and supported Local Zones — but always confirm current regional support before depending on it in a specific Region.

Key takeaways

Further Reading

• Extend AWS EBS Volume Without Downtime in Linux
• Create RDS Snapshot via Lambda
• Official: Copy an Amazon EBS volume — AWS documentation
• Official: Share a volume — AWS documentation