AWS IAM（Identity and Access Management）

September 11, 2026September 25, 2026

概要

AWS IAM（Identity and Access Management）は、AWS リソースへのアクセスを管理するサービスです。

「誰が（Who）」「どのリソースに（What）」「何をできるか（Actions）」を細かく制御できます。

たとえば、社内に 10 人のエンジニアがいる場合を考えます。全員が同じ AWS アカウントを使うとき、「開発者は EC2 を操作できるが、S3 の削除はできない」「新入社員は参照のみ」といった制御を実現するのが IAM の役割です。

—

この記事のメリット

IAM の主要コンポーネント（ポリシー・ユーザー・グループ・ロール）の役割と関係を理解できる
最小権限の原則を理解できる
ルートユーザーの保護方法を把握できる
人間・チーム・AWS サービスごとに適切なアクセス管理の方法を選べるようになる

—

執筆者とキャラクター紹介

執筆者：土肥（とひ）

株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。

クラウドおさる

クラウドおさる

はじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。

クラウドおさる

基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。

クラウドおさる

猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。

技術解説

ポリシー：権限の「定義書」

IAM を理解する上で最初に押さえるべきなのがポリシーです。

ポリシーとは「何ができて、何ができないか」を定義した JSON 形式のドキュメントで、IAM ユーザー・グループ・ロールにアタッチして権限を与えます。このJSON形式のドキュメントをAWSではポリシードキュメントと呼びます。

たとえば「EC2 インスタンスの起動・停止のみ許可する」ポリシーを作成し、エンジニアにアタッチ（紐付け）する、という使い方をします。

アイデンティティベースのポリシー（ユーザー・グループ・ロールにアタッチするポリシー）は 3 種類に分けられます。

種類	概要	特徴
AWS 管理ポリシー（コンソール表記は「AWS マネージド」）	AWS があらかじめ用意したポリシー	変更不可。よく使われる権限セットが揃っている
カスタマー管理ポリシー（同「カスタマーマネージド」）	自分で作成・管理するポリシー	複数のユーザーやロールに再利用できる
インラインポリシー	ユーザー・グループ・ロールに直接埋め込むポリシー	1 対 1 の関係。再利用しない用途に使う

ポリシードキュメントは以下の構造になっています。

フィールド	役割
`Version`	ポリシー言語のバージョン。現在は `2012-10-17` を指定するのが標準
`Statement`	権限の定義をリスト形式で記載する
`Sid`	ステートメントの識別子（任意）
`Effect`	許可（`Allow`）か拒否（`Deny`）かを指定
`Action`	許可または拒否する操作を列挙
`Resource`	操作の対象リソースを指定。`*` はすべてのリソースを意味する

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:ListObjectAnnotations",
                "s3:ListAccessPointsForObjectLambda",
                "s3:ListBucketMultipartUploads",
                "s3:ListAccessPoints",
                "s3:ListCallerAccessGrants",
                "s3:ListBucketVersions",
                "s3:ListJobs",
                "s3:ListBucket",
                "s3:ListMultiRegionAccessPoints",
                "s3:ListStorageLensGroups",
                "s3:ListAccessGrantsLocations",
                "s3:ListMultipartUploadParts",
                "s3:ListStorageLensConfigurations",
                "s3:ListTagsForResource",
                "s3:ListAllMyBuckets",
                "s3:ListAccessGrantsInstances",
                "s3:ListAccessGrants",
                "s3:ListObjectVersionAnnotations"
            ],
            "Resource": "*"
        }
    ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:ListObjectAnnotations",
                "s3:ListAccessPointsForObjectLambda",
                "s3:ListBucketMultipartUploads",
                "s3:ListAccessPoints",
                "s3:ListCallerAccessGrants",
                "s3:ListBucketVersions",
                "s3:ListJobs",
                "s3:ListBucket",
                "s3:ListMultiRegionAccessPoints",
                "s3:ListStorageLensGroups",
                "s3:ListAccessGrantsLocations",
                "s3:ListMultipartUploadParts",
                "s3:ListStorageLensConfigurations",
                "s3:ListTagsForResource",
                "s3:ListAllMyBuckets",
                "s3:ListAccessGrantsInstances",
                "s3:ListAccessGrants",
                "s3:ListObjectVersionAnnotations"
            ],
            "Resource": "*"
        }
    ]
}

IAM ユーザー：1 人に権限を与える

IAM ユーザーは、AWS を操作する個人（または特定のアプリケーション）を表すエンティティです。マネジメントコンソールへのログインや、CLI からの操作に使います。

ユーザーに権限を与えるには、ポリシーをそのユーザーに直接アタッチします。

ユーザー（太郎） ← ポリシー（EC2 の操作を許可）

ユーザー（太郎） ← ポリシー（EC2 の操作を許可）

ユーザーには 2 種類の認証情報を設定できます。

パスワード：マネジメントコンソールへのログインに使用
アクセスキー（アクセスキー ID + シークレットアクセスキー）：CLI・SDK・API からの操作に使用

IAM グループ：チームに権限を与える

ユーザーが 1 人のうちはポリシーを直接アタッチする運用でも問題ありません。しかし、ユーザが 10 人に増えたとき、同じポリシーを 10 人に個別にアタッチするのは手間ですし、管理ミスも起きやすくなります。この課題を解決するのが IAM グループです。

グループにポリシーをアタッチすると、グループに所属するすべてのユーザーに権限が適用されます。

グループ（開発チーム） ← ポリシー（EC2 の操作を許可）
  ├── ユーザー（太郎）
  ├── ユーザー（花子）
  └── ユーザー（次郎）

グループ（開発チーム） ← ポリシー（EC2 の操作を許可）
  ├── ユーザー（太郎）
  ├── ユーザー（花子）
  └── ユーザー（次郎）

新しいメンバーが入ったときはグループに追加するだけ、権限を変更したいときはグループのポリシーを更新するだけで済みます。

グループの動作について、以下の点を押さえておきます。

ユーザーは複数のグループに所属できる
グループにグループを入れることはできない（ネストは不可）

IAM ロール：「人」以外に権限を与える

ユーザーとグループは「人」にアクセスを管理するための仕組みでした。では、AWS のサービス自身がリソースにアクセスしたい場合はどうすればよいでしょうか。

たとえば、EC2 上のアプリケーションが S3 バケットにファイルを保存する、というシーンを考えます。

この場合、アプリケーションに IAM ユーザーのアクセスキーをハードコードすることは避けるべきです。コードやサーバーが漏洩した際にアクセスキーも流出してしまいます。

この課題を解決するのが IAM ロールです。

ロールは「権限のセット」を EC2 などの AWS サービスに割り当てる仕組みです。ロールを割り当てられた EC2 インスタンスは、アクセスキーなしで S3 にアクセスできます。

EC2 インスタンス ← IAM ロール（S3 への読み書きを許可）

EC2 インスタンス ← IAM ロール（S3 への読み書きを許可）

IAM ロールを使うと、EC2 上のアプリはアクセスキーを持たずに S3 へアクセスできる

ユーザーとロールの違いは次の通りです。

比較軸	IAM ユーザー	IAM ロール
主な用途	人間が AWS を操作する	AWS サービスや外部エンティティが権限を引き受ける
認証情報	パスワード・アクセスキーを持つ	固定の認証情報を持たない（一時的なトークンを発行）
使用例	エンジニアがコンソールで操作	EC2 が S3 にアクセス、クロスアカウントアクセス

ロールを使う主なシーン：

AWS サービスが他のリソースにアクセスする場合（例：EC2 → S3、Lambda → DynamoDB）
別の AWS アカウントのユーザーにアクセスを許可する場合（クロスアカウントアクセス）

—

新卒・未経験の方へ

AWS を仕事にしたい方へ ── 新卒・未経験から

この記事を書いているのは、AWS の設計・構築を仕事にしている現役エンジニアです。運営元の株式会社ジェニュインでは、新卒・未経験の方を募集しています。プログラミング未経験から入社して活躍しているメンバーもいます。

✓システム開発・WEB エンジニア / インフラ構築などの職種で、未経験から応募できます
✓未経験から入社した社員の声を含む社員アンケートを掲載
✓応募フォームから 1 分で応募できます

採用ページを見る

実践

IAM のポリシー・グループ・ロールを実際に作成し、EC2 インスタンスにロールをアタッチするまでを行います。

前提条件

リージョンは ap-northeast-1（東京）を使用します。IAM はグローバルサービスですが、EC2 の操作で使用します
IAM の管理権限を持つユーザーで AWS マネジメントコンソールにログイン済みであること
ロールのアタッチ先として、EC2 インスタンスが 1 台起動済みであること

このハンズオンで作成するリソースは以下のとおりです。

リソース種別	リソース名	用途
IAM ポリシー	`s3-list-only-policy`	S3 のリスト系アクションのみを許可するカスタマー管理ポリシー
IAM グループ	`developers`	開発チーム用のグループ。上記ポリシーをアタッチする
IAM ロール	`ec2-s3-readonly-role`	EC2 から S3 を参照するためのロール

カスタマー管理ポリシーを作成する

AWS マネジメントコンソールにログインし、上部の検索バーに IAM と入力して「IAM」を選択します。IAM はグローバルサービスなので、リージョンの表示は「グローバル」になります。

左側ナビゲーションの「アクセス管理」→「ポリシー」を選択します。一覧の「タイプ」列が「AWS マネージド」となっているものが AWS 管理ポリシーです。

右上の「ポリシーの作成」をクリックします。ポリシーの作成は「ステップ 1 アクセス許可を指定」「ステップ 2 確認して作成」の 2 ステップで進みます。

「ポリシーエディタ」で「ビジュアル」が選択されていることを確認し、「サービスを選択」をクリックします。検索ボックスに S3 と入力し、表示された「S3」を選択します。

「アクション許可」の「アクセスレベル」から「リスト」を展開し、「すべてのリストアクション」にチェックを入れます。見出しが「リスト (選択済み 18/18)」に変わります。

「リソース」で「すべて」を選択します。ワイルドカード（*）を使うと対象が広くなるため、「制限が少な過ぎる可能性があります」という注意が表示されます。実運用では特定の ARN を指定するほうが安全です。

ポリシーエディタ（ビジュアル）で S3 のリストアクションとリソースを選択した画面

エディタ右上の「JSON」をクリックすると、ビジュアルでの設定内容がポリシードキュメントとして生成されていることを確認できます。

「次へ」をクリックし、「ポリシー名」に s3-list-only-policy を入力します。その他の項目はデフォルトのままにします。

ページ下部の「ポリシーの作成」をクリックします。

ポリシー一覧に戻り、検索ボックスに s3-list-only-policy と入力すると、タイプが「カスタマーマネージド」のポリシーとして作成されていることを確認できます。

作成した s3-list-only-policy がポリシー一覧に表示されている状態

グループを作成してポリシーをアタッチする

左側ナビゲーションの「アクセス管理」→「IAM ユーザーグループ」を選択し、右上の「グループを作成」をクリックします。

「ユーザーグループを作成」の画面で、以下を設定します。

「グループに名前を付ける」の「ユーザーグループ名」: developers
「許可ポリシーを添付 – オプション」の検索ボックスに s3-list-only-policy と入力し、表示されたポリシーにチェックを入れる

「ユーザーをグループに追加 – オプション」では、既存の IAM ユーザーをこの場でグループに入れることもできます。今回は追加せずに進めます。

ページ下部の「ユーザーグループを作成」をクリックします。

作成したグループ名をクリックし、「許可」タブで s3-list-only-policy がアタッチされていることを確認します。グループには最大 10 個の管理ポリシーをアタッチできます。

ユーザーをこのグループに追加すると、そのユーザーにはグループのポリシーの権限がすぐに適用されます。追加はグループ詳細画面の「ユーザー」タブから行います。

EC2 用の IAM ロールを作成する

左側ナビゲーションの「アクセス管理」→「ロール」を選択し、右上の「ロールを作成」をクリックします。ロールの作成は「ステップ 1 信頼されたエンティティを選択」「ステップ 2 許可を追加」「ステップ 3 名前、確認、および作成」の 3 ステップです。

「信頼されたエンティティタイプ」で「AWS のサービス」を選択します。「ユースケース」の「サービスまたはユースケース」で EC2 を選択すると、その下にユースケースの一覧が表示されるので、先頭の「EC2（Allows EC2 instances to call AWS services on your behalf.）」を選択して「次へ」をクリックします。

「許可を追加」の検索ボックスに AmazonS3ReadOnlyAccess と入力し、表示されたポリシーにチェックを入れて「次へ」をクリックします。

「ロール名」に ec2-s3-readonly-role を入力します。同じ画面で、ステップ 1 の選択から生成された信頼ポリシー（ec2.amazonaws.com に sts:AssumeRole を許可する内容）も確認できます。ページ下部の「ロールを作成」をクリックします。

作成したロールをクリックすると、概要に「インスタンスプロファイルの ARN」が表示されます。EC2 用のロールでは、インスタンスにロールを渡すための入れ物（インスタンスプロファイル）が自動で作成されます。

「信頼関係」タブを開くと、ec2.amazonaws.com がこのロールを引き受けられる（sts:AssumeRole）ことが定義されているのを確認できます。

ec2-s3-readonly-role の信頼関係タブ（ec2.amazonaws.com が信頼されている状態）

EC2 インスタンスにロールをアタッチする

上部の検索バーに EC2 と入力して「EC2」を選択し、リージョンが ap-northeast-1（東京）であることを確認します。左側ナビゲーションの「インスタンス」→「インスタンス」を選択します。

ロールを割り当てるインスタンスのチェックボックスを選択し、「アクション」→「セキュリティ」→「IAM ロールを変更」をクリックします。

「IAM ロール」のドロップダウンから ec2-s3-readonly-role を選択します。選択したロールは、インスタンスに現在アタッチされているロールを置き換えます。

「IAM ロールの更新」をクリックします。

インスタンスの詳細画面に戻り、「セキュリティ」タブを開くと、「IAM ロール」に ec2-s3-readonly-role が表示されていることを確認できます。

以降、このインスタンス上で動作するアプリケーションは、アクセスキーを持たずに S3 を参照できます。認証情報は一時的なものが自動で発行・更新されるため、コードやサーバーにキーを埋め込む必要がありません。

—

まとめ

コンポーネント	役割
IAM ポリシー	「何ができて何ができないか」を定義する権限の定義書
IAM ユーザー	AWS を操作する個人・アプリケーションを表すエンティティ
IAM グループ	ユーザーをまとめ、一括で権限を管理する仕組み
IAM ロール	AWS サービスや外部エンティティが一時的に権限を引き受ける仕組み

最小権限の原則：必要な操作だけを許可し、それ以上の権限は与えない
ルートユーザーは日常使用しない：MFA を設定し、通常業務は IAM ユーザーで行う
AWS サービスが他のリソースにアクセスする場合は IAM ロールを使い、アクセスキーのハードコードを避ける
多数のユーザーや複数アカウントの管理には IAM Identity Center を活用する

—

参照先

キャリア相談

独学の先に、AWS の仕事がある ── ジュニアおさるのキャリア相談

CLF には受かったけれど、次に何をすればいいのか分からない。独学で AWS を学ぶジュニアおさるの相談に、株式会社ジェニュイン代表の土肥が答えています。

✓資格はゴールか、CLF の次に何から手を付けるか
✓EC2 の次に作ってみる構成と、IaC・コスト管理
✓実務経験ゼロでも、面接で話せる「これまで」の作り方

相談を読む

新卒・未経験の方へ

AWS を仕事にしたい方へ ── 新卒・未経験から

✓システム開発・WEB エンジニア / インフラ構築などの職種で、未経験から応募できます
✓未経験から入社した社員の声を含む社員アンケートを掲載
✓応募フォームから 1 分で応募できます

採用ページを見る

この記事が気に入ったら
フォローしてね！

Follow @osaru_cloud Follow Me

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

この記事を書いた人

土肥康太郎

株式会社ジェニュイン（https://genuine-pt.jp)の代表取締役.

2018年〜インフラエンジニアとしてキャリアをスタートし、オンプレミスのネットワーク・サーバ環境で3年半、クラウド環境で4年半の8年間エンジニアとして従事。
2021年に佐藤氏の創業した株式会社Luxyを引き継ぎ、代表に就任。
その後アガルートグループ内の株式会社ジェニュインと合併。
合併後同社代表に就任。