AWS EC2实例中/var/lib/cloud/instances下多实例ID文件夹的原因及关联

这事儿其实挺常见的，我来给你理清楚背后的原因和它们的关联：

核心原因：两个文件夹的由来 #

/var/lib/cloud/instances是cloud-init的核心工作目录，它负责存储实例初始化的配置、日志和运行状态。出现两个不同实例ID的文件夹，大概率是以下两种情况之一：

1. 自定义AMI带来的残留数据 #

如果你的EC2实例是从自定义AMI启动的，而这个AMI是基于另一个EC2实例创建的，那么源实例的cloud-init工作文件夹（也就是那个旧的实例ID目录）会被打包进AMI镜像里。当新实例启动时，cloud-init会自动为当前实例创建一个新的、对应当前实例ID的文件夹，这样就会同时存在新旧两个目录。

2. 实例停止重启后的宿主机调度（少见但可能） #

AWS的EC2实例停止后再启动，有时候会被调度到不同的物理宿主机上。极少数情况下，cloud-init会保留之前在旧宿主机上的实例记录文件夹，同时为新的宿主机调度创建新的目录——不过这种情况里，旧文件夹的实例ID其实和当前实例ID是一致的，你遇到的是不同ID的话，更可能是第一种情况。

两个文件夹的关联与作用 #

• 当前实例ID对应的文件夹：这是正在被cloud-init使用的工作目录，里面存储着当前实例的user_data执行日志、初始化状态、配置脚本等关键数据，是实例正常运行时cloud-init依赖的目录。
• 旧实例ID对应的文件夹：这是从源AMI继承来的残留数据，里面的内容属于之前的那个实例，对当前实例没有任何作用，只是镜像打包时带过来的“遗留文件”。

验证与清理建议 #

你可以先确认当前实例的真实ID，运行下面的命令：

curl http://169.254.169.254/latest/meta-data/instance-id

对比输出的ID和文件夹名称，和当前ID匹配的就是正在使用的目录。

如果确认旧文件夹是残留数据，完全可以安全删除它，不会影响当前实例的运行——cloud-init已经在使用新的目录了。

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