【AWS SAA対策】IAMって何？ユーザー・グループ・ロール・ポリシーの違いをわかりやすく解説

はじめに

AWS SAA試験において、IAM（Identity and Access Management）に関係する問題は全体の中でも特に出題数が多く、他のサービス（EC2・S3など）と組み合わせた問題の前提知識としても必要になります。

この記事では、初学者が最初に混乱しやすい「IAMユーザー」「IAMグループ」「IAMロール」「IAMポリシー」の4つの要素を解説します。

難しい概念も「オフィス」の比喩を使って直感的に理解できるよう説明しますので、ぜひ最後まで読んでみてください。

IAMとは何か？

IAMは、AWS リソースへのアクセスを安全に管理するためのサービスです。

IAMを使用することで、ユーザ等の認証とリソースの使用の認可を制御することが可能です。

「認証」と「認可」は似ている言葉ですが、以下のような違いがあります。

「ユーザー」「グループ」「ロール」「ポリシー」の違い

IAMに関して、最初に混乱しやすいのが「ユーザー」「グループ」「ロール」「ポリシー」の4つの関係です。

これらはオフィスに例えると整理しやすくなります。

IAMの概念	オフィスの例え	役割
IAMユーザー	社員証	特定の個人を表す認証情報
IAMグループ	部署	複数ユーザーをまとめる入れ物
IAMポリシー	許可証	できることを定義したルール
IAMロール	貸出用の鍵	一時的に役割を引き受ける仕組み

それぞれを順番に見ていきましょう。

① IAMユーザー ＝ 社員証（特定の個人）

IAMユーザーは、AWSを操作する個人のアカウントです。社員証のように、その人専用の認証情報を持ちます。

AWSアカウントを作成すると、デフォルトでルートユーザーが存在します。ルートユーザーにしかできない操作は限られており、AWSアカウントの解約・MFAデバイスの管理・ルートアクセスキーの削除などがこれに該当します。AWSではルートユーザーではなく、最小権限の原則を適用したIAMユーザーの使用がベストプラクティスとなっています。

IAMユーザーの認証方法は2種類

IAMユーザーには、用途に応じて2種類の認証方法があります。

認証方法	用途
ユーザー名 ＋ パスワード	AWSマネジメントコンソールへのログイン（ブラウザ操作）
アクセスキー ＋ シークレットアクセスキー	AWS CLI・SDKでのプログラムアクセス（コマンド操作）

アクセスキーは一度発行したら大切に管理し、定期的にローテーションすることが推奨されています。

キーが漏洩すると第三者にAWSを操作されるリスクがあるためです。

また、IAMユーザを作成する上で以下の原則があります。

---

② IAMグループ ＝ 部署（開発部・営業部など）

IAMグループは、複数のIAMユーザーをまとめて権限を管理する機能です。

「開発チーム全員にS3の読み取り権限を付与する」といった場合、個別ユーザーにポリシーを設定するのではなく、以下のようにグループに対してポリシーをアタッチすれば一括管理できます。

開発グループ（IAMグループ）
├── Aさん（IAMユーザー）
├── Bさん（IAMユーザー）
└── Cさん（IAMユーザー）
↑このグループにポリシーをアタッチすると3人全員に権限が付与される

また、IAMグループを利用する場合は以下の注意点があります。

・IAMユーザーは複数のグループに同時所属できる
たとえば「Aさんが開発グループと兼任で運用グループにも入る」といったことが可能です。

・IAMグループを別のIAMグループに所属させることはできない
「開発グループ」を「運用グループ」に入れるといった入れ子（ネスト）の構造はAWSでは対応していません。

なぜグループを使うのか？ AWSのベストプラクティス

AWSは「IAMユーザーに直接ポリシーをアタッチせず、グループを通じて権限を管理する」ことを推奨しています。

グループを利用することで、以下のようにIAMユーザの権限を効率的に管理することが可能です。

③ IAMポリシー ＝ 許可証（権限の本体）

IAMポリシーは、AWSリソースへの操作権限を定義したルール書（JSON形式）です。

ユーザー・グループ・ロールにアタッチすることで権限を付与します。

ポリシーはJSON形式で書かれている

たとえば「特定のAWS アカウント のメンバーに、S3バケットに対するすべてのアクションの実行を許可する」というポリシーは、以下のようなJSONで表現されます。

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid": "1",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111122223333:root"
                ]
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket",
                "arn:aws:s3:::amzn-s3-demo-bucket/*"
            ]
        }
    ]
}

ポリシーの5つの構成要素

ポリシーは以下の５つの要素(Effect/Action/Resource/Principal/Condition)で構成されています。

要素	説明	例
Effect	許可（Allow）または拒否（Deny）を指定	Allow / Deny
Action	実行できる操作を指定	s3:GetObject、ec2:StartInstances
Resource	操作対象のリソース（ARN形式）を指定	arn:aws:s3:::my-bucket/*
Principal	アクセスのリクエスト元（リソースベースポリシーで使用）	特定のIAMユーザーのARN
Condition	ポリシーが適用される条件（任意）	特定のIPアドレス範囲のみ許可

④ IAMロール ＝ 貸出用の鍵（一時的に役割を引き受ける仕組み）

IAMロールは、ここまで説明した「ユーザー」「グループ」「ポリシー」とは少し異なる概念です。

ロールは「人」ではなく「AWSサービスやアプリケーション・別アカウント」に権限を渡すためのものです。

なぜロールが必要なのか？

たとえば「EC2インスタンス上で動くアプリがS3バケットのファイルを読み書きしたい」という場面を考えます。

❌ NG ：アクセスキーをコードに直接書く

# こんな書き方は絶対NG
aws_access_key = "AKIAXXXXXXXXXXXXXXXX"
aws_secret_key = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

✅ 正解：EC2にIAMロールをアタッチする

IAMロールをEC2にアタッチすると、アプリは一時的な認証情報（アクセスキー）を自動で取得できます。この一時キーは数時間で自動的に期限切れになり、自動でローテーションされるため、漏洩リスクが大幅に下がります。

インスタンスプロファイルとは？

EC2にIAMロールをアタッチするとき、厳密には「インスタンスプロファイル」という入れ物を経由しています。インスタンスプロファイルはEC2専用のIAMロールを格納する容器で、IAMロールを作成すると自動的に作成されます。

IAMロールを使う代表的な場面

場面	説明
EC2からAWSサービスを操作する	アクセスキーをコードに書かずに安全に操作できる
クロスアカウントアクセス	別のAWSアカウントのリソースを操作する
IDフェデレーション	GoogleやActive DirectoryのユーザーをAWSにログインさせる
IAM Roles Anywhere	オンプレミスや他クラウドのサーバーからAWSリソースにアクセスする

まとめ：4つの要素の比較表

改めてIAMの要素について整理しました。

要素	役割	アタッチの対象	キーワード
IAMユーザー	個人の認証情報（社員証）	AWSの操作者（人・アプリ）	1人1アカウント・最小権限
IAMグループ	ユーザーの集合体（部署）	IAMユーザー	ネスト不可・ベストプラクティス
IAMポリシー	権限のルール書（許可証）	ユーザー・グループ・ロール・リソース	JSON形式・デフォルト拒否
IAMロール	一時的な役割の鍵	AWSサービス・他アカウント・外部ID	一時認証情報・コードにキーを書かない

SAA試験直前チェックリスト（IAM基本編）

SAA試験対策としては、以下の項目を理解しておきましょう。