AWS extends EBS Volume Clones to copy block storage across accounts with optional KMS re-encryption
A small storage feature is a useful way to understand how cloud accounts, resource sharing and key management fit together.
Amazon Web Services announced on 9 September that Amazon EBS Volume Clones can now copy a volume into a different AWS account, with the option to re-encrypt the copy under a key held in the destination account. Channy Yun's post on the AWS News Blog frames it as a way to refresh test and development environments held in separate accounts while keeping production data isolated.
Sharing runs through AWS Resource Access Manager (RAM). The source account owner selects "Share volume", adds the target account to a resource share, and the target accepts it in its RAM console. The volume then appears in the target account's EBS volume list, where a copy can be started. The copy must be created in the same Availability Zone as the source.
Unencrypted volumes and those encrypted with a customer-managed key can be shared; volumes encrypted with an AWS managed key cannot. Where a customer-managed key is in use it must also be shared with the target, which may choose a different key so the copy is re-encrypted on arrival. Sharing is free; initiating a copy incurs a one-time fee based on volume size, billed to the receiving account, and the new volume is charged at standard EBS rates. CloudTrail records a SharedVolumeCopyInitiated event and EventBridge emits notifications at the initializing and completed states. It is available wherever EBS Volume Clones is supported.
Why it matters
Many organisations now run dozens of AWS accounts as isolation boundaries, and single-account features keep being reworked to cross that line. Moving a volume between accounts previously meant snapshot, share and restore; a direct clone removes steps from a common workflow. The encryption constraints are the instructive part: they show how identity, key ownership and storage are bound together, which developers need to grasp before designing multi-account systems.
Many organisations now run dozens of AWS accounts as isolation boundaries, and single-account features keep being reworked to cross that line.
Owner shares the volume
Source account adds the target account to a Resource Access Manager share
Target accepts the share
The volume appears in the target account's EBS volume list
Copy is initiated
Same Availability Zone as the source; optionally re-encrypt with a target-account customer-managed key
Copy completes
CloudTrail logs SharedVolumeCopyInitiated; EventBridge emits initializing and completed events
What you can learn from this
- Accounts are the hardest boundary in AWS. An account is a container for resources, permissions and billing, and nothing inside it can be reached from outside without an explicit grant. Teams use separate accounts for production, development and security tooling so that a mistake or compromise in one has a limited blast radius. The cost of that isolation is friction whenever data legitimately needs to cross, which is exactly the gap this feature fills, and the reason so many recent AWS launches are variations on "now works across accounts".
- Resource sharing is a two-sided handshake. Resource Access Manager lets an owner offer a resource to another account, but the offer does nothing until the recipient accepts it. That design prevents one account from pushing resources, and their associated costs or risks, into another without consent. Once accepted, the shared item shows up in the recipient's own console as if it were local, though the owner still controls it and can withdraw the share.
- Key ownership decides what can move. AWS managed keys belong to a single account and cannot be granted to another, which is why volumes encrypted with them cannot be shared here. Customer-managed keys carry a key policy that the owner writes, and that policy can name other accounts. EBS uses envelope encryption, so the volume's data key is wrapped by the KMS key; re-encrypting the copy under the target's own key removes any lasting dependency on the source account's key and lets the target rotate or revoke independently.
- Block storage is tied to a location. An EBS volume is replicated within one Availability Zone and attached to instances in that zone only, so a direct clone must stay in the same zone. Snapshots behave differently because they are stored in object storage that spans a region, which is why cross-zone or cross-region moves still go through snapshots. Knowing which storage primitive is local and which is regional prevents surprises in disaster recovery plans.
- Every control-plane action should leave a trace. CloudTrail records the API call that started the copy and who made it, while EventBridge turns state changes into events that other services can react to. Together they give you both an audit log for later review and a hook for automation now, such as tagging the new volume, attaching it to a test instance or notifying a channel when the copy completes. Features that ship with both from day one are easier to govern.
We teach this
How to use this in practice
- Draw your own account map before touching the feature. On one page, box each AWS account you use or know of, then draw arrows for every existing cross-account relationship: RAM shares, KMS key policies naming other accounts, assumed roles, shared snapshots. Mark which boxes hold production data. Done is a diagram where every arrow has a reason written next to it, and any unexplained arrow becomes a question for the owner of that account. Redraw it after any change to a key policy or share, since the map is only useful while it is current.
- Audit which keys could ever cross an account boundary. Run
aws kms list-keys, then for each keyaws kms describe-key --key-id <id>and note theKeyManagerfield (AWS or CUSTOMER). For customer-managed keys, runaws kms get-key-policy --key-id <id> --policy-name defaultand search the output for account IDs other than your own. Done is a short table of keys, their manager type and whether any external account appears in the policy, with a note on whether each external grant is still needed. - Confirm the audit trail works before you rely on it. Run
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=SharedVolumeCopyInitiated --max-results 5in a region you use. An empty result is fine; the point is proving that the lookup returns cleanly and that you know where the events would appear if a copy were ever started from your data. Done is the command saved in your notes with its output and the region it was run in. - Write an EventBridge rule for the completed state. Create a rule whose event pattern matches the EBS volume copy notification with a state of
completedand point it at an SNS topic or a small Lambda function that logs the event. Use the console's test-event feature oraws events put-eventswith a hand-written sample to fire it. Done is a rule that turns a sample completion event into a message you can see, ready for a real copy. Delete the test rule afterwards if you do not intend to keep it.
Sources
- Introducing Amazon EBS Volume Clones across AWS accounts — AWS News Blog
Our reporting is an original summary; full coverage is at the links above.
Don't just read about it — build it.
Square 1 teaches the skills behind the headlines, with every line of your work graded by AI. Find your starting point in 3 minutes.
Get your free skill report