Amazon EBS extends Volume Clones to cross-account copy
AWS extends Amazon EBS Volume Clones to copy volumes across accounts, with optional re-encryption in the destination account. Multi-account teams can now refresh test environments with current production data, provided they work within the encryption and Availability Zone constraints.
September 9, 2026. AWS is extending its Amazon EBS Volume Clones to cross-account copy, a year after introducing them for instant, point-in-time copies inside a single Availability Zone. A volume can now be shared to another account through AWS RAM, then copied there with optional re-encryption. For any organization that isolates its environments into separate accounts, this removes a recurring headache: refreshing a test pool with current production data without ever touching production.
What cross-account copy changes
Volume Clones solve a narrow problem: getting a point-in-time copy of a volume without waiting out a full snapshot cycle or a restore. Last year AWS confined them to a single account and a single Availability Zone. That limit chafed for organizations built around multiple accounts, where production lives in one account, testing in another, and development in a third.
The mechanism is now straightforward. The volume owner shares it with the destination account in AWS Resource Access Manager (RAM), the service for sharing resources across accounts or within an AWS Organization. The destination account accepts the share, sees the volume in its Amazon EBS console, and starts a volume copy. The flow works from the console as well as through the API, including via the AWS MCP Server for teams working from a coding assistant.
The operational payoff is immediate. Instead of duplicating snapshots, sharing them, then restoring them by hand, the QA team receives a directly usable clone of the production database. Test data stays fresh, and the gap between the pre-production environment and reality narrows.
The encryption guardrails
This is where the announcement gets more demanding. Not all volumes can be shared equally, and the difference comes down to encryption mode.
Unencrypted volumes and volumes encrypted with a customer managed key (CMK) can be shared. Volumes encrypted with the AWS managed key (AMK) cannot. That restriction is a direct consequence of how AWS KMS works: an AMK belongs to a single account and cannot be delegated.
Two practical implications follow. First, when copying a volume encrypted with a CMK, that CMK must itself be shared with the destination account, or the copy fails at decryption time. Second, the destination account can specify a different CMK to re-encrypt the copy on arrival — exactly the right move when accounts have separate security boundaries.
For teams about to use the feature, the starting point is an encryption-mode audit of production volumes. A volume encrypted with an AMK must first be migrated to a CMK (through a re-encrypted snapshot, for instance) before it can feed a test account. That is a prerequisite to plan for, not an option.
Zone, pricing, and observability
The copy must be created in the same Availability Zone as the source volume. AWS recommends using Zone IDs (such as use1-az1) rather than zone names, because names do not map to the same physical locations across accounts.
On pricing, sharing through AWS RAM is free. A one-time fee, calculated on volume size, is charged to the account where the copy lands, and the copied volume then incurs the usual EBS charges from creation onward. The model scales with data size, with no recurring surprise.
Finally, the operation is observable. The SharedVolumeCopyInitiated event appears in AWS CloudTrail, and Amazon EventBridge emits events at the start of the copy (initializing state) and at its end (completed state), with the shared volume ID, the consuming account, and a timestamp. That is enough to wire an alert when an unexpected account copies a sensitive volume.
Snapshots still have their place
Faced with this feature, the fair question is why not stick with snapshots. The answer is purpose. A snapshot is a backup: incremental, replicable across regions, durable over time, built for restore. A Volume Clone is a working snapshot: instant, but confined to the same zone and — until now — a single account. For refreshing a QA environment, the clone wins on speed and simplicity; for cross-region disaster recovery, the snapshot remains essential.
The new flow also has a welcome compliance side effect. By re-encrypting the copy with a CMK from the destination account, you avoid pushing a production key into a less protected environment. A production database holding personal data can feed a test account under a distinct key, with CloudTrail logging that lets you audit exactly who copied what, and when.
The cost reads in two lines. The one-time copy fee, proportional to size, is marginal next to the storage cost of the copied volume, billed from creation. The real cost, as usual, is not the operation: it is the configuration debt — un-migrated AMK volumes, loosely governed RAM shares, and EventBridge alerts that were never wired up.
Verdict
Cross-account copy turns Volume Clones into a multi-account engineering building block rather than a storage gimmick. It removes the most expensive friction of isolated environments: refreshing test data.
If you run a multi-account architecture with a Landing Zone or strict security boundaries, adopt the feature for your QA and disaster-recovery flows. But start by migrating volumes to CMK, audit who is allowed to share volumes, and hook EventBridge onto SharedVolumeCopyInitiated.
If you need to copy to another region, look elsewhere: the shared-Availability Zone requirement is firm, and snapshots remain the tool for cross-region moves. Finally, remember that a clone is not a backup — it is an environment-instantiation tool, to be paired with a real snapshot and retention policy.