mongodb atlas 支持 aws iam 角色认证，但仅限 m10+ 集群、启用 iam 身份提供商的区域，需严格配置 identity provider（arn 和 audience 匹配）、角色信任策略含 https://identity.mongodb.com/oidc、连接字符串不含密码且指定 authmechanism=mongodb-aws，并确保运行环境具备有效 aws 凭证。
云数据库 MongoDB 不支持直接配置 IAM 权限
MongoDB Atlas 和大多数云厂商托管的 MongoDB 服务（如阿里云、腾讯云、华为云）**不使用 AWS IAM 或通用云 IAM 体系管理数据库访问权限**。它们各自封装了独立的数据库用户与角色模型，IAM 只用于控制「谁可以操作数据库实例本身」（比如重启、扩缩容、修改配置），而非「谁可以连上 mongosh 执行 db.find()」。
常见误解是以为给云账号 IAM 用户绑上 ReadOnlyAccess 就能读取数据库内容——实际完全无效。数据库连接层的认证授权仍走 MongoDB 原生机制。
Atlas 中的数据库用户 ≠ Atlas 平台用户
在 MongoDB Atlas 控制台里，你看到的「Database Access」页面管理的是 数据库连接凭证，而「Organization Access」或「Project Access」页管理的是 平台操作权限（即类似 IAM 的角色）。两者完全隔离：
-
Project Reader角色允许查看 Atlas 项目配置，但无法创建数据库用户，也不能执行任何mongosh命令 - 你在「Database Access」里创建的用户（如
app-user），其密码和角色只作用于mongodb+srv://...连接串后的数据库，与 Atlas 平台权限无关 - 即使一个 IAM 用户（或 Atlas 组织成员）没有任何 Project 权限，只要拿到有效的数据库用户名/密码 + 连接地址，照样能连库查数据
正确配置数据库访问：用 Atlas 内置角色而非 IAM 策略
Atlas 提供预定义的数据库角色（如 atlasAdmin、readAnyDatabase、readWrite），全部在「Database Access」页配置。关键点：
- 角色绑定到具体数据库（
db: "myapp"）或全局（db: "admin"），不能用 IAM 策略模拟这种细粒度控制 - 网络白名单必须单独设置（IP Access List），它和角色权限是正交的——即使用户有
readWrite，若 IP 不在白名单里，连接直接被拒绝，连认证环节都进不去 - 启用 MFA 或 LDAP 集成时，底层仍是 Atlas 自己的认证流程，只是把密码验证委托给外部系统，权限分配逻辑不变
自建 MongoDB + 云 IAM 的混合场景要特别小心
如果你在 ECS 或 EC2 上自己部署 MongoDB，并希望通过云 IAM 控制访问，这条路基本走不通。MongoDB 本身不解析 IAM token，也没有官方插件支持。可行路径只有两种：
- 用云厂商提供的「数据库代理」（如阿里云 DMS、AWS RDS Proxy），它能做 IAM 身份转换，但仅支持部分引擎（RDS MySQL/PostgreSQL），不支持自建 MongoDB
- 在应用层做中转：应用服务用 IAM Role 获取临时凭证 → 调用密钥管理服务（如 KMS）解密数据库密码 → 再用该密码连接 MongoDB。这本质是绕过，不是真正的 IAM 授权
真正容易被忽略的是：很多人把云防火墙规则、VPC 安全组、Atlas IP 白名单、MongoDB 用户角色这四层权限混为一谈，调错其中一层就会导致「连不上」或「连得上但查不到」，排查时得一层层确认，不能默认它们联动。
