Share or Copy an Encrypted AMI to Another AWS Account: KMS Key Policy, aws/ebs Fix, "Client.InternalError: Client Error on Launch", Auto Scaling and Terraform

To share or copy an encrypted AMI to another AWS account, three things must line up. First, the AMI's snapshots must be encrypted with a customer managed KMS key, because AMIs encrypted with the default AWS managed key (aws/ebs) cannot be shared: copy the AMI in your own account and re-encrypt it with a customer managed key first. Second, that key's key policy must allow the other account to use it (Decrypt, DescribeKey, ReEncrypt, GenerateDataKey and CreateGrant), and the other account's IAM user or role needs the same permissions on your key. Third, you share the AMI's launch permission with the account and, if they want their own copy, the snapshots too. The other account then copies it with --encrypted --kms-key-id and its own key, so it no longer depends on yours. If an instance launched from the shared AMI goes straight from pending to terminated with Client.InternalError: Client error on launch, the launching identity cannot use the KMS key; for Auto Scaling groups in another account, the service-linked role also needs a KMS grant. Below: every step with console, CLI and PowerShell, the key policy, the errors, Auto Scaling, cross-Region copies, Organizations, Terraform and Python.

The shop's "golden image" (a patched Windows server with the ticketing app installed) lived in the main AWS account. When Ethan set up a separate staging account, the plan was simple: share the AMI, launch it, done. The share took ten seconds. The launch took ten seconds too, and then the instance was terminated, with the reason "Client.InternalError: Client error on launch". Nothing about keys, nothing about encryption, nothing helpful at all. The image was fine. The staging account just was not allowed to open the lock on its disks.

New to AMIs or KMS? The cards below explain both in plain English, plus how AWS Organizations and snapshot billing fit in.

Why encrypted AMIs are harder to share

An AMI is a small record that points at one or more EBS snapshots, which hold the actual disk data. Our plain-English AMI guide covers the basics. When those snapshots are encrypted, the data can only be read with the KMS key that encrypted them. Sharing the AMI shares the record; it does not share the key. So the other account can see your AMI, start a launch, and then fail at the moment EC2 tries to decrypt the disk.

There are two kinds of key you may be dealing with:

• The AWS managed key, aws/ebs: created automatically in each account and Region, and used when you tick "encrypt" without choosing a key. Its key policy belongs to AWS and you cannot change it, so you can never give another account access to it. That is why AMIs backed by snapshots encrypted with the AWS managed key cannot be shared.
• A customer managed key: a key you create in KMS. You control its key policy, so you can let other accounts use it. This is the kind you need for sharing.

The good news: copying an AMI can change its key. You copy the AMI in your own account, choose your customer managed key, and the copy is the version you share. Encryption only goes one way, though: you can copy unencrypted to encrypted, or re-encrypt with a different key, but you cannot copy an encrypted AMI to an unencrypted one.

Share or copy? Sharing lets the other account launch from your AMI as it stands; the AMI and its storage stay in your account and on your bill. Copying gives the other account its own independent AMI, encrypted with its own key and billed to it. For anything long-lived, the usual pattern is both: you share so they can copy, they copy with their own key, and then you can stop sharing.

Jake: "So the image was shared, but the key to unlock its disks wasn't?"

Ethan: "Exactly. Like handing someone a locked box and keeping the key in your pocket."

The two-account checklist

In the examples below, 444455556666 is the source account that owns the AMI, and 111122223333 is the target account that wants to use it. Here is everything each side needs:

Everything happens in the same Region. AMIs and KMS keys are both Regional, so if the target account works in another Region, copy the AMI to that Region first (covered below).

Step 1: check the key, and re-encrypt if it is aws/ebs

In the source account, find which key encrypts the AMI's snapshots. Three commands get you there:

# 1. The AMI's snapshots, and whether they are encrypted
aws ec2 describe-images --image-ids ami-0abcdef1234567890 \
  --query "Images[].BlockDeviceMappings[].Ebs.[SnapshotId,Encrypted]" --output table

# 2. The key each snapshot uses
aws ec2 describe-snapshots --snapshot-ids snap-0123456789abcdef0 \
  --query "Snapshots[].KmsKeyId" --output text

# 3. Is that key AWS managed or customer managed?
aws kms describe-key --key-id arn:aws:kms:us-east-1:444455556666:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d \
  --query "KeyMetadata.[KeyManager,KeyState]" --output text

If the last command prints AWS, the snapshots use the AWS managed key and you need a re-encrypted copy. If it prints CUSTOMER and Enabled, skip to step 2. In the console, the same information is on the AMI's Storage tab and the snapshot's details.

Create a customer managed key if you do not have one for sharing yet. In the KMS console: Customer managed keys, Create key, Symmetric, Encrypt and decrypt, give it an alias such as alias/shared-ami, and finish. EBS only supports symmetric keys. With the CLI:

aws kms create-key --description "Key for AMIs shared with other accounts" \
  --query "KeyMetadata.Arn" --output text
aws kms create-alias --alias-name alias/shared-ami \
  --target-key-id arn:aws:kms:us-east-1:444455556666:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d

Copy the AMI with the new key. In the EC2 console, select the AMI, choose Actions, Copy AMI, keep the same Region, tick Encrypt EBS snapshots of AMI copy and choose your customer managed key. With the CLI:

aws ec2 copy-image \
  --source-image-id ami-0abcdef1234567890 \
  --source-region us-east-1 --region us-east-1 \
  --name "ticketing-golden-2026-10-shared" \
  --encrypted \
  --kms-key-id arn:aws:kms:us-east-1:444455556666:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d

Use the full key ARN rather than an alias when you will share it: the other account cannot resolve your alias. The new AMI starts as pending and becomes available when its snapshots finish copying, which can take from minutes to hours for large disks, because re-encrypting makes a full copy rather than an incremental one. aws ec2 wait image-available --image-ids ami-NEW waits for you.

Step 2: let the other account use your KMS key

Open the key in the KMS console, choose the Key policy tab, and either use Other AWS accounts, Add other AWS accounts (which adds suitable statements for you) or edit the policy and add these two statements, keeping the existing ones:

{
  "Sid": "AllowTargetAccountUseOfTheKey",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
  "Action": [
    "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*",
    "kms:GenerateDataKey*", "kms:DescribeKey"
  ],
  "Resource": "*"
},
{
  "Sid": "AllowTargetAccountGrantsForAWSResources",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
  "Action": "kms:CreateGrant",
  "Resource": "*",
  "Condition": {"Bool": {"kms:GrantIsForAWSResource": "true"}}
}

Naming the account's root principal does not give the root user anything special. It means "this account may use the key, as far as its own IAM policies allow". So the target account also has to grant its users and roles permission, in step 4. CreateGrant matters because EC2 creates a grant on the key for each encrypted volume it attaches; without it, launches fail even when Decrypt is allowed.

If you need Auto Scaling groups in the target account to use the key, leave out the GrantIsForAWSResource condition on the second statement, because the target account will create a grant directly (see the Auto Scaling section).

Step 3: share the AMI, and the snapshots if they will copy it

In the console:

1. Open the EC2 console in the AMI's Region and choose AMIs.
2. Select the AMI (the re-encrypted copy, if you made one) and choose Actions, Edit AMI permissions.
3. Keep it Private. Under Shared accounts, choose Add account ID, enter 111122223333 and choose Share AMI.
4. Choose Save changes. The AMI's Permissions tab now lists the account.
5. If the other account will copy the AMI, open each of its snapshots under Snapshots, choose Actions, Snapshot settings, Modify permissions, and add the same account ID.

With the CLI:

# Share the AMI (launch permission)
aws ec2 modify-image-attribute --image-id ami-0fedcba9876543210 \
  --launch-permission "Add=[{UserId=111122223333}]"

# Share each snapshot (needed only for copying)
aws ec2 modify-snapshot-attribute --snapshot-id snap-0fedcba9876543210 \
  --attribute createVolumePermission --operation-type add --user-ids 111122223333

With PowerShell:

Edit-EC2ImageAttribute -ImageId ami-0fedcba9876543210 `
  -Attribute launchPermission -OperationType add -UserId "111122223333"

Edit-EC2SnapshotAttribute -SnapshotId snap-0fedcba9876543210 `
  -Attribute createVolumePermission -OperationType add -UserId "111122223333"

Just launching does not need the snapshots shared: EC2 gives the instance access to the snapshots behind a shared AMI during the launch. Copying is different: the copy reads the snapshots directly, so the owner must grant read access to the storage, not just the AMI. Either way, the key has to be shared.

Two limits worth knowing. Tags you put on the AMI are not visible to the other account, except tags with the ec2:SharedTag/ prefix. And an AMI with encrypted snapshots cannot be made public; encrypted AMIs can only be shared with specific accounts, organizations or OUs.

Step 4: in the other account, launch or copy it with your own key

Give the identity permissions. The user or role in 111122223333 that launches or copies needs IAM permission on the source key, plus the usual EC2 actions. A policy for copying:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "UseSourceAndOwnKeys",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt", "kms:DescribeKey", "kms:CreateGrant",
        "kms:ReEncrypt*", "kms:GenerateDataKey*"
      ],
      "Resource": [
        "arn:aws:kms:us-east-1:444455556666:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d",
        "arn:aws:kms:us-east-1:111122223333:key/9f8e7d6c-5b4a-3c2d-1e0f-9f8e7d6c5b4a"
      ]
    },
    {
      "Sid": "CopyAndDescribeImages",
      "Effect": "Allow",
      "Action": ["ec2:CopyImage", "ec2:DescribeImages", "ec2:DescribeSnapshots", "ec2:CreateTags"],
      "Resource": "*"
    }
  ]
}

Find the shared AMI. In the EC2 console of the same Region, choose AMIs and change the filter from "Owned by me" to Private images. With the CLI:

aws ec2 describe-images --executable-users self --owners 444455556666 \
  --query "Images[].[ImageId,Name,CreationDate]" --output table

Copy it with your own key (recommended for anything you will keep):

aws ec2 copy-image \
  --source-image-id ami-0fedcba9876543210 \
  --source-region us-east-1 --region us-east-1 \
  --name "ticketing-golden-2026-10" \
  --encrypted \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/9f8e7d6c-5b4a-3c2d-1e0f-9f8e7d6c5b4a

The copy belongs to you, uses your key, and keeps working if the source account later deregisters its AMI, stops sharing, or disables its key. Launch permissions and tags from the source are not carried over, so share or tag the copy again if you need to.

Or launch directly from the shared AMI with a normal launch. You can also choose a different key for the new volumes in the launch's storage settings; the identity still needs permission to use the source key to read the snapshot.

Jake: "Why copy it if launching works?"

Ethan: "Because then staging doesn't break the day someone in the main account tidies up old AMIs or rotates a key."

Every error, and what fixes it

To read the exact reason for a failed launch, look at the instance's state reason, which stays visible for a while after termination:

aws ec2 describe-instances --instance-ids i-0123456789abcdef0 \
  --query "Reservations[].Instances[].[State.Name,StateReason.Code,StateReason.Message]" --output table

For a failed AMI copy, aws ec2 describe-images --image-ids ami-NEW --query "Images[].[State,StateReason.Message]" shows why it failed.

Fixing "Client.InternalError: Client error on launch"

This is the error that brings most people to this topic, and its name is misleading: nothing is wrong inside AWS. EC2 tried to create the encrypted root volume, KMS refused, and the launch was abandoned. Work through these checks in order:

1. Confirm the reason with the describe-instances command above. Client.InternalError with "Client error on launch" on an encrypted volume is almost always KMS.
2. Check the key is enabled: aws kms describe-key on the snapshot's key, and look at KeyState. Disabled or PendingDeletion keys fail every launch.
3. Check the key policy (in the account that owns the key) allows the launching account, including kms:CreateGrant.
4. Check the IAM policy of the user or role that launches, in the launching account. It must allow the same KMS actions on the key's full ARN. A cross-account key needs both the key policy and the IAM policy; either one alone is not enough. The same two-sided rule applies to cross-account S3 access.
5. Look for an aws:SourceIp condition in the key policy or IAM policy. The decrypt call comes from the EC2 service on your behalf, not from your IP address, so an IP condition rejects it. Use kms:ViaService (for example ec2.us-east-1.amazonaws.com) to limit the key to EC2 instead.
6. Check who actually launches. An Auto Scaling group, a CI pipeline role, Elastic Beanstalk or a launch template run under different identities. The identity that calls RunInstances, or the Auto Scaling service-linked role, is the one that needs the key.

Ethan's staging account failed at step 3: the key policy still listed only the main account. Adding the staging account's two statements fixed the next launch on the first try. If launches fail with a plain permission error instead, our guide to "not authorized to perform ec2:RunInstances" covers the IAM side.

The same error appears when an instance with an encrypted volume is started after the key was disabled or its permissions removed: the instance goes to pending, then back to stopped. The fix is the same: restore the key's state and permissions.

Auto Scaling groups with a key from another account

Auto Scaling launches instances with its service-linked role, AWSServiceRoleForAutoScaling, not with your user. That role can use AWS managed keys in its own account, but not your customer managed keys, and certainly not a key in another account. For a cross-account key, two things are needed, in this order:

1. In the key's account (444455556666), the key policy allows the target account to use the key and to create grants (the two statements from step 2, without the GrantIsForAWSResource condition on CreateGrant).
2. In the Auto Scaling group's account (111122223333), a user or role with kms:CreateGrant on the key creates a grant for the service-linked role:

aws kms create-grant \
  --region us-east-1 \
  --key-id arn:aws:kms:us-east-1:444455556666:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d \
  --grantee-principal arn:aws:iam::111122223333:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling \
  --operations "Encrypt" "Decrypt" "ReEncryptFrom" "ReEncryptTo" "GenerateDataKey" "GenerateDataKeyWithoutPlaintext" "DescribeKey" "CreateGrant"

The service-linked role must already exist (it is created the first time you make an Auto Scaling group). After you create the grant, keep that role; deleting and recreating it breaks the grant. When launches fail, the group's Activity tab shows the failed launch with the same Client.InternalError reason.

If the key is in the same account as the group, you can skip the grant and add the service-linked role to the key policy directly as a principal. Our Auto Scaling explainer covers launch templates and groups if they are new to you.

The simplest route of all: copy the shared AMI into the target account with the target account's own key (step 4), and point the launch template at the copy. Then the Auto Scaling group never touches the other account's key.

Copying an encrypted AMI to another Region

KMS keys never leave their Region, so a cross-Region copy always re-encrypts with a key in the destination Region. You run the copy in the destination Region and name a key there:

aws ec2 copy-image \
  --source-image-id ami-0abcdef1234567890 \
  --source-region us-east-1 \
  --region eu-west-2 \
  --name "ticketing-golden-2026-10-london" \
  --encrypted \
  --kms-key-id arn:aws:kms:eu-west-2:444455556666:key/0a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d

Leave out --kms-key-id and the copy uses your account's default EBS encryption key in the destination Region, which is usually the AWS managed key, and that copy cannot be shared. To share in several Regions, copy to each Region with a customer managed key there, then share each copy. Multi-Region keys make this tidier: a primary key and its replicas share the same key material and key ID across Regions, though each replica still has its own key policy that you must update for other accounts.

A cross-Region or re-encrypting copy is a full copy of the data, so it takes longer than later, incremental copies of the same AMI. If you need a guaranteed finish time, a time-based copy lets you set a completion window from 15 minutes to 48 hours, for an extra charge.

Sharing with a whole AWS Organization or OU

If every account in your organization (or one organizational unit) should be able to use the image, share with the organization instead of listing account IDs. In the Edit AMI permissions page, add an organization or OU ARN, or with the CLI:

aws ec2 modify-image-attribute --image-id ami-0fedcba9876543210 \
  --launch-permission "Add=[{OrganizationalUnitArn=arn:aws:organizations::444455556666:ou/o-exampleorgid/ou-ab12-cd34ef56}]"

The key policy then needs to allow the organization rather than single accounts. A common pattern uses "Principal": {"AWS": "*"} with a condition on aws:PrincipalOrgID (your organization ID), so any identity in your organization that also has IAM permission can use the key, and nobody outside it can. Pair that with kms:ViaService for EC2 to keep the key from being used for anything else. Our AWS Organizations explainer covers organization IDs and OUs.

Automating it: Terraform, Python, Image Builder

Terraform has a resource for each step. In the source account:

resource "aws_ami_copy" "shared" {
  name              = "ticketing-golden-shared"
  source_ami_id     = var.golden_ami_id
  source_ami_region = "us-east-1"
  encrypted         = true
  kms_key_id        = aws_kms_key.shared_ami.arn
}

resource "aws_ami_launch_permission" "staging" {
  image_id   = aws_ami_copy.shared.id
  account_id = "111122223333"
}

resource "aws_snapshot_create_volume_permission" "staging" {
  for_each    = toset([for d in aws_ami_copy.shared.ebs_block_device : d.snapshot_id])
  snapshot_id = each.value
  account_id  = "111122223333"
}

The key itself is an aws_kms_key with a policy that includes the statements from step 2. In the target account, another aws_ami_copy with its own kms_key_id makes the independent copy.

Python (boto3), run in the target account to copy and wait:

import boto3

ec2 = boto3.client("ec2", region_name="us-east-1")
resp = ec2.copy_image(
    SourceImageId="ami-0fedcba9876543210",
    SourceRegion="us-east-1",
    Name="ticketing-golden-2026-10",
    Encrypted=True,
    KmsKeyId="arn:aws:kms:us-east-1:111122223333:key/9f8e7d6c-5b4a-3c2d-1e0f-9f8e7d6c5b4a",
)
new_ami = resp["ImageId"]
print("copying to", new_ami)
ec2.get_waiter("image_available").wait(
    ImageIds=[new_ami], WaiterConfig={"Delay": 30, "MaxAttempts": 240})
print("available:", new_ami)

If the waiter stops with a failure, call describe_images on the new ID and print StateReason; a KMS access problem shows up there. A Lambda function doing the same job needs the KMS permissions on its execution role, for both the source key and its own key, which is the usual reason a copy "works from my laptop but fails in Lambda".

EC2 Image Builder can do all of this as part of a pipeline: its distribution settings can share the output AMI with other accounts or copy it into them, per Region, with a KMS key per Region. The keys still need policies that allow the target accounts. Amazon Data Lifecycle Manager can also copy shared snapshots and AMIs across accounts on a schedule with cross-account copy event policies.

What sharing and copying cost

• Sharing costs nothing extra. The owner keeps paying for the AMI's snapshot storage; the other account pays for the instances it launches.
• Copying has no copy fee unless you use a time-based copy. The target account pays for storing its new snapshots, and the source account pays any data transfer charges.
• Re-encrypting or cross-Region copies are full copies, so the first copy stores the whole disk again. Our guide to how snapshots are billed explains why later copies are smaller.
• KMS charges a monthly fee per customer managed key plus a small per-request charge; launches and copies make only a handful of requests. Details are in our KMS costs guide.

The forgotten cost is the intermediate copy. If you re-encrypted an AMI just to share it, and the other account has since made its own copy, deregister the intermediate AMI and delete its snapshots, or you pay to store the same disk twice.

Cleaning up and keeping it safe

• Stop sharing after the copy. Once the target account has its own copy, remove the launch permission (--launch-permission "Remove=[{UserId=111122223333}]") and the snapshot permission, and, if the key was only for that purpose, remove the account from the key policy.
• Use one key for shared images rather than your main data key, so giving another account access to it does not open up anything else.
• Limit the key to EC2 with kms:ViaService, so the other account can use it for launching and copying, not for decrypting arbitrary data.
• Check what you share before you share it: anything baked into the image (passwords in config files, SSH keys, application secrets) goes with it.
• Watch it in CloudTrail: ModifyImageAttribute events show who shared what, and KMS CreateGrant and Decrypt events from the other account show it being used.
• Disabling the key stops new launches and copies that need it, and stopped instances using it may fail to start. Copies the other account re-encrypted with its own key are unaffected, which is one more reason to copy.

Frequently asked questions

Staging now runs on its own copy of the golden image, encrypted with the staging account's key. Each month, when the main account builds a new patched image, a small pipeline re-encrypts it with the shared key, shares it, and the staging account copies it with its own key. Jake asked why it needs three steps instead of one. Ethan's answer: "Because each account should hold its own keys. The extra steps are the price of nobody else being able to lock you out of your own servers."

Revision note. Written October 19, 2026. Sharing an image takes ten seconds; sharing the key behind it is the part that makes it work.