はじめに

SCSの学習でIAMの奥深さに感動した勢いのまま書く。
注意：個人的な解釈であって絶対的に正しいものではない。
また、個人の責任において記載しているが抜け漏れや間違いがある可能性はあることを理解の上で読んで頂きたい。
正確な解釈は公式ドキュメントのポリシーとアクセス許可を参照。
とはいえこんな長ったるいの読んでられねえし、他ブログ記事の内容も個人的にいまいち腑落ちしなかったため書き残すことにした。

結論

面倒なんで 許可 前提で書く。

• 当たり前だがサービスが違う。(STSとIAM)
• 書く場所が違う。
  iam:PassRoleは基本的にアイデンティティベースのポリシーに記載する。
  sts:AssumeRoleはリソースベースのポリシーに記載する。
  後で補足する。
  
• アクションの内容が違う。
  iam:PassRoleは あるIAMRoleをEC2インスタンスやLambda関数などのリソースに設定することを許可 する。
  IAMユーザーに紐付けたIAMポリシーでiam:PassRoleを許可した場合は、そのユーザーがIAMRoleをEC2インスタンスなどに設定できるようになる。
  IAMRoleでiam:PassRoleを許可するケースは、具体的にはConfig自動修復 -> SSM Automation -> Lambda関数の連携でConfig Ruleの設定にて使われる。（Use IAM to configure roles for Automation）
  sts:AssumeRoleは Principalに記載したサービスあるいはアカウント・ユーザーなどに、 そのIAMRoleのアイデンティティベースのポリシーで許可されたアクションを同じように許可 する。
  クロスアカウントアクセスRoleでよくある奴。
  

補足

IAMRoleにおけるアイデンティティベースのポリシー

そのIAMRoleに主に 何の アクションを許可するのかを記載する。
普段意識して使う奴。

IAMRoleにおけるアクセス許可の境界（ポリシー）

そのIAMRoleのアイデンティティベースのポリシーとリソースベースのポリシーに どこまで アクションを許可するのかを記載する。
正直存在理由がわからん。ともかくここで指定したポリシーの制限を超えたものは全部拒否される。

IAMRoleにおけるリソースベースのポリシー（信頼ポリシーまたは信頼されたエンティティ）

そのIAMRoleを 誰が 使用することを許可するのかを記載する。
場所によってリソースベースだの信頼だの表記ゆれがあって厄介な奴。