AWS has expanded Amazon EBS Volume Clones to support copying volumes across different accounts. The update impacts one of the most widely used building blocks of cloud infrastructure: block storage attached to Amazon EC2 instances. From now on, teams managing separate AWS environments can create a copy of an EBS volume in another account, with the additional option to encrypt the copy using an AWS Key Management Service key belonging to the receiving account, if needed.
The announcement addresses a recurring need for organizations that do not consolidate development, testing, production, backups, or specific business units within a single AWS account. Account segregation is frequently adopted to define roles, budgets, policies, and operational responsibilities. In these scenarios, moving or providing a copy of volume data is not merely a technical operation: it also involves access boundaries and encryption key management.
With this new capability, clones can now cross that organizational boundary. AWS also explicitly highlights the re-encryption option using an AWS KMS key located in the destination account. This is a notable detail, as it allows the receiving account to associate the copy with its own key management domain, rather than treating encryption simply as an attribute inherited from the source environment.
A storage operation integrated into multi-account workflows
Amazon EBS is the AWS block storage service used alongside Amazon EC2. Volumes can host operating systems, application data, and other persistent assets required by running workloads. Providing a clone in another account opens a more direct path for preparing copies destined for distinct contexts, without reducing the operation to a simple file transfer.
The most immediate use case is when a team needs to make a volume replica available to an environment with its own AWS account. This may involve development and testing activities isolated from production, a department operating with infrastructure autonomy, or an organization utilizing dedicated accounts for different functions and projects. While the announcement does not remove the need to establish appropriate access rules, it delivers a purpose-built feature for cross-account volume copying.
The distinction matters on an operational level as well. An EBS volume is not an indistinct archive: it is a resource tied to an infrastructure's configuration and to the processes governing its use, availability, and protection. Moving a copy of it to a different account means having to consider who administers it, with what permissions, and under which policies. AWS therefore includes, in the same update, both the clone transfer and the ability to apply a recipient KMS key.
Encryption shifts to the account receiving the copy
AWS Key Management Service is the service used to create and manage cryptographic keys within the AWS ecosystem. In the announced case, re-encryption is optional: users can choose an AWS KMS key in the destination account when creating the cross-account copy. The phrasing is important, as it does not present the operation as an automatic waiver of encryption or as a configuration enforced under all circumstances.
For those architecting cloud environments across separate accounts, the ability to direct encryption toward a recipient key can help maintain more consistent accountability for the copied resource. The account hosting the new volume can, in fact, bring cryptographic protection under its own set of keys and controls. This does not eliminate decisions regarding permissions, key rotation, auditing, and data classification, but it provides a native option at the moment the copy is created.
However, overinterpreting the announcement should be avoided. AWS announced the introduction of the feature and the re-encryption option with AWS KMS in the target account; it did not present this capability as a complete, automated solution for every migration, disaster recovery, or governance requirement. Organizations will still need to assess compatibility with their procedures, the sensitivity of the data on the volume, and the policies applied to the respective accounts.
Why this matters for organizations splitting workloads on AWS
Using multiple accounts is a widespread practice when seeking to separate environments and limit the scope of users, applications, or teams. In these models, cross-account operations tend to require explicit steps and careful permissions design. The arrival of cross-account EBS clones directly addresses this dynamic: a volume copy can be routed to a different account, while encryption can be tied to a key managed in the new context.
The new feature can also be useful for standardizing internal procedures. A central team may need to prepare a reference volume, while another account must receive a copy on which to conduct testing or operational activities. In a larger organization, the same pattern can serve to distribute datasets and configurations across separate domains. The potential benefit depends not only on the speed of the operation, but on the ability to integrate it into workflows that respect existing administrative boundaries.
At the same time, copying a volume requires caution. If the content includes personal data, application secrets, credentials, or regulated information, duplicating it into an additional account expands the number of resources that must be inventoried and protected. The new feature does not replace controls such as access reviews, data minimization, or the adoption of retention policies. It may simplify the copy mechanism, but it does not automatically transfer responsibility for security decisions.
What remains to be verified in individual environments
AWS announcement materials do not detail every aspect that a cloud manager will need to examine prior to adoption: authorization configurations, environment constraints, costs, operational turnaround times, existing automations, and compliance requirements. These elements depend on the account structure and the workloads involved. For this reason, the feature should be regarded as a new infrastructure capability to be tested within existing procedures, rather than a command to be introduced indiscriminately into production.
A sensible first step will be to map the volumes for which a cross-account copy is truly necessary and determine who should be authorized to initiate it. The second concerns the keys: if re-encryption is chosen, organizations must identify the appropriate AWS KMS key in the destination account and verify that its governance is consistent with the type of data transferred. Finally, organizations will need to update documentation and controls so that the presence of the clone is visible both to the originating team and to the one managing it after the copy.
AWS thus adds another piece to storage management in multi-account architectures. The direction is clear: enabling the transfer of an EBS copy across account boundaries, while simultaneously leaving the choice to encrypt it with a recipient KMS key. Its real-world effectiveness will depend on customers' ability to integrate this option into already mature provisioning, security, and data governance processes.
