Sharing AMIs across AWS accounts is a common requirement for deploying consistent infrastructure.
Let’s see it in action. Imagine you’ve just built a golden AMI with Packer in Account A and now want to use it in Account B.
First, in Account A, you’ll need to grant explicit ec2:ModifyImageAttribute and ec2:RegisterImage permissions to Account B. This is done by modifying the AMI’s attributes.
aws ec2 modify-image-attribute \
--image-id ami-0abcdef1234567890 \
--launch-permission "Add=[{UserId=111122223333}]" \
--region us-east-1
Replace ami-0abcdef1234567890 with your AMI ID and 111122223333 with the AWS Account ID of Account B. This command tells AWS that Account B is now allowed to see and launch instances from this AMI.
Now, in Account B, you can see the AMI, but you can’t directly launch it because it doesn’t show up in your own AMIs list. You need to "copy" the AMI ID into your account’s context.
aws ec2 describe-images \
--owners 111122223333 \
--filters "Name=image-id,Values=ami-0abcdef1234567890" \
--region us-east-1
This describe-images call, using the source account ID as the owner, will return the details of the shared AMI. The output will contain the ImageId that you can then use in Account B.
To make it easier to manage, you can create a snapshot of the shared AMI in Account B. This effectively creates a new AMI that is entirely owned by Account B.
aws ec2 create-image \
--instance-id i-0123456789abcdef0 \
--name "MyCopiedGoldenAMI" \
--description "Copied from Account A" \
--no-reboot \
--region us-east-1
Wait, that’s not right. You can’t create an image from an AMI directly. You need to launch an instance from the shared AMI first.
Let’s correct that. In Account B, launch an EC2 instance from the shared AMI:
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--count 1 \
--instance-type t3.micro \
--subnet-id subnet-0123456789abcdef0 \
--region us-east-1 \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=TempAMIBuilder}]'
Once the instance is running, you can create a new AMI from it:
aws ec2 create-image \
--instance-id i-0123456789abcdef0 \
--name "MyCopiedGoldenAMI-AccountB" \
--description "Copied from Account A" \
--no-reboot \
--region us-east-1
This create-image command takes a running instance (or a stopped one, but --no-reboot is often preferred for speed) and registers it as a new AMI within Account B. This new AMI is fully owned by Account B and doesn’t rely on cross-account permissions for subsequent launches.
The core problem this solves is the need for consistent, pre-configured machine images across different AWS environments or teams, without needing to manually rebuild them. By sharing the original AMI, you ensure everyone starts with the same base. Copying it into the target account then decouples future usage from the source account’s permissions.
A common pitfall is forgetting that the shared AMI ID in the target account is still owned by the source account. Any modifications or deletions to the original AMI in Account A will affect Account B’s ability to use it. Creating a copy in Account B eliminates this dependency.
The real power comes when you automate this process. You can use AWS Systems Manager (SSM) Automation documents or Lambda functions triggered by CloudTrail events to automatically copy shared AMIs into your target accounts whenever a new version is published in the source account. This ensures your "golden AMIs" are always up-to-date everywhere.
You might also want to consider using AWS Organizations’ Service Control Policies (SCPs) to restrict which accounts can share AMIs or to enforce policies around AMI creation and sharing.
The next step is often managing these copied AMIs, including lifecycle policies for deletion and versioning.