从什么是account（账户）user（用户）role（角色）说起
aws提供的云服务要通过订阅的方式租用并且计费。而aws账户就是所有订阅，计费，云服务的一个独立空间，在这个空间中的所有资源都可以由账户随意调配。
容易混淆的是用户和角色：
用户主要针对的是具体的人或者组织或者应用程序，有固定的认证方式。
而角色可以理解为是一系列权限的集合。相比之下角色被认为是一种短期的，灵活的认证。并且角色可以实现跨账户访问。
🌰栗子
把账号类比于一个公司，公司中有各种资源 ，公司是一个独立的空间 ，公司可以分配拥有的资源。
登录到公司人事部的每一个具体的 员工都是一个用户，有固定的认证方式（比如员工牌）。
角色就是岗位，具体的人分配到不同的岗位上就会扮演不同的角色，角色是一系列权限的集合，一个员工业绩好分配到了项目经理的位置上，就具有了项目经理的权限，过了两个月因为业绩太差被分配到端茶倒水的位置上，就失去了项目经理的权限，只保留了端茶送水的权限，所以同一个员工（工牌号9527），同一个人，因为在不同的岗位上扮演不同的角色，相对应的权限也会发生变化。
最后跨账户访问，也就是跨公司访问的情况：A公司的员工9527，哪怕是项目经理，也无法进入B公司去使用项目经理的权限。也就是说员工9527，他是属于A公司的员工（A账户的用户），无法执行B公司的权限（没有B账户的权限），也无权访问B公司的文件（无权访问账户B的资源）。
但是假设B公司创建了一个岗位（B账号创建了一个角色），这个岗位需要其他公司派来一个苦逼的外包程序员（允许A账号的用户扮演B账号的角色），允许使用B公司的电脑，键盘，鼠标（一部分权限），但是不能吃B公司的零食。
这时候A公司的员工9527，虽然仍然归属于A公司，却可以在B公司扮演角色，明明是A公司的员工，获得了在B公司使用一部分权限的能力。
员工9527在A公司扮演现场工程师，在B公司扮演外包程序员（就是在下了）
这就是assume role。
写成policy
由于是B公司开通的岗位，所以应该在B公司上面开放权限，A公司的员工来不来是A公司的事情。
{
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:: A公司 : 现场工程师 / 外包程序员 "
},
"Action": "sts:AssumeRole"
}
]
}