Can EC2 boot from an EBS volume with a cross-account KMS key?

Yes, Amazon EC2 can boot from an encrypted root EBS volume using a customer-managed KMS key shared from another AWS account. This article explains the permission requirements in both the source and target AWS accounts, how to configure the KMS key policy and IAM roles, and the steps needed to launch an instance from a shared encrypted AMI or snapshot.

How Cross-Account KMS Encryption Works for Root Volumes

When an Amazon EC2 instance boots from an encrypted Amazon Elastic Block Store (EBS) root volume, the EC2 service must communicate with AWS Key Management Service (KMS) to generate a data key and decrypt the volume's encryption key. When the KMS key resides in a different AWS account (the key owner account) than the EC2 instance (the target account), permissions must be explicitly granted on both sides:

  1. Key Owner Account: The KMS key policy must allow the target AWS account (or specific IAM principals within it) to perform cryptographic operations and create grants.
  2. Target Account: The IAM user or role launching the EC2 instance must have IAM policy permissions to use the remote KMS key via its full Amazon Resource Name (ARN).

Note that AWS-managed keys (such as the default aws/ebs key) cannot be shared across accounts. You must use a customer-managed key (CMK) to share encrypted snapshots or AMIs and boot instances across account boundaries.

Step 1: Configure the KMS Key Policy in the Source Account

In the AWS account that owns the customer-managed KMS key (Account A), update the key policy to grant access to the target AWS account (Account B). Amazon EBS requires both standard cryptographic permissions and grant permissions (kms:CreateGrant, kms:ListGrants, kms:RevokeGrant) so the EC2 infrastructure can attach and manage the volume.

Add the following statements to your KMS key policy in Account A, replacing 222222222222 with the 12-digit account ID of Account B:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowUseOfTheKeyCrossAccount",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::222222222222:root"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowAttachmentOfPersistentResourcesCrossAccount",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::222222222222:root"
      },
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "kms:GrantIsForAWSResource": "true"
        }
      }
    }
  ]
}

Specifying arn:aws:iam::222222222222:root delegates permission management to Account B's IAM administrators rather than granting access to every principal in Account B automatically. The kms:GrantIsForAWSResource condition ensures that grants can only be created when an integrated AWS service like Amazon EBS or EC2 requests them on the user's behalf.

Step 2: Configure IAM Permissions in the Target Account

In the target account where the EC2 instance will run (Account B), attach an IAM policy to the user or role responsible for launching the EC2 instance (or to the Auto Scaling service-linked role if launching via an Auto Scaling group).

Replace 111111111111 with Account A's ID and provide the specific key ID:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowTargetPrincipalToUseCrossAccountKMSKey",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKeyWithoutPlaintext",
        "kms:ReEncryptFrom",
        "kms:ReEncryptTo",
        "kms:DescribeKey",
        "kms:CreateGrant"
      ],
      "Resource": "arn:aws:kms:us-east-1:111111111111:key/12345678-1234-1234-1234-123456789012"
    }
  ]
}

Special Consideration for Auto Scaling Groups

If you are launching EC2 instances in Account B using an Amazon EC2 Auto Scaling group, the Service-Linked Role (AWSServiceRoleForAutoScaling) in Account B initiates the instance launch. Because you cannot modify the inline IAM policies of a service-linked role directly, you must add the Auto Scaling service-linked role ARN of Account B (arn:aws:iam::222222222222:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling) directly into the Principal section of the KMS key policy in Account A, or create a KMS grant for it using the AWS CLI.

Step 3: Share the AMI or Snapshot and Launch the Instance

To boot an EC2 instance using a shared key, you typically share an Amazon Machine Image (AMI) backed by an encrypted root snapshot from Account A to Account B:

  1. Create the AMI with a Customer-Managed Key: Ensure the AMI's root volume snapshot in Account A is encrypted with your customer-managed KMS key (not the default aws/ebs key).
  2. Share the AMI: Modify the AMI's launch permissions in Account A to share it with Account B (222222222222). When you share an AMI through the console or API, AWS automatically shares the underlying EBS snapshots for launch purposes.
  3. Launch the EC2 Instance in Account B:
    • You can launch the instance directly using the shared AMI and leave the root volume encrypted with Account A's KMS key.
    • Alternatively, during launch (via RunInstances), you can specify a new KMS key owned by Account B in the BlockDeviceMappings parameter. Amazon EBS will decrypt the snapshot data using Account A's key and re-encrypt the newly created root volume on the fly using Account B's KMS key.
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --block-device-mappings '[
    {
      "DeviceName": "/dev/xvda",
      "Ebs": {
        "Encrypted": true,
        "KmsKeyId": "arn:aws:kms:us-east-1:111111111111:key/12345678-1234-1234-1234-123456789012"
      }
    }
  ]'

Troubleshooting Immediate Instance Termination

If your EC2 instance enters the pending state and immediately transitions to shutting-down and terminated with a state transition reason of Client.InternalError or Client.UserInitiatedShutdown, KMS permission failure is the most common cause.

Check AWS CloudTrail in both Account A and Account B for CreateGrant, Decrypt, or GenerateDataKeyWithoutPlaintext events with an AccessDenied error code. Common issues include:

  • The KMS key is in a different AWS Region than the EC2 instance (KMS keys are regional resources unless configured as Multi-Region keys).
  • Missing kms:CreateGrant permission in either the KMS key policy or the launching principal's IAM policy.
  • The KMS key in Account A is disabled or pending deletion. If the key is disabled later in Account A, running instances in Account B will continue operating until they are stopped and started again, at which point they will fail to boot.