> ## Content Index > Fetch the complete content index at: https://blog.kloudops.pro/llms.txt > Use this file to discover other available public pages before exploring further. # Copying Encrypted AMIs Across AWS Accounts - What I Learned the Hard Way - URL: https://blog.kloudops.pro/copying-encrypted-amis-across-aws-accounts-what-i-learned-the-hard-way/ - Published: 2026-03-14T12:14:28.000Z - Updated: 2026-03-14T12:14:28.000Z - Author: Kloudops Pro - Tags: Cloud, #Import 2026-10-20 16:39 Everything was planned for the migration, and the first task was to copy the existing AMI of one of the components to the destination AWS account. I was following the documentation, but we hit a wall. ![](https://storage.ghost.io/c/d2/5f/d25fda85-4ca3-41fe-a9ba-d6a6b8e486a4/content/images/2026/03/image-1.png) AMI snapshot was encrypted with a AWS managed key! So that means we can't proceed with copying the AMI to the destination account? Is our migration at risk? Not at all. ### What is the issue? In simple words, the issue was that the particular AMI snapshot was encrypted with a AWS managed key, and we couldn't share the AMI with the destination AWS account due to that. Okay.. let's learn a bit about encryption and AWS KMS. Encryption is a mechanism where you convert the readable data into an unreadable/encoded format using Keys and algorithms. This is the fundamental requirements for data privacy. [Read more on encryption here.](https://www.cloudflare.com/en-gb/learning/ssl/what-is-encryption/?ref=blog.kloudops.pro) AWS KMS is a service provided by AWS to manage keys that we can use to encrypt the data in an AWS account \[1\]. There are three types of policies. 1. AWS Owned Keys: Not visible to the customers at all. Entirely managed by AWS, and only the services that use it can access. 2. AWS Managed Keys: Managed by AWS, but the customer can view them in the console, CLI, etc. But it cannot set permission for usage by the customer. Only usable with the given AWS account and Region. 3. Customer-Managed Keys: This is entirely managed by the customer, including the full lifecycle of the key. Can be shared with accounts and regions. Normally, if you do not explicitly enable encryption when the resource is created, it remains unencrypted. But if your AWS account policies enforce encryption by default, it will automatically use the relevant AWS-managed key to encrypt unless you use your own key (customer-managed key). I hope you may now have some idea. Now let's go back to the issue. Since our AMI snapshot was encrypted with the AWS-managed keys, we can't share it with other accounts. As mentioned above, AWS managed keys are bound to an account and region, so we can't permit the other accounts to use them for decryption. In other hand, the destination account must have access to the key in order to decrypt the AMI snapshot. ### Okay.. How to achieve this, then? The solution is pretty straightforward. If we can encrypt the AMI snapshot with a CMK (Customer Managed Key), we can grant the destination account to use that key to decrypt the AMI snapshot, and that will let the user copy the AMI to the account. Let's go through the steps. 1. Create a CMK in your KMS if it has not already been created. 2. Copy the AMI, which is encrypted by the AWS Managed key, to the same account by re-encrypted with CMK. ``` aws ec2 copy-image \ --source-region \ --source-image-id \ --name \ --encrypted \ --kms-key-id \ --region ``` 1. Next, go to the KMS and update the key policy of the aforementioned CMK to grant temporary access to the destination account to use the key to decrypt. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam:::root", "arn:aws:iam:::root" ] }, "Action": "kms:*", "Resource": "*" } ] } ``` 1. After that, update the permissions of the AMI and the underlying block storage, and add the destination account ID in the account sharing section. 2. Next, go to the destination account and check in the AMI section (private images) to see if the shared AMI is visible here. 3. Follow step #2 in the destination account, and copy the AMI to the destination account with its own AWS-managed key or a CMK. 4. Once that is done, revoke the sharing setting in the CMK policy and AMI in the source account. That's it. Now the AMI is shared with the destination account, and we did the migration successfully. What looked like an AMI problem was a KMS problem all along. The lesson - always check who owns your encryption keys before assuming the copy will just work 😉. \[1\] [https://docs.aws.amazon.com/kms/latest/developerguide/overview.html](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html?ref=blog.kloudops.pro)