一文讲透AWS的IAM

理解 IAM（Identity and Access Management）里的 Policy、User、Role、Group 之间的关系，可以用一个通俗的比喻来帮你构建直觉理解：

---

类比：公司大楼的门禁系统

想象你是某家公司的 IT 管理员，需要设置员工进入哪些办公室、能使用哪些设备：

---

User（用户） = 公司员工个人

每一个 User 就是一个具体的人，比如“张三”“李四”，他们需要自己的门禁卡来刷卡进门、使用电脑等。

• AWS 里的 User 就是具体的账号，比如你的开发人员、测试人员。

---

Group（用户组） = 部门

公司有很多部门，比如“开发部”“测试部”“财务部”。一个人可以在某个部门，也可以在多个部门（比如兼任开发和安全）。

• AWS 里的 Group 是一堆用户的集合，你可以给整个组分配权限。
• 举个例子：你把“开发权限”Policy 给“开发部”这个 Group，那么组里的每个 User 自动就有这些权限。

---

Policy（策略） = 门禁卡权限说明

Policy 就是一张权限清单，比如：

• 允许访问 S3 某个桶
• 拒绝删除 EC2 实例
• 允许只读 DynamoDB 表

你可以把 Policy 贴在：

• 用户身上（User）
• 用户组（Group）
• 角色（Role）

---

Role（角色） = 外包人员临时工/机器人账号

Role 就像是一个“身份外衣”：

• 有些时候，不是公司正式员工来访问系统，而是：

  • 外包人员来临时支援
  • 一个 AWS 服务（比如 Lambda）来访问其他服务
  • 另一个 AWS 账号的用户

这些情况不能直接建 User，而是要让他们“扮演”某个角色 —— Role。

• Role 没有用户名和密码，它靠“被谁扮演”（Assume Role）来访问。
• 举个例子：Lambda 函数调用 S3 时就会 Assume 一个有 S3 访问权限的 Role。

---

总结一下（表格版）

概念	类比	说明
User	员工个人	有唯一身份，可以登录控制台
Group	部门	把一堆 User 分组，统一授予权限
Policy	门禁权限清单	写清楚谁能干什么，贴在谁身上都行
Role	临时身份/机器人	没有固定人，谁来就穿这个身份做事

---

实战例子

你公司在 AWS 上做项目，需求如下：

• 张三是开发人员，可以访问开发用的 EC2 和 S3；
• 李四是测试人员，只能读 S3 里的数据；
• Jenkins（CI 工具）要上传构建产物到 S3。

那么你的 IAM 设计可能是：

1. 创建 User 张三和李四；
2. 创建 Group Developers 和 Testers，分别绑定对应的 Policy；
3. 张三加入 Developers，李四加入 Testers；
4. 创建一个 Role CIUploadRole，绑定上传 S3 的权限；
5. Jenkins 运行时 Assume 这个 Role。