まずはイメージ

たとえば会社で考えると、

• ロール = 「経理担当」「人事担当」のような役割
• ポリシー = 「経費申請を承認できる」「給与データを見られる」のような権限ルール

です。

つまり、

• ロール単体では何ができるか決まらない
• ポリシーをロールに付けて初めて、そのロールの権限が決まる

という関係です。

IAMロールとは

IAMロールは、AWS上の「一時的に引き受けて使う権限付きの身分」です。
IAMユーザーと似ていますが、長期的なパスワードやアクセスキーを持たないのが大きな特徴です。必要なときに引き受けられ、主に一時クレデンシャルで使われます。

よくある利用例は次のとおりです。

• EC2に付けるロール
  EC2上のアプリがS3やDynamoDBにアクセスする
• Lambda実行ロール
  Lambda関数がCloudWatch LogsやS3を操作する
• クロスアカウント用ロール
  別AWSアカウントのユーザーやロールが引き受ける
• 外部IDプロバイダ連携用ロール
  SAML / OIDC でログインした利用者が使う

AWSでは、ロールを作る際に「誰がそのロールを引き受けてよいか」を**信頼ポリシー（trust policy）**で定義します。

IAMポリシーとは

IAMポリシーは、許可・拒否のルールをJSONで記述したものです。
誰かがAWS APIを実行しようとしたとき、AWSはそのポリシーを評価して、許可するか拒否するかを判断します。

典型的な要素は次です。

• Action: 何をしたいか
  例: s3:GetObject
• Resource: どのリソースに対してか
  例: 特定のS3バケットやオブジェクト
• Effect: 許可か拒否か
  例: Allow / Deny
• Condition: 条件付きにするか
  例: 特定IPからのみ許可

各AWSサービスで使える Action / Resource / Condition key はサービスごとに定義されています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

よく混同される点

1. ロールにもポリシーがある

あります。
ただし、正確には2種類あります。

• 信頼ポリシー
  そのロールを誰が引き受けられるか
• 権限ポリシー
  そのロールで何ができるか

この2つを分けて考えると整理しやすいです。

2. ポリシーはロールだけに付けるものではない

ポリシーは、IAMユーザー・グループ・ロールなどのアイデンティティに付けるものと、S3バケットなどリソース側に付けるものがあります。

3. AWS managed policy と customer managed policy の違い

• AWS managed policy: AWSが用意している
• Customer managed policy: 自分で作る
• Inline policy: 特定のユーザー/ロールに埋め込む

再利用や管理のしやすさを考えると、実務ではcustomer managed policyが使いやすいことが多いです。