Error: unknown configuration key: "encrypted" (Packer amazon-ebs)

Error: unknown configuration key: "encrypted" (Packer amazon-ebs)

TL;DR

encrypted is not a builder-level key. Move it (and volume_size, volume_type, delete_on_termination) inside an ami_block_device_mappings block.

The error

Build 'amazon-ebs' prepare failure: 1 error(s) occurred:

* unknown configuration key: "encrypted"

Fix it

1. Remove "encrypted": true (and any sibling volume keys) from the builder top level.

• Success check: no volume keys at the builder root.

1. Add them inside a block device mapping:

   ami_block_device_mappings {
     device_name = "/dev/sda1"
     volume_size = 20
     volume_type = "gp3"
     encrypted   = true
     delete_on_termination = true
   }

• Success check: the keys sit inside the mapping block.

1. Run packer validate.

• Success check: validation passes.

1. Re-run packer build.

• Success check: the AMI is created encrypted.

When to use this

You hit this on packer validate with volume/encryption keys at the builder top level.

When NOT to use this

Do not use this for KMS key errors (kms_key_id rejected) or for encryption failing at AMI creation. This is specifically the misplaced key.

Compatibility

Packer 1.x, amazon-ebs (JSON and HCL).

Variants

• unknown configuration key: "delete_on_termination", "volume_size", "volume_type" (same misplacement)
• The same nesting rule for launch_block_device_mappings (instance volumes) vs ami_block_device_mappings (AMI volumes)

Root cause

Volume options belong to block device mappings, not the builder. The docs list them under the mapping blocks, but the flat JSON layout makes the top level tempting.

Edge cases

• encrypted on the launch mapping encrypts the build instance's volumes; on the AMI mapping it encrypts the resulting AMI. Pick the right one.
• For KMS, add kms_key_id inside the same mapping block.