CloudFormation中Fn::ImportValue短格式嵌套Fn::Sub报错排查

该报错并非短标记格式与Fn::Sub嵌套存在兼容问题，本质是YAML短标签解析规则与CloudFormation内置函数参数要求不匹配导致：

• YAML语法中，!开头的CloudFormation短标记后如果紧跟方括号[]，解析器会默认将方括号包裹的内容识别为数组（序列）类型，作为入参传递给对应内置函数。
• 问题写法中的!ImportValue [!Sub "..."]结构，最终会被解析为{"Fn::ImportValue": [{"Fn::Sub": "xxx"}]}：即传给Fn::ImportValue的入参是长度为1的数组，而非单个字符串或返回字符串的内置函数。
• Fn::ImportValue的参数规范明确要求入参必须为字符串，或是可返回字符串的内置函数，不接受数组类型入参，因此触发参数类型不匹配的报错。

给出的长格式可运行写法Fn::ImportValue: !Sub "xxx"，解析后结构为{"Fn::ImportValue": {"Fn::Sub": "xxx"}}，完全符合参数要求，因此可正常执行。

• 按内置函数的参数类型选择短标记写法：
  • 仅!Join、!Select、!Split这类本身需要接收多值/列表类型入参的内置函数，短标记后才需要搭配方括号传递参数。
  • !ImportValue、!Sub、!Ref、!Base64这类仅接收单个入参的内置函数，短标记后直接传入参数即可，无需额外包裹方括号。
• 短标记嵌套单参数函数时直接顺写即可，不需要额外包裹符号：短格式下!ImportValue嵌套!Sub的合法写法为!ImportValue !Sub "${ProductEnvironment}-${ProductName}-IngressGreengrassProxyFunctionArn"，该写法解析后的结构与长格式完全一致，不存在兼容问题，可正常运行。
• 多层函数嵌套、模板逻辑复杂度较高的场景，优先使用Fn::xxx的长格式书写，避免YAML标签解析歧义，同时提升模板可读性。

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