AWS has extended EBS Volume Clones to support copies into another AWS account. The practical opportunity is a cleaner separation between production storage and the environment where a team develops or tests changes. The target account can a
1h ago
AWS has extended EBS Volume Clones to support copies into another AWS account. The practical opportunity is a cleaner separation between production storage and the environment where a team develops or tests changes. The target account can also use its own supported customer-managed encryption key for the copy.
The sharing workflow uses AWS Resource Access Manager. The source owner grants access, the target accepts the share and then creates a copy. This is a storage-copy capability, so application consistency still needs attention: copying a volume does not by itself establish that a multi-volume database was captured at a safe transactional boundary.
Two constraints deserve attention before implementation. The copy must remain in the same physical Availability Zone, and account-specific zone names are not reliable identifiers for that comparison. Use Availability Zone IDs. For encrypted volumes, the source key and its access policy also matter; the default AWS-managed key does not support this sharing workflow.
Build the rollout around an isolated test account, explicit key permissions and an application-level validation after the copy. Review the one-time copy charge and ongoing EBS storage charges. Teams handling sensitive production data should also decide which records need masking before the copied environment is made available to developers.
A thoughtful contribution can make all the difference. Be the first to share one.
aws