这个场景将围绕一个在线教育平台 展开，它巧妙地融合了AWS的IAM角色、STS服务以及临时安全凭证（AK/SK/Session Token）的核心概念。我们将使用搜索结果中提到的跨账户授权、STS获取临时凭证以及凭证使用等关键环节。
教学场景：多租户在线教育平台的课件存储与分发
故事背景：
“智慧学”是一家在线教育平台公司。公司有两个AWS账户：
账户A（生产账户）：存放着平台所有核心数据，特别是包含大量视频、PPT课件的S3存储桶 (
wisdom-learn-course-bucket)。账户B（开发/分发账户）：运行着面向学生和老师的应用程序服务器（EC2实例）。这个账户本身没有直接访问账户A中S3的权限。
业务需求：
当学生通过账户B中的应用程序点播课程视频时，应用需要能够安全、实时地从账户A的S3存储桶中获取视频文件流。我们不能在应用代码里硬编码长期有效的AK/SK，因为那有泄露风险。
解决方案：
采用 “基于IAM角色的跨账户临时凭证访问” 模式。整个过程就像一个精密的“凭证传递接力赛”。
架构图与分步流程解析
下图清晰地展示了整个访问链条：
分步讲解（对应架构图编号）：
学生发起请求：学生在“智慧学”App或网页上点击播放一个课程视频。
应用准备授权：运行在账户B的EC2实例上的应用程序接收到请求。为了访问视频，它需要先获得授权。应用程序配置了账户B中一个IAM用户的长期AK/SK，但这个用户权限很有限，仅被允许做一件事：向AWS安全令牌服务（STS）请求扮演（Assume）某个特定角色。
请求临时凭证：应用程序使用其配置的长期AK/SK，调用STS服务的
AssumeRoleAPI。这个请求的核心是告诉STS：“我请求扮演账户A中那个名为CourseAccessRole的角色”。STS颁发门票：STS服务收到请求后，会进行严格验证：
检查请求者（账户B的IAM用户）是否有
AssumeRole权限。检查账户A的
CourseAccessRole角色的信任策略是否允许被账户B的该用户扮演。验证通过后，STS会动态生成一组临时安全凭证，包括：
AccessKeyId（临时AK）、SecretAccessKey（临时SK）和至关重要的SessionToken。这组凭证有效期最长为12小时。请注意：这个
SessionToken是临时凭证有效性的证明，必须和临时AK/SK一起使用。
使用临时凭证访问资源：应用程序拿到这组“临时门票”后，立即使用它们来初始化一个新的AWS SDK客户端（如S3客户端）。随后，它使用这个客户端直接向账户A的
wisdom-learn-course-bucket发起请求，获取对应的视频文件。S3返回数据：账户A的S3服务收到请求。它会检查请求所携带的临时凭证（AK/SK+Token）。由于这组凭证是通过STS扮演
CourseAccessRole角色获得的，而该角色附加了访问S3的策略，因此S3认为请求者是合法的，遂将视频数据流返回给应用程序。应用分发内容：应用程序将收到的视频流处理并分发给请求的学生客户端，完成一次完整的视频点播。
场景设计的教学亮点
现实映射：将抽象的“账户A”、“账户B”具体化为“生产账户”和“开发账户”，符合企业常见的多账户安全隔离实践。
安全演进：清晰地对比了“不安全的长期AK/SK硬编码”与“安全的临时凭证动态获取”两种方式，突出STS和IAM角色的价值——无需分发或嵌入长期凭证，降低泄露风险，且凭证自动过期。
核心概念串联：一个流程串联了 IAM用户、IAM角色、信任策略、STS、AssumeRole、临时AK/SK、Session Token 等所有关键知识点，展示了它们如何协同工作。
动态与临时性：强调临时凭证的“有效期”概念，就像一张限时有效的门票，过期作废，比长期有效的“门禁卡”（长期AK/SK）更安全。
架构可视化：通过架构图，学生可以直观地看到请求流、凭证流和数据流在跨账户环境中的走向，理解各个AWS服务（IAM, STS, S3）在其中的位置和作用。
