亚马逊云代付 AWS STS 获取临时凭证（AssumeRole）报 AccessDenied 的权限边界排查
这类报错，用户最常见的第一反应是“我已经给了 IAM 权限，为什么还是拒绝”。实际排查里，真正卡住的往往不是 STS 本身，而是权限边界、信任策略、组织 SCP、账号风控状态叠在一起之后，表面看起来都像 AccessDenied。
如果你现在正卡在 AssumeRole，建议先不要反复改配置。很多人一边改 policy，一边把问题绕得更复杂：有的账号是新开通的，支付方式还没通过验证；有的企业账号还在风控审核；有的角色权限边界写得太保守；还有的目标角色信任策略只信任了 root，没放行实际调用的 IAM 用户或角色。下面按真实排查顺序讲。
先判断：这次拒绝到底是谁拦的
AssumeRole 报 AccessDenied，通常只看三处就能定位 80% 的问题：
- 调用方有没有权限：当前 IAM 用户或角色是否显式允许
sts:AssumeRole - 亚马逊云代付 权限边界有没有放行：即使身份策略允许，边界没放行也会被挡住
- 目标角色信任策略有没有接受你：Trust Policy 里有没有你的账号、用户、角色 ARN
很多人只盯着“我给了 IAM FullAccess”，但忽略了权限边界这一层。边界的实际效果很直接：身份策略允许不等于最终允许。如果边界里没有放行 sts:AssumeRole，或者没允许目标角色 ARN，即使你在 IAM 里手工加了允许，也一样会被拒。
最常见的 4 种失败场景
| 现象 | 更可能的原因 | 现场怎么改 |
|---|---|---|
| 调用方报 AccessDenied | 身份策略没放行 sts:AssumeRole | 给调用方补 sts:AssumeRole，并确认资源 ARN 写对 |
| 身份策略已放行，还是失败 | 权限边界没放行 | 检查 boundary 是否包含目标 role ARN，必要时临时放宽测试 |
| 只有某个角色能跳，其他不行 | 目标角色信任策略只信任了部分主体 | 把实际调用的 IAM role/user ARN 加进 trust policy |
| 同一套配置在某账号能用，另一个账号不能用 | 组织 SCP、账号状态、MFA、ExternalId 条件不一致 | 按账号维度检查 Organizations、MFA、条件键 |
权限边界怎么把你“卡死”的
权限边界最容易让人误判，因为它不是显性报错“boundary denied”，而是直接表现成 AccessDenied。实操里我最常见到两种写法问题：
- 边界只写了通配，但没覆盖目标角色 ARN。比如允许了某个账户下的部分服务，但没包含跨账号角色。
- 边界里有显式 Deny。很多企业为了控风险，会把
sts:AssumeRole、iam:PassRole、iam:CreateRole一起禁掉，后面业务上线再去追权限，就会发现“怎么加都不行”。
排查时别只看当前用户的 policy，要把身份策略 + 权限边界 + 组织 SCP放在一起看。三者里任何一个没过，最终都会拒绝。实际操作上，我建议先临时做一个最小测试：
- 给测试调用方单独挂一条仅允许目标 role 的
sts:AssumeRole - 确认 boundary 里同样放行这条动作
- 信任策略里只加入这个测试主体
这样做的好处是能快速判断问题到底在“调用方权限”还是“目标角色信任”。不要一上来就放宽成 *，那样虽然能通，但后面很难收回来。
很多人忽略的：AWS 账号状态也会影响排查效率
如果你的账号是刚开通的国际站 AWS 账号，或者是通过代理、代注册、企业代开方式创建的，先确认账号本身没有被风控。真实场景里，有些账号表面能登录，但 Billing、IAM、STS、EC2 的可用范围并不完全一致。尤其是以下几种情况：
- 实名认证/企业信息未补齐：部分区域或后续审核会要求补资料，短期内会影响部分操作
- 支付方式未通过验证：信用卡小额验证失败、账单地址不一致、预付卡不可用，都可能触发风控
- 充值/扣费失败：欠费或扣款失败后，部分账号会进入限制状态，排查权限时会出现“配置都对，但就是不正常”
- 新账号行为过密：刚开通就频繁创建角色、跨账号切换、开多个区域服务，容易触发风控审查
这类问题和 STS 权限不是一回事，但在现场经常一起出现。比如你去改 trust policy 时发现控制台某些页面加载异常，或者 API 频繁 403，这时先看账单和账号状态，比盲改权限更省时间。
支付方式、续费和风控：为什么会影响权限排查
AWS 的访问控制看起来是 IAM 问题，但在新账号和低信用账号上，支付信息经常是底层前置条件。比较常见的差异是：
- 信用卡：验证速度快，但账单地址、国家地区、发卡行风控都可能影响开通结果
- 借记卡/预付卡：有些能绑，有些会被拒，尤其是自动扣费场景稳定性差
- 企业付款方式：资料齐全通常更稳，但审核周期更长，且后续变更要保留一致性
如果账号因为续费失败或付款失败进入限制状态，用户会误以为是 AssumeRole 配错。实际排查时建议同步看 Billing 页面、付款历史、发卡行扣款记录。我的经验是：新账号一旦出现 billing hold，先解决账单状态，再看 IAM，否则改权限会白忙。
按优先级排查：5 分钟内先做什么
- 确认调用方 ARN，别拿 root 或别的角色当成当前主体
- 看当前主体是否有
sts:AssumeRole的显式允许 - 检查权限边界是否同样允许该动作和目标 role ARN
- 查看目标角色 trust policy 是否信任了当前主体
- 核对是否有 SCP、MFA、ExternalId、SourceIp 条件
- 确认账号没有 billing hold、风控限制或区域级服务限制
如果你只能改一处来验证问题，优先改目标角色信任策略和调用方权限边界。这两处最容易导致“看上去都对，实际上没放行”。
不同修复方式的成本对比
| 方案 | 改动成本 | 风险 | 适合什么场景 |
|---|---|---|---|
| 只补调用方 IAM policy | 低 | 容易误判，若 boundary 没改仍失败 | 初步验证权限缺失 |
| 同步调整权限边界 | 中 | 放宽过大可能扩大权限面 | 企业统一管控、多人共用账号 |
| 修改 trust policy | 低到中 | 信任主体过多会增加横向访问风险 | 跨账号访问、角色切换 |
| 新建测试角色隔离验证 | 中 | 多一个角色维护成本 | 复杂组织、SCP 多层叠加 |
从成本看，先建一个最小权限测试角色通常比在生产角色上反复试错更省钱。因为一旦改错 trust policy，带来的不只是访问失败，还有审计噪音和回滚成本。
实战里最容易踩的配置坑
- 资源 ARN 写错：把目标角色 ARN 里账号 ID、路径名、角色名写偏一点，都会直接失败
- 亚马逊云代付 只放行了 sts:AssumeRole，没有放行角色链路：如果你是从 A role 再跳到 B role，链路里每一跳都要过
- Trust policy 只写了账户，没有写具体主体：账号内主体很多，结果你以为都能跳，实际条件限制卡住
- 边界里有条件键限制：例如必须带 MFA，或者必须来自固定 IP 段
- 组织 SCP 统一禁了跨账号访问：本地看 policy 没问题，组织层一刀切拒绝
FAQ：用户最常问的几个问题
Q1：我已经给了 AdministratorAccess，为什么还报 AccessDenied？
A：先看权限边界和 SCP。AdministratorAccess 只是身份策略层面的“看起来很大”，边界和组织策略照样能拦。
Q2：权限边界和信任策略，先改哪个？
A：先改信任策略做最小验证，再看边界。信任策略不通过，边界放行也没用；边界不通过，信任放行也会失败。
Q3：新开通的 AWS 账号，为什么 IAM 都配好了还是不稳定？
A：很多是账号状态问题，不是纯权限问题。支付方式验证、风控审核、欠费、资料不完整，都会让你在控制台或 API 上碰到看似权限错误的现象。
Q4：跨账号 AssumeRole 需要注意什么？
A：除了双方 IAM 和 trust policy，还要确认组织 SCP、ExternalId、MFA 条件、以及目标账号是否允许这个主体来源。跨账号问题不是“加一条 allow”就结束了。
最后给一个现场判断原则
如果你手上这个 AccessDenied 是“最近刚发生”，优先看三件事：有没有改过权限边界、有没有换过账号支付信息、有没有触发组织或风控限制。如果是“新账号一直不通”，优先看认证、账单、信任策略。如果是“某个角色偶发失败”，优先看条件键和 SCP。
真正省时间的做法，不是把所有 policy 都拉满，而是先把“谁在拦你”找出来。找到拦截层，AssumeRole 的 AccessDenied 基本都能落到一处修掉。
