Sharing an Amazon Machine Image (AMI) across AWS accounts is a powerful way to standardize your deployments, onboard new teams, or distribute software. You can create an AMI from an existing EC2 instance, then explicitly share it with other AWS account IDs. This allows those accounts to launch new EC2 instances using your standardized image.

Let’s walk through the process and see it in action.

Creating an AMI

First, you need an EC2 instance that has the software and configuration you want to capture.

  1. Launch an EC2 Instance: If you don’t have one, launch a new EC2 instance. For this example, let’s say we’ve launched a t3.micro instance in the us-east-1 region with a standard Amazon Linux 2 AMI.
  2. Configure the Instance: Connect to your instance via SSH and install any necessary software, update packages, and configure settings. For instance, you might install a web server:
    sudo yum update -y
    sudo yum install -y httpd
    sudo systemctl start httpd
    sudo systemctl enable httpd
    
    You could then create a simple index.html file:
    echo "<h1>Hello from my custom AMI!</h1>" | sudo tee /var/www/html/index.html
    
  3. Create the AMI: Once your instance is configured, you can create an AMI from it.
    • Navigate to the EC2 console.
    • Under "Instances," select your configured instance.
    • Click "Actions" -> "Image and templates" -> "Create image."
    • Give your AMI a name (e.g., my-webserver-ami) and a description.
    • Ensure "No reboot" is unchecked for a consistent snapshot, or check it if you need to minimize downtime (though this might lead to inconsistent data in the snapshot).
    • Click "Create image."

AWS will now create snapshots of your instance’s root volume (and any other attached EBS volumes you selected) and register them as an AMI. This can take a few minutes. You can monitor the progress in the EC2 console under "AMIs."

Sharing the AMI

Once the AMI is created, you can share it. Let’s say you want to share it with Account ID: 111122223333 and Account ID: 444455556666.

  1. Navigate to AMIs: In the EC2 console, go to "AMIs" under "Images."

  2. Select Your AMI: Find and select the my-webserver-ami you just created.

  3. Modify Permissions: Click "Actions" -> "Modify AMI permissions."

  4. Add Account IDs: Under "Account permissions," click "Add account." Enter 111122223333 and click "Save." Repeat for 444455556666.

    You’ll see a confirmation that the AMI is now shared with these accounts.

    Note: You can also share with "All accounts" (publicly) or by Organization/Organizational Unit (OU), but sharing with specific account IDs is the most common and secure method for cross-account sharing.

Launching an Instance from a Shared AMI

Now, let’s switch to the perspective of Account ID: 111122223333.

  1. Navigate to AMIs: In their EC2 console, they go to "AMIs" under "Images."
  2. Filter for Private AMIs: By default, they’ll see their own AMIs. To see the shared AMI, they need to change the filter:
    • Click the "Filter" button.
    • In the "Owned by" dropdown, select "Shared with me."
  3. Find the AMI: They should now see my-webserver-ami (or whatever name you gave it).
  4. Launch Instance: Select the AMI and click "Launch instance from AMI."
  5. Configure and Launch: They proceed through the instance launch wizard just as they would with any other AMI, selecting an instance type, configuring storage, security groups, etc.

When the instance launches, it will have all the software and configurations from the original AMI, including the Apache web server and the index.html file. If they navigate to the public IP address of the new instance, they should see "Hello from my custom AMI!".

Managing AMI Permissions and Lifecycle

  • Deregistering AMIs: When an AMI is no longer needed, you should deregister it. This removes it from your account’s AMI list. However, the underlying snapshots will persist until you explicitly delete them.
  • Deleting Snapshots: To fully remove the storage associated with an AMI, you must go to the "Snapshots" section in EC2, find the snapshots related to your AMI, and delete them.
  • Copying AMIs: You can also copy an AMI to another AWS region. This is useful for disaster recovery or for making your AMI available to users in different geographic locations. This is done via the "Actions" -> "Copy AMI" option.
  • Cross-Account Copying: While you can share an AMI directly, you can also use the copy-ami AWS CLI command to copy an AMI from one account to another, even across regions. This is often done for more controlled distribution.

The most counterintuitive aspect of AMI sharing is that the AMI itself is just a metadata record. The actual data resides in the EBS snapshots. When you share an AMI, you are essentially sharing access to that metadata record, which in turn grants permission for the target account to use the underlying snapshots to launch instances. This means the originating account is responsible for the storage costs of the snapshots until they are explicitly deleted.

The next challenge you’ll likely face is automating this AMI creation and sharing process, often involving AWS Systems Manager (SSM) for image building and custom Lambda functions or EventBridge rules for managing permissions.

Want structured learning?

Take the full Ec2 course →