EBS Volume Clones Across Accounts: RAM, AZ IDs, KMS

For about fifteen years, moving a block volume between AWS accounts meant the same tired four-step shuffle: snapshot the volume, share the snapshot, copy the snapshot into the target account, restore a new volume from it. EBS Volume Clones across accounts kills that pipeline. You share the live volume with AWS RAM, the other account accepts, and it clones straight into a new volume. No intermediate snapshot object to track, copy, tag, expire, and explain to your auditor.

It’s a small feature with an outsized blast radius on how you design multi-account environments — so let’s go through what actually happens under the hood, and the three things that will trip you up the first time.

What EBS Volume Clones across accounts actually does

The mechanics are simpler than the snapshot chain they replace. There are exactly three moves:

• The source account shares the volume through AWS Resource Access Manager, either from the EBS console’s “Share volume” action or by creating a resource share directly.
• The target account accepts the share. If both accounts sit in the same AWS Organization with RAM sharing enabled, the acceptance can be automatic; otherwise it’s an explicit invitation accept.
• The target account initiates the copy. The clone is created in, owned by, and billed to the target account. The source account never hands over control of anything beyond read access to the data.

The important design detail: sharing is not copying. A share costs nothing and creates nothing. The bytes only move when the target account pulls the trigger, which means you can pre-stage shares as a standing grant and let downstream teams refresh on their own schedule.

Creating the share from the CLI looks like this:

aws ram create-resource-share \
  --name prod-db-volume-to-dev \
  --resource-arns arn:aws:ec2:us-east-1:111122223333:volume/vol-0a1b2c3d4e5f67890 \
  --principals 444455556666 \
  --tags key=Purpose,value=env-refresh key=Expires,value=2026-10-07

On the other side, the target account finds and accepts the invitation:

aws ram get-resource-share-invitations \
  --query 'resourceShareInvitations[?status==`PENDING`].[resourceShareName,resourceShareInvitationArn]' \
  --output table

aws ram accept-resource-share-invitation \
  --resource-share-invitation-arn arn:aws:ram:us-east-1:111122223333:resource-share-invitation/EXAMPLE-GUID

AZ IDs, not AZ names — the part that will bite you

The clone has to be created in the same Availability Zone as the source volume. That sounds trivial until you remember that AWS randomizes AZ name-to-physical-zone mapping per account, specifically so everybody doesn’t pile into “us-east-1a.” Account A’s us-east-1a and Account B’s us-east-1a are almost certainly different buildings.

The fix is AZ IDs — stable identifiers like use1-az1 that mean the same physical zone in every account. Query both sides and match on ZoneId, never ZoneName:

aws ec2 describe-availability-zones \
  --region us-east-1 \
  --query 'AvailabilityZones[].{Name:ZoneName,Id:ZoneId}' \
  --output table

Run that in the source account, find the ZoneId that matches your volume’s AZ, then run it in the target account and use whatever ZoneName maps to that same ZoneId. If your automation hardcodes AZ names, this is the moment it starts failing in a way that looks like a permissions bug but isn’t.

KMS: encrypted volumes have rules

This is where most first attempts die. EBS encryption supports two flavors of key, and only one of them can cross an account boundary:

• AWS-managed keys (the aws/ebs default key) cannot be shared. Full stop. A volume encrypted under the default EBS key is not a candidate for cross-account cloning, and no amount of IAM policy will change that. If you want prod volumes to be clonable later, encrypt them with a customer managed key now.
• Customer managed keys (CMKs) work, but the key has to be shared with the target account too — via the key policy, not just an IAM policy. The target principal needs decrypt-and-use rights on the source CMK to read the source data.

The best part: during the copy, the target account can specify a different CMK. The clone gets re-encrypted under the target account’s own key as it lands. That means prod data arriving in a dev account is immediately protected by a key that the dev account controls and the prod account can revoke independently — which is exactly the separation your security team keeps asking for and the old snapshot-copy workflow made awkward.

Minimum key policy shape on the source CMK, added alongside your existing statements:

{
  "Sid": "AllowCloneTargetAccountUse",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::444455556666:root" },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey",
    "kms:CreateGrant"
  ],
  "Resource": "*",
  "Condition": {
    "Bool": { "kms:GrantIsForAWSResource": "true" }
  }
}

Scope the Principal down to the specific role that runs your refresh job rather than account root once you’ve got it working. The kms:CreateGrant action is what lets EBS hold a grant for the duration of the copy; without it the operation fails partway through with an access-denied that names the key, not the volume.

Running the copy

The copy is initiated from the target account against the shared volume ARN, specifying the destination AZ and the destination key. In the CLI this is the volume copy operation on the EC2 API — the example below is illustrative, so check the EBS Volume Clones documentation for the exact command name and flags in your CLI version:

# Illustrative — confirm flag names against the EBS Volume Clones docs
aws ec2 copy-volume \
  --source-volume-id vol-0a1b2c3d4e5f67890 \
  --source-region us-east-1 \
  --availability-zone us-east-1c \
  --encrypted \
  --kms-key-id arn:aws:kms:us-east-1:444455556666:key/dev-env-key \
  --tag-specifications 'ResourceType=volume,Tags=[{Key=Env,Value=dev},{Key=ClonedFrom,Value=prod}]'

Tag on creation, not afterward. Clones of production volumes are exactly the kind of resource that goes unnoticed for six months and then shows up as a line item nobody can explain.

Cost and audit

Sharing is free. Once a copy is initiated, you pay a one-time fee based on the size of the volume, charged to the account where the copy lands — the target, not the source. After that it’s standard EBS volume pricing for as long as the clone exists. That billing split matters organizationally: the team consuming the data pays for consuming it, which is a healthier incentive than prod absorbing the cost of everyone’s test refreshes.

Every step here is an API call, which means every step lands in CloudTrail in both accounts — the RAM share creation, the acceptance, the copy initiation, and the KMS grant. Build the detective control before you need it. “Who cloned a production volume into a sandbox account last Tuesday” should be a query, not an investigation.

At Enkompass (enkompass.net), this is our home turf. We design AWS architectures that survive contact with production — and the 3 AM page that comes with it. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.