IAMユーザー・IAMロール・IAMポリシーの違いを初心者向けに解説
AWSの権限管理で重要なIAMユーザー、IAMロール、IAMポリシーの違い、試験ポイント、実務での使い分けを整理します。
比較対象サービス
サービス名をクリックすると、用語詳細ページで復習できます。
結論
IAMはAWSの権限管理サービスです。
IAMユーザー、IAMロール、IAMポリシーは、それぞれ役割が違います。
| 用語 | 一言でいうと | 主な使いどころ |
|---|---|---|
| IAMユーザー | 長期認証情報を持てるAWSアカウント内のID | フェデレーション非対応の例外、学習・検証 |
| IAMロール | 一時的に権限を引き受ける仕組み | Lambda、EC2、GitHub Actions、フェデレーションなど |
| IAMポリシー | 何を許可・拒否するかを書いた権限定義 | S3読み取り許可、DynamoDB書き込み許可など |
迷ったら、まずはこう判断します。
- 人の通常アクセス：フェデレーションでIAMロールを引き受ける
- IAMユーザー：フェデレーション非対応の例外や学習用途
- AWSサービスに権限を渡す：IAMロール
- 何を許可するか：IAMポリシー
比較表
| 項目 | IAMユーザー | IAMロール | IAMポリシー |
|---|---|---|---|
| 種類 | ID | 権限を引き受ける仕組み | 権限ルール |
| 主な対象 | 例外的な人、特定用途 | AWSサービス、外部ID、別アカウント | ユーザー、グループ、ロール |
| 認証情報 | パスワード、アクセスキー | 一時的な認証情報 | 認証情報は持たない |
| 主な用途 | フェデレーション非対応の例外、学習・検証 | Lambda実行、EC2権限、OIDC連携、人のフェデレーション | 許可アクションと対象リソースの定義 |
| セキュリティ観点 | MFA、アクセスキー管理、用途限定が重要 | 長期キー不要で安全にしやすい | 最小権限が重要 |
| このプロジェクトでの用途 | 例外的な管理用に限定 | Lambda実行ロール、GitHub Actionsロール | DynamoDB PutItem、S3デプロイ許可など |
初学者向け説明
IAMユーザー
IAMユーザーは、AWSアカウント内に作る長期認証情報を持てるIDです。
AWSコンソールにログインしたり、AWS CLIから操作したりできますが、人間の通常アクセスではIAM Identity Centerなどのフェデレーションを優先します。
IAMユーザーを使うのは、フェデレーションで対応できないケースや学習・検証に限定します。アクセスキーを発行すると漏えいリスクがあるため、取り扱いに注意が必要です。
IAMロール
IAMロールは、特定の主体が一時的に権限を引き受けるための仕組みです。
例えば、LambdaがDynamoDBに書き込む場合、Lambda関数にIAMロールを付与します。
このプロジェクトでは、問い合わせ送信LambdaにDynamoDBへの書き込み権限だけを持たせる設計にします。
IAMポリシー
IAMポリシーは、どの操作をどのリソースに対して許可するかをJSONで定義するものです。
例えば、問い合わせLambdaには dynamodb:PutItem だけを許可します。
不要な dynamodb:* や AdministratorAccess は付けません。
試験で問われるポイント
CLF-C02で問われやすいポイント
- IAMはAWSの認証・認可を管理するサービス
- 人のアクセスはフェデレーションと一時的な認証情報を優先する
- IAMユーザーを使う場合はMFAを設定する
- rootユーザーは日常利用しない
- IAMポリシーで権限を定義する
- 最小権限の原則が重要
- IAMロールはAWSサービスに権限を付与するときによく使う
SAA-C03で問われやすいポイント
- EC2やLambdaに権限を与える場合はIAMロールを使う
- 長期アクセスキーよりIAMロールを優先する
- クロスアカウントアクセスではIAMロールを使う
- GitHub Actionsなど外部サービス連携ではOIDC + IAMロールが安全
- リソース単位でポリシーを絞る
*を多用した過剰権限は避ける
実務での使い分け
IAMユーザーを使うケース
- フェデレーションで対応できない特定用途
- 学習初期にAWS CLIやコンソールの仕組みを確認する
- 緊急時や例外運用として明確に管理する
ただし、人間の通常アクセスではIAM Identity Centerなどのフェデレーションを優先します。IAMユーザーを使う場合はMFAを必ず設定し、アクセスキーの発行は最小限にします。
IAMロールを使うケース
- IAM Identity Centerや外部IdPから人が一時的に権限を引き受ける
- LambdaからDynamoDBに書き込む
- EC2からS3を読む
- GitHub ActionsからS3へデプロイする
- 別AWSアカウントから一時的にアクセスする
このプロジェクトでは、以下のIAMロールが登場します。
- Lambda問い合わせ送信用ロール
- GitHub Actionsデプロイ用ロール
IAMポリシーを使うケース
- LambdaにDynamoDB PutItemだけを許可する
- GitHub ActionsにS3アップロードだけを許可する
- CloudFront Invalidationだけを許可する
- S3バケットへの読み取りをCloudFrontにだけ許可する
ポリシーでは、ActionとResourceを絞ることが重要です。
よくある間違い
間違い1：IAMユーザーにAdministratorAccessを常用する
学習初期は広い権限で進めたくなります。
ただし、本番やポートフォリオ説明では危険です。
長期的には、作業ごとに権限を分けるべきです。
間違い2：Lambda内にAWSアクセスキーを書く
LambdaにはIAMロールを付けます。
コード内にAWSアクセスキーを書くのは危険です。
このプロジェクトでも、秘密情報の直書きは禁止です。
間違い3：IAMロールとIAMポリシーを同じものだと思う
IAMロールは権限を引き受ける入れ物です。
IAMポリシーは権限の内容です。
ロールにポリシーを付けることで、何ができるかが決まります。
間違い4：Resourceを常に * にする
* はすべてを意味します。
実務では、対象のS3バケットやDynamoDBテーブルなどに絞ります。
関連用語
関連問題
まとめ
IAMユーザー、IAMロール、IAMポリシーはAWSセキュリティの基礎です。
IAMユーザーは長期認証情報を持てるID、IAMロールは一時的に権限を引き受ける仕組み、IAMポリシーは権限内容です。
この違いを説明できると、AWSポートフォリオのセキュリティ設計も説明しやすくなります。
次に学ぶ内容
比較で違いを理解したら、関連用語と模擬問題で知識を確認してください。資格試験では「似ているサービスの使い分け」が問われます。