如何通过CloudFormation创建带加密启动卷的EC2实例？

当然可行！不过你之前遇到的报错是踩了AWS的一个规则：当你的AMI是基于快照创建的时候，不能直接在Launch Configuration的BlockDeviceMappings里给根卷指定Encrypted: true——AWS不允许你直接修改由AMI快照派生的卷的加密状态，得换个正确的姿势来做。

最直接的解决方案：使用预先加密的自定义AMI #

这其实就是你手动流程的Cloud适配版，把加密AMI的准备工作提前完成，再在CloudFormation里直接引用即可：

1. 按照你熟悉的步骤创建加密的自定义Windows AMI：
   • 从原基础AMI启动实例
   • 创建根卷快照
   • 加密复制该快照
   • 基于加密快照生成新的自定义AMI
   • 清理临时资源
2. 记录这个加密AMI的ImageId
3. 修改CloudFormation模板：
   • 把原来ImageId: { "Ref": "WindowsImage" }里的WindowsImage参数替换为加密AMI的ID，或者在部署模板时传入加密AMI的ID作为参数值
4. 保留（或移除）原来的BlockDeviceMappings配置——因为加密AMI的根卷已经是加密状态，实例启动时会自动继承这个属性，不需要额外指定Encrypted: true

这样修改后，你的Launch Configuration创建的实例就会自动使用加密的启动卷，也不会再触发之前的报错。

进阶方案：用CloudFormation自动生成加密AMI（全流程自动化） #

如果不想手动提前创建加密AMI，想要让CloudFormation栈部署时自动完成加密AMI的生成，可以通过自定义资源+Lambda函数实现：

1. 编写一个Lambda函数，逻辑如下：
   • 接收原AMI ID作为输入参数
   • 从原AMI创建根卷快照
   • 加密复制该快照（可指定KMS密钥，默认用AWS管理密钥即可）
   • 基于加密快照创建新的自定义AMI
   • 返回新AMI的ID给CloudFormation
2. 在CloudFormation模板中定义一个自定义资源，调用这个Lambda函数，传入原WindowsImage的ID
3. 修改Launch Configuration的ImageId，引用自定义资源返回的加密AMI ID
4. 添加清理逻辑：当CloudFormation栈删除时，让Lambda函数自动删除生成的AMI和快照（避免残留资源）

这个方案实现了全流程自动化，但需要处理Lambda的IAM权限（比如允许创建快照、AMI，访问KMS等），相对复杂一些，适合需要频繁更换基础AMI且要求全自动化的场景。

为什么之前的修改会报错？ #

再回头解释下你遇到的错误：the encrypted flag cannot be specified since device /dev/sda1 has a snapshot specified——你的原Windows AMI本身是基于某个快照创建的，根卷的设备映射已经关联了该快照。当你在Launch Config里强行指定Encrypted: true时，相当于要求AWS基于原快照创建一个加密卷，但AWS不允许直接修改现有快照派生卷的加密状态，必须通过“加密复制快照→创建新AMI”的流程来实现。

内容的提问来源于stack exchange，提问作者Kappacake