已绑定IAM角色的EC2实例能否执行STS AssumeRole获取S3访问权限

STS AssumeRole 的本质是依托已有的可信身份，生成一套权限范围独立的临时安全凭证。这套临时凭证和初始使用的基础身份属于完全独立的两套权限体系，不存在“单资源只能绑定一套身份”的冲突限制。

完全可以。
EC2实例附加的IAM角色，本身就是一套可正常发起AWS API调用的有效身份，这套身份完全可以作为调用AssumeRole接口的主身份——只要主身份被纳入目标角色的信任策略白名单，就能顺利完成AssumeRole流程，和实例已经绑定了角色这件事没有任何冲突。
需要明确的常见认知误区：大家常说的“EC2无法同时承担两个IAM角色”，指的是EC2实例元数据服务层面，同一台实例同一时间只能关联一套实例配置角色，和业务代码里主动调用AssumeRole获取额外临时凭证的逻辑完全无关，后者没有任何可获取的临时角色数量限制。

你描述的高频DynamoDB调用、低频S3调用的场景，完全可以通过AssumeRole实现权限隔离，根本不需要修改现有EC2绑定的、仅用于DynamoDB访问的IAM角色。
具体实现路径：

• 保留现有EC2实例绑定的IAM角色原有配置，不新增任何S3访问权限，继续为每秒数百次的DynamoDB请求提供身份凭证
• 新建一个专门用于S3访问的IAM角色，给该角色配置最小范围的S3访问权限，同时将角色的信任策略设置为：允许当前EC2绑定的DynamoDB角色作为可信调用方，完成AssumeRole的身份校验
• 业务逻辑层面，高频DynamoDB请求直接使用EC2元数据服务获取的原有角色凭证发起；低频S3请求，单独通过AssumeRole获取对应S3角色的临时凭证发起即可

实操层面的注意事项：

• 调用AssumeRole获取的临时凭证最长有效期可达12小时，可在代码中缓存拿到的临时凭证，等凭证临近过期时再重新拉取，不需要每次发起S3请求都调用一次AssumeRole，不会带来额外性能开销
• 这种权限分离的设计符合AWS安全最佳实践：可以做到不同业务模块的权限完全隔离，避免单一角色权限过大带来的安全风险，且完全不需要改动现有生产环境的角色配置

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