Terraform中AWS IAM Role ID与Role Name的区别及使用时机

• name属性：对应创建IAM角色时显式配置的纯角色名称，是不带任何路径信息的人类可读字符串，比如在资源块里写name = "test_role"，该属性返回值就是"test_role"本身，和IAM API、控制台要求传入的角色名字段格式完全匹配。
• id属性：这个属性的值并不是AWS官方定义的全局唯一IAM角色ID（ARO开头的永久标识），而是Terraform AWS provider自动拼接了角色完整访问路径的角色名称字符串。如果创建角色时没有手动指定非默认的path参数（默认路径为根路径"/"），id的返回值会和name完全一致——这也是部分团队用id写法可以正常跑通的根本原因。

当创建IAM角色时手动配置了非默认路径，比如path = "/ecs/task-roles/"，此时id属性的返回值会变成"/ecs/task-roles/my-test-role"这种带全路径的字符串。而aws_iam_role_policy资源的role参数，API层面要求只传入不带路径的纯角色名，一旦把带路径的id值传入，就会触发角色找不到、策略关联失败的问题。
这里需要纠正常见的认知偏差：AWS官方定义的全局唯一IAM角色ID（ARO开头的字符串），在Terraform的aws_iam_role资源中是挂载在arn属性下的独立字段，和资源顶层的id属性完全没有关联，千万不要混淆概念。

• 优先选择name的场景：所有需要关联IAM策略、绑定EC2实例配置文件、传给IAM相关API作为角色标识的场景，直接传入aws_iam_role.xxx.name是最稳妥的写法，不受角色创建时自定义路径的影响，完全匹配API的参数格式要求，能从根源上避免偶发报错。
• 可以兼容使用id的场景：只有当项目中所有IAM角色都使用默认根路径、没有自定义非根路径的配置时，id和name值完全等价，此时两种写法的运行效果没有区别。但从项目可维护性角度，不推荐这种写法——后续如果调整角色的路径配置，就会直接触发无预期的运行报错。

很多人踩坑的根源就是误以为Terraform资源的顶层id一定是全局唯一的资源标识，实际上IAM相关资源的id字段的设计本身就和大家的默认认知有差异，写配置时优先传name字段能省掉很多排查时间。

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