どうも、shihopowerです！前回の投稿から期間が開いてしまって、知的な便秘状態となっている今日この頃です。SAP対策をやっていて、基礎的なことなのに自分で言語化できないものがたくさんあることに気が付きました。行き詰ったときこそ基本に立ち返る、大事ですね！！
さて、今日はIAMについてです。
AWSを使い始めると必ず登場するIAMですが、「ロール」と「ポリシー」の違いで混乱する方も多いと思います。この記事では両者の差分をシンプルに整理します。
目次
１．IAMポリシー（Policy）── 「何ができるか」を定義するルール
２．IAMロール（Role）── 「誰が引き受けるか」を定義するID
３．2つの関係性を説明する
４．差分の比較表を示す
５．具体例：Lambda関数がS3にアクセスしたい場合
６．まとめ
１．IAMポリシー（Policy）── 「何ができるか」を定義するルール
IAMポリシーは、AWSリソースへのアクセス権限を記述したJSONドキュメントです。
単体では機能しないのがポイントです。ロール・ユーザー・グループにアタッチして初めて効力を発揮します。
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
上記は「my-bucket内のオブジェクトを読み取り許可する」というポリシーの例です。
２．IAMロール（Role）── 「誰が引き受けるか」を定義するID
IAMロールは、ポリシーをまとめてアタッチできる**「帽子」**のようなものです。
ユーザー、AWSサービス（EC2・Lambdaなど）、他アカウントが「引き受ける（Assume）」ことで、そのロールに紐づく権限を一時的に使えるようになります。
IAMロールは永続的な認証情報（アクセスキー）を持たず、一時的な認証情報を発行します。これがロールを使う大きなメリットの一つです。
３．2つの関係性を説明する
IAMロール
├── IAMポリシーA（S3読み取り許可）
└── IAMポリシーB（DynamoDB書き込み許可）
↑
EC2インスタンスがこのロールを引き受ける
→ S3読み取り ＋ DynamoDB書き込みが可能になる
４．差分の比較表を示す
| 項目 | IAMポリシー | IAMロール |
|---|---|---|
| 役割 | 権限のルール定義（何ができるかを定義する） | 権限をまとめたID（誰が引き受けるかを定義する） |
| 単体で機能するか | ❌ アタッチが必要 | ✅（ポリシーのアタッチは必要） |
| 誰が使う | ロール・ユーザーにアタッチ | サービス・ユーザー・アカウントが引き受ける |
| 認証情報 | なし | 一時的な認証情報を発行 |
５．具体例：Lambda関数がS3にアクセスしたい場合
実際のユースケースで流れを確認しましょう。
- 「S3読み取り許可」のポリシーを作成する
- そのポリシーをアタッチしたロールを作成する
- Lambda関数にそのロールを割り当てる
Lambda関数はロールを引き受けることで、一時的な認証情報を使ってS3にアクセスできるようになります。アクセスキーをコードに埋め込む必要がないため、セキュアな構成が実現できます。
６．まとめ
- ポリシー ＝「何ができるか」を記述したJSONのルール
- ロール ＝ポリシーを束ねて「誰かに引き受けてもらう」ためのID
「ポリシーで権限を定義 → ロールにアタッチ → サービスやユーザーがロールを引き受ける」というフローを意識すると、IAMの設計がぐっと理解しやすくなります。
本記事がどなたかの参考になれば幸いです。