Key Takeaways

  • Sharing an encrypted AMI requires two separate grants: the AMI's launch permission, and the underlying KMS key's grant to the target account — missing either causes a silent-looking "unable to decrypt" launch failure.
  • AMI sharing across accounts never copies the snapshot data automatically outside the key policy you define — a shared AMI remains encrypted with your key unless you explicitly re-encrypt during copy.
  • The cleanest pattern: grant the target account kms:CreateGrant + decrypt permissions scoped to the specific key, not account-wide KMS access.
  • A shared AMI referencing a KMS key only works as long as that key and its grants exist — deleting the source key breaks every account that launched instances from it.

The Two-Part Problem With Encrypted AMI Sharing

Sharing an unencrypted AMI across AWS accounts is one API call: ModifyImageAttribute with the target account ID as a launch permission. Encrypted AMIs add a second requirement that trips up most teams: the target account also needs permission to use the KMS key that encrypted the AMI's underlying EBS snapshots. Grant only the AMI permission, and the target account sees the AMI in their console but gets an access-denied error the moment they try to launch an instance from it.

Step 1: Share the AMI Itself

aws ec2 modify-image-attribute \
  --image-id ami-0abcd1234efgh5678 \
  --launch-permission "Add=[{UserId=222233334444}]"

This makes the AMI visible and launchable (pending the key grant below) to account 222233334444.

Step 2: Grant the Target Account Access to the KMS Key

The AMI's snapshots are encrypted with a specific KMS key — usually a customer-managed key (CMK), since the default AWS-managed EBS key (aws/ebs) cannot be shared across accounts at all.

Check which key encrypted the AMI's snapshot:

aws ec2 describe-images --image-ids ami-0abcd1234efgh5678 \
  --query "Images[0].BlockDeviceMappings[0].Ebs.KmsKeyId"

Update the CMK's key policy to allow the target account to use it:

{
  "Sid": "AllowCrossAccountAmiUsage",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::222233334444:root" },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey",
    "kms:CreateGrant"
  ],
  "Resource": "*"
}

Apply it:

aws kms put-key-policy \
  --key-id arn:aws:kms:us-east-1:111122223333:key/abcd-1234-efgh-5678 \
  --policy-name default \
  --policy file://updated-key-policy.json

kms:CreateGrant is the part most guides skip — without it, the target account can see key metadata but EC2 in that account can't create the grant it needs at instance-launch time to decrypt the volume.

Step 3: Target Account Launches the Instance

From account 222233334444:

aws ec2 run-instances \
  --image-id ami-0abcd1234efgh5678 \
  --instance-type t3.medium \
  --subnet-id subnet-0a1b2c3d \
  --key-name my-keypair

EC2 in the target account automatically creates a temporary grant against the source account's CMK to decrypt the boot volume during launch — this is why kms:CreateGrant must be present in the key policy.

Cross-Account AMI Sharing Flow

<svg viewBox="0 0 760 340" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:760px;font-family:sans-serif;color:currentColor">
  <style>
    .box { fill: none; stroke: currentColor; stroke-width: 1.5; }
    .lbl { fill: currentColor; font-size: 13px; }
    .sub { fill: currentColor; font-size: 11px; opacity: 0.7; }
    .arrow { stroke: currentColor; stroke-width: 1.5; marker-end: url(#a6); fill: none; }
  </style>
  <defs>
    <marker id="a6" markerWidth="8" markerHeight="8" refX="6" refY="3" orient="auto">
      <path d="M0,0 L6,3 L0,6 Z" fill="currentColor" />
    </marker>
  </defs>

  <rect class="box" x="40" y="30" width="300" height="140" rx="8" />
  <text class="sub" x="55" y="50">Source Account 111122223333</text>
  <rect class="box" x="70" y="70" width="110" height="55" rx="6" />
  <text class="lbl" x="80" y="93">Encrypted AMI</text>
  <rect class="box" x="210" y="70" width="110" height="55" rx="6" />
  <text class="lbl" x="220" y="93">KMS CMK</text>
  <text class="sub" x="220" y="110">key policy updated</text>

  <rect class="box" x="420" y="30" width="300" height="140" rx="8" />
  <text class="sub" x="435" y="50">Target Account 222233334444</text>
  <rect class="box" x="450" y="70" width="110" height="55" rx="6" />
  <text class="lbl" x="460" y="93">EC2 Launch</text>
  <rect class="box" x="590" y="70" width="110" height="55" rx="6" />
  <text class="lbl" x="600" y="93">Temp Grant</text>
  <text class="sub" x="600" y="110">CreateGrant</text>

  <path class="arrow" d="M340,97 H420" />
  <path class="arrow" d="M560,97 H590" />
  <path class="arrow" d="M650,70 Q650,20 265,20 Q180,20 180,70" style="display:none" />

  <rect class="box" x="140" y="230" width="480" height="60" rx="6" />
  <text class="lbl" x="155" y="258">EC2 in target account decrypts boot volume using the grant</text>
  <text class="sub" x="155" y="276">Without kms:CreateGrant → launch fails with access denied</text>

  <path class="arrow" d="M505,125 V230" />
</svg>

Common Failure: "Client.InvalidKMSKey.InvalidState" or Access Denied at Launch

If the AMI appears shared but launches fail:

  1. Confirm the key policy includes kms:CreateGrant, not just kms:Decrypt.
  2. Confirm you're not using the default aws/ebs AWS-managed key — it cannot be shared cross-account at all; you must re-encrypt the AMI with a CMK first via copy-image with --encrypted --kms-key-id.
  3. Check IAM permissions in the target account's launching role — the KMS key policy alone isn't sufficient if the IAM role lacks kms:Decrypt in its own policy (KMS requires both).
# Re-encrypt an AMI from the default EBS key to a shareable CMK
aws ec2 copy-image \
  --source-image-id ami-0abcd1234efgh5678 \
  --source-region us-east-1 \
  --name "shareable-ami-copy" \
  --encrypted \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-1234-efgh-5678

FAQ

Why can't I share an AMI encrypted with the default AWS-managed EBS key? AWS-managed keys (aws/ebs) cannot have their policies modified to add external principals. You must re-encrypt with a customer-managed KMS key to share across accounts.

Does sharing an AMI also share its underlying snapshots? Yes — EC2 automatically shares the referenced EBS snapshots when you share the AMI, but the snapshots remain encrypted and require the same KMS key grant.

What happens if the source account deletes the KMS key after sharing? Any instance launch or snapshot restore in the target account referencing that key will fail permanently once the key is deleted — plan key retention around all downstream dependents.

Can I share an AMI with multiple target accounts at once? Yes, modify-image-attribute accepts multiple UserId entries in one call, and the KMS key policy can list multiple account principals similarly.

Get Your Cross-Account AMI Sharing Right the First Time

KMS key grants and AMI permissions interact in ways that produce confusing errors when misconfigured. Talk to f9infotech's AWS infrastructure team about setting up secure, repeatable cross-account AMI sharing.