一个用户（User）可以被想象为一个在职的员工，经常在任，身份户籍也一直固定不变，偶尔会经历身份证明方式（访问凭据）或者职责范围（Permission）的变动。而角色（Role），则更像是一个临时的岗位的头衔，比如管理S3管理者，资源开销审计，安全评估人员，又或者是无所不能老板等，而角色的权限范围也是通过和用户使用的一样的格式的IAM Policy来定义。可以把Role想象成可以复用权限的容器，他会告诉外界这个头衔大概是干什么的，但具体职责可能会在岁月的变迁中不断变化。当一个员工担任起了某个角色，他就可以行使这个角色的特权，当然有时候也会相反带来更多的限制，而这个角色任期可长可短，而且它的身份凭据会时不时更换。
AWS很巧妙的通过将权限通过Policy单独定义为一种资源，而不是将权限直接定义在实体中，这样不光让权限的定义可以复用，并产生了一种十分灵活的权限管理机制。这也让AWS IAM和典型的Role-Based Access Control有些许不同的感觉，这里的Role不再是“贴”在实体上的，而是需要实体来主动“申请”，而且有任期，所以给人一种“临时工”的感觉。比如说，我们现存在一个名为AuditRole的角色，它的权限可以看到所有Account中的资源，我们还有一些其他的用户，像是DevPerl，DevJava，TestCocoa等，但是他们的权限仅局限于自己会用到的资源。那么，如果有一天，DevPerl想要提议使用AWS的某个新服务，但是他没有对于新服务的任何权限，这事该怎么办呢？简单来说，可以让管理员修改DevPerl本身的权限，或者是Dev所在Group的权限来访问新资源，但这样需要管理员同时记得在DevPerl完成了工作后要还原他的权限。有没有一种更智能的方式呢？我们也可以暂时地让DevPerl来担任AuditRole这个角色来暂时地获得对于新服务的访问权限，并在期限结束时自动失去这层权力，这样我们的管理员的工作就少了很多。
到了这里，还有一个环节不是很清晰，那就是为什么DevPerl可以选则担任AuditRole这个Role呢？难道任何用户都可以任意地选则某个角色来临时担任么？这样的话那就乱了套了，IAM也会形同虚设。每一个Role可以定义自己“信任”的实体，即这个Role的Trusted Entities，并在其中的Principal一项里写入可以担任此Role的实体，比如DevPerl的ARN。这种托管行为是可以用在不同的Account之间，即可以暂时获取它人Account的访问权限。