使用AWS::CloudFormation::Init对比直接写入UserData块的优势探讨

阿华AIGC实验室

2026-5-12

AWS::CloudFormation::Init vs 直接写 UserData：优势与痛点解析

你提的这个问题太接地气了——我刚用CloudFormation的时候也吐槽过Init的写法太啰嗦，明明几行bash就能搞定的事，非要拆成一堆配置块。但用得多了才发现，它的优势在复杂场景下会被无限放大，下面结合我自己的实践给你掰扯清楚：

核心优势

1. 配置结构化，维护成本直线下降

UserData本质就是把一堆脚本堆在一起，时间长了很容易变成“祖传代码”：比如你要修改某个配置文件的内容，得在几十行bash里找对应的echo或sed命令，稍不留神就改错。
而Init把配置拆成了files、commands、packages、services等独立模块，每个模块负责单一职责：比如安装依赖找packages块，写配置文件找files块，启动服务找services块。结构清晰到新人接手也能快速定位修改点。

2. 内置依赖与执行顺序控制，不用自己造轮子

你提到用多个configSet来控顺序，其实Init的dependsOn属性能更精准地处理依赖：比如你可以指定“启动Nginx服务”这个步骤必须依赖“安装Nginx包”和“写入配置文件”两个步骤完成，不用在UserData里写一堆sleep或者手动检查进程的逻辑。
另外，Init自带重试机制——如果某个步骤（比如安装包时网络波动）失败，它会自动重试，而UserData脚本默认是失败了就硬往下走，你得自己写重试逻辑，容易漏坑。

3. 动态配置更省心，少写替换占位符的代码

Init可以直接引用CloudFormation的参数、资源属性，不用在UserData里用sed替换占位符。比如你要把数据库端点写入配置文件，用Init只需要：

files:
  /etc/nginx/conf.d/db.conf:
    content: |
      proxy_pass http://!Ref DBInstanceEndpoint;
    mode: '000644'

而用UserData得写：

echo "proxy_pass http://${DBInstanceEndpoint};" > /etc/nginx/conf.d/db.conf

看起来差不大，但配置复杂的时候，Init的写法能避免大量字符串替换的错误。

4. 日志与状态追踪更清晰，排障快十倍

Init的执行日志单独存在/var/log/cfn-init.log里，每个配置块的执行结果、错误信息都有详细记录，出问题直接搜这个日志就行。而UserData的日志混在/var/log/cloud-init.log里，要找问题得翻一大堆无关内容。
更重要的是，你可以用cfn-signal配合Init，让CloudFormation知道实例初始化是否成功——如果Init执行失败，栈会直接进入ROLLBACK状态，你能第一时间发现问题；而UserData脚本失败的话，栈可能显示CREATE_COMPLETE，但实例其实没配置好，等出问题才发现就晚了。

5. 可复用性更强，避免复制粘贴

你可以把常用的Init配置做成嵌套栈或者宏，在多个模板里复用；而UserData脚本通常是每个实例写一遍，复制粘贴容易带出旧配置的问题。比如我把“配置Nginx反向代理”的Init块做成嵌套栈，每次需要的时候直接引用就行，不用重复写一堆配置。

关于你提到的痛点

写法冗长？

确实，简单场景下Init的写法比UserData繁琐，但随着配置复杂度提升，这种“冗长”带来的维护成本降低会越来越明显。另外，你可以用YAML的锚点&和引用*来复用重复配置，比如多个config块都需要相同的命令，定义一次就能重复用，能省不少代码。

需要额外安装cfn-init？

现在大部分AWS官方AMI（比如Amazon Linux 2、Ubuntu官方AMI）都预装了aws-cfn-bootstrap包（包含cfn-init、cfn-signal），不用额外安装。如果是自定义AMI，你可以把这个包提前打包进去，或者在UserData里先执行安装命令（比如Amazon Linux用yum install -y aws-cfn-bootstrap），虽然多一步，但后续的配置收益绝对值得。