テクノロジー 2026.7.30

【2026年最新】AWS IAMとは？ユーザー・ロール・ポリシーの違いを現役AWSエンジニアがわかりやすく解説

KANADE

「IAMってよく聞くけど、結局なんのサービス？」「ユーザーとロールとポリシー、何が違うのか毎回わからなくなる」「とりあえず権限を設定したいけど、呪文みたいなJSON画面で手が止まった」

AWSを触り始めると、ほぼ全員がこのIAMの壁にぶつかります。AWS IAMは、AWSを安全に使うための土台でありながら、登場する用語が似ていて混乱しやすい、最初の関門とも言えるサービスです。

本記事では、IAMの基本概念から、初学者が必ずつまずく「ユーザー・ロール・ポリシーの違い」、ポリシー（JSON）の読み方、そして実務で効くセキュリティのベストプラクティスまで、現役AWSエンジニアの視点で整理しました。あわせて、2026年時点のAWS公式が推奨する「一時的な認証情報を中心とした運用」の考え方も解説します。これからAWSを学ぶ方、AWS認定資格の取得を目指す方は、ぜひ最後までご活用ください。

この記事でわかること

・AWS IAMとは何か、なぜ必要なのか
・IAMユーザー・グループ・ロール・ポリシーの違い
・IAMポリシー（JSON）の基本的な読み方
・ルートユーザーやアクセスキーを安全に扱う考え方
・IAMのセキュリティベストプラクティス
・IAMの料金と、IAM Identity Centerとの違い

1. AWS IAMとは？【まずは結論】
2. IAMを構成する4つの要素（ユーザー・グループ・ロール・ポリシー）
3. 【最重要】ユーザー・ロール・ポリシーの違いをわかりやすく整理
4. IAMポリシーの読み方・書き方【JSONの基本】
5. IAMの使い方｜ルートユーザーの保護からMFA設定まで
6. IAMのセキュリティベストプラクティス【現役エンジニアの視点】
7. IAMの料金は？ IAM Identity Centerとの違い
8.よくある質問（FAQ）
まとめ｜IAMはAWSセキュリティの土台
参考リンク
関連記事

監修：KANADE
■保有資格
AWS Certified Cloud Practitioner / AWS Certified AI Practitioner / AWS Certified Solutions Architect - Associate / AWS Certified Developer - Associate / AWS Certified Machine Learning Engineer - Associate / AWS Certified SysOps Administrator - Associate / AWS Certified Data Engineer - Associate / AWS Certified DevOps Engineer - Professional / AWS Certified Solutions Architect - Professional / AWS Certified Security - Specialty / AWS Certified Database - Specialty / AWS Certified Data Analytics - Specialty / AWS Certified Machine Learning - Specialty / AWS Certified SAP on AWS - Specialty / AWS Certified Advanced Networking - Specialty / AWS Authorized Instructors
食品業界からIT業界未経験でALHへ入社。AWS環境上で稼働するシステムインフラの設計から運用保守を担当。

運営元：ALH株式会社
ALH株式会社は、AWSパートナーネットワーク（APN）において、以下の認定を取得しているAWSパートナー企業です。
◆ AWS 1000 APN Certification Distinction
AWS認定資格の取得数が1,000件を超えたパートナーに与えられる認定
◆ AWS Training Partner
AWS公認の研修トレーニングを提供できるパートナー認定
◆ AWS Select Tier Services Partner
AWSサービスの構築・運用において一定の実績を持つパートナー認定

1. AWS IAMとは？【まずは結論】

AWS IAM（Identity and Access Management／アイデンティティ・アンド・アクセス・マネジメント）とは、「誰が、どのAWSサービスやリソースに、何をできるか」を管理するためのサービスです。一言でいえば、AWSアカウントのアクセス管理（入退室管理）を担う仕組みです。AWS公式でも「アイデンティティとAWSのサービスおよびリソースへのアクセスを安全に管理する」サービスと位置づけられています（AWS公式 IAMユーザーガイド）。

たとえば「Aさんにはストレージ（S3）の閲覧だけ許可する」「開発チームには仮想サーバー（EC2）の起動・停止を許可するが削除は禁止する」といった、細かな権限のコントロールがIAMの役割です。AWSアカウントを安全に運用するうえで、避けては通れない中心的なサービスと言えます。

なお、2026年時点のAWS運用では、人間の利用者に長期的なIAMユーザーを直接発行するよりも、IAM Identity Centerや外部IDプロバイダーと連携し、一時的な認証情報でAWSへアクセスさせる方法が推奨されています。
本記事ではIAMユーザーの基本も解説しますが、実務ではIAMロールや一時的な認証情報の活用が重要になる、という前提で読み進めてください。

1-1. IAMの読み方と正式名称

「IAM」は「アイアム」と読みます（「アイ・エー・エム」と読まれることもあります）。正式名称はIdentity and Access Managementで、「Identity（誰なのか＝身元）」と「Access Management（アクセスの管理）」という2つの言葉が、そのままIAMの役割を表しています。

1-2. IAMが必要な理由は？ルートユーザーだけでは危険な理由

IAMが必要な最大の理由は、すべての操作が可能な「ルートユーザー」をそのまま使い続けるのが危険だからです。AWSアカウントを作ると、最初にルートユーザー（アカウント作成時のメールアドレスでログインするユーザー）が用意されます。これはAWSアカウント内のすべての操作が可能な、非常に強い権限を持つユーザーです。家でいう「マスターキー」のような存在だと考えてください。

マスターキーを全社員に配って日常業務に使わせる会社はありません。万が一漏れれば、請求情報の変更からアカウントの削除まで何でもできてしまうからです。そこでIAMを使い、「この人にはこの範囲だけ」という個別の権限を管理します。ルートユーザーは厳重に管理して日常業務では使わず、普段はIAMで管理された権限を使うというのが、AWS運用の大原則です。

1-3. IAMが担う「認証」と「認可」の違い

IAMの役割は、「認証（Authentication）」と「認可（Authorization）」の2つに分けて理解すると一気にクリアになります。ここは多くの初学者があいまいなまま進んでしまう、重要なポイントです。

用語	意味	身近な例え	IAMでの担当
認証（Authentication）	「あなたは誰か」を確認すること	建物の入口で身分証を見せる	ユーザーやフェデレーション、MFAでログインを確認
認可（Authorization）	「あなたは何をしてよいか」を決めること	入館後に入れる部屋が決まっている	ポリシーで操作できる範囲を制御

つまり「ログインできるか（認証）」と「ログインした後に何ができるか（認可）」は別物です。IAMはこの両方を一手に引き受けている、と押さえておきましょう。

2. IAMを構成する4つの要素（ユーザー・グループ・ロール・ポリシー）

IAMは主に「ユーザー」「グループ」「ロール」「ポリシー」の4つの要素で構成されます。このうち権限の中身そのものを定義するのがポリシーで、残りの3つは「そのポリシーを誰に・どう割り当てるか」の器だと考えると整理しやすくなります。

2-1. IAMユーザーとは？現在は限定利用が推奨される理由

IAMユーザーとは、AWSアカウント内に作成する、長期的な認証情報を持つIAMアイデンティティ（identity）です。パスワードやアクセスキーを持たせられるため、AWSマネジメントコンソールやCLI、SDKからAWSへアクセスできます。

ただし、現在のAWSベストプラクティスでは、人間の利用者にはIAM Identity Centerや外部IDプロバイダーとの連携を使い、一時的な認証情報でアクセスさせることが推奨されています。IAMユーザーは、フェデレーションが使えない特定のケースや緊急時の運用などに限定して使うものと理解しておきましょう。特に、長期間有効なアクセスキーは漏えい時のリスクが大きいため、可能な限りIAMロールや一時的な認証情報を使うことが重要です（AWS公式 IAMユーザー）。

2-2. IAMグループとは

IAMグループとは、複数のIAMユーザーをまとめて、同じ権限を一括で管理するための「束」です。
たとえば「開発者グループ」「経理閲覧グループ」を作り、そこに権限（ポリシー）を割り当てておけば、ユーザーはグループに追加するだけで適切な権限が付与されます。一人ずつ権限を設定する手間が省け、設定漏れも防げます。

2-3. IAMロールとは？一時的な権限を安全に使う仕組み

IAMロールとは、「一時的に引き受ける（Assumeする）権限のセット」です。
特定の人やサービスに固定で紐づくのではなく、必要なときに引き受けることで、一時的な認証情報を使って権限を借りる仕組みです。わかりやすい例えは「制服」や「来客用の入館証」です。その制服を着ている間だけ特定の作業ができ、脱げば権限はなくなります。EC2やLambdaといったAWSサービスにロールを持たせてサービス同士を安全に連携させる場面のほか、人間の利用者が一時的にAWSへアクセスする場面でも中心的に使われます。

2-4. IAMポリシーとは

IAMポリシーとは、「どのサービスの、どの操作を、許可するか／拒否するか」を定義した権限のルールブックです。JSONという形式（後述）で書かれ、ユーザー・グループ・ロールにアタッチ（貼り付け）して使います。ポリシー単体では何も起こらず、誰かに割り当てられて初めて効果を発揮します。

要素	役割	身近な例え	主な用途
ユーザー	長期認証情報を持つID	社員証	限定的な場面でのログイン・プログラムアクセス
グループ	ユーザーをまとめる束	部署・チーム	同じ権限を複数人に一括付与する
ロール	一時的に引き受ける権限	制服・来客証	人の一時アクセス、サービス間連携
ポリシー	権限の中身（許可・拒否）	ルールブック	上記3つにアタッチして権限を定義

3. 【最重要】ユーザー・ロール・ポリシーの違いをわかりやすく整理

3つの違いを一言でまとめると、「ユーザー＝長期的な身元」「ロール＝一時的に借りる権限」「ポリシー＝権限の中身」です。ユーザーとロールは「権限を持つ主体（誰が）」、ポリシーは「権限の内容（何をできるか）」という、そもそも別の役割を持っています。ここを分けて考えるのが、IAM理解の最大のコツです。

3-1. ユーザーとロールの違い（最大の混乱ポイント）

違いの核心は「長期的な認証情報を持つか」と「どう使うか」です。ユーザーは固有のパスワードやアクセスキーを持てる一方、ロールはそれらを持たず、引き受けたときに一時的な認証情報を発行して使います。現在のAWSでは、人間の利用者もロール（一時的な権限）を引き受ける形が推奨されています。

比較項目	IAMユーザー	IAMロール
主な位置づけ	長期的な認証情報を持つIAMアイデンティティ	一時的に引き受ける権限のセット
主な利用場面	フェデレーションが使えない特定ケース、緊急時用など	人間の一時アクセス、サービス間連携、外部ID・他アカウント連携
認証情報	パスワード／アクセスキーなど長期認証情報を持てる	固定のパスワード・キーを持たず、一時認証情報を使う
有効期間	継続的	一時的
セキュリティ上の注意	長期認証情報の漏えいリスクがある	一時認証のため長期キーよりリスクを抑えやすい
現在の推奨	必要な場合に限定して利用	人間・ワークロードともに積極的に活用

この「できる限り一時的な認証情報を使う」という方針は、AWS公式のIAMのセキュリティベストプラクティスでも明確に示されています。

3-2. ロールとポリシーの違い

ロールは「器（権限を引き受ける箱）」、ポリシーは「中身（具体的な許可内容）」です。空のロールを作っただけでは何の権限もありません。そこにポリシーをアタッチして初めて「S3を読める制服」「EC2を起動できる制服」になります。ロールとポリシーは、ほぼ必ずセットで使うものだと考えてください。

3-3. アクセス権限が決まる仕組み

IAMのアクセス可否は、単純な足し算ではなく、複数の要素をもとに評価されます。ユーザーやロールに付いたポリシーだけでなく、グループのポリシー、リソースベースのポリシー、権限境界、SCP（組織レベルの制限）など、複数の制御が関わります。基本の考え方は「明示的に許可されていなければ拒否」であり、どこかに明示的なDeny（拒否）があれば、Allow（許可）よりも優先されます。詳しい判定の順序は次の章で解説します。

4. IAMポリシーの読み方・書き方【JSONの基本】

IAMポリシーは「JSON」という形式で書かれ、中身は基本的に「Effect・Action・Resource」の3つの要素でできています。JSON（ジェイソン）とは、データを「キー（項目名）」と「値」の組み合わせで表現する、コンピュータが読みやすい記述形式です。一見難しく見えますが、読むポイントは3つだけです。

4-1. ポリシーの3大要素（Effect・Action・Resource）

次のサンプルは「特定のS3バケットの中身を読むことだけを許可する」ポリシーの例です。

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

要素	読み方	意味	上記サンプルでの内容
Effect	エフェクト	許可（Allow）か拒否（Deny）か	Allow（許可）
Action	アクション	どんな操作を対象にするか	s3:GetObject（オブジェクトの取得）
Resource	リソース	どの対象に対してか	example-bucketというS3バケット

つまりこのポリシーは「example-bucketの中身を取得する操作を、許可する」と読めます。Effect・Action・Resourceの3点さえ追えば、ほとんどのポリシーの意味はつかめます。

4-2. ポリシーの3つの種類

ポリシーには「AWS管理ポリシー」「カスタマー管理ポリシー」「インラインポリシー」の3種類があります。

種類	作成者	特徴	使いどころ
AWS管理ポリシー	AWSが用意	一般的な用途向けに事前定義済み	まず試す・素早く権限を付けたいとき
カスタマー管理ポリシー	利用者が作成	自社の要件に合わせて自由に定義・再利用可	本番運用で最小権限を実現するとき
インラインポリシー	利用者が作成	特定の1ユーザー／ロールに直接埋め込む	1対1の例外的な権限を付けるとき

AWS公式は「まずAWS管理ポリシーで始め、徐々にカスタマー管理ポリシーで最小権限へ寄せていく」ことを推奨しています（IAMベストプラクティス（AWS公式））。

4-3. アクセス可否が決まるロジック（明示的Denyが最優先）

権限判定の基本ルールは、「デフォルトは拒否、明示的なAllowがあれば許可、ただし明示的なDenyがあれば必ず拒否が優先される」という点です。

デフォルトでは、すべての操作は暗黙的に「拒否」される
いずれかのポリシーで「Allow（許可）」があれば、その操作は許可される
ただし、いずれかのポリシーに「Deny（拒否）」があれば、Allowを上書きして必ず拒否される

実務では、この判定にSCPや権限境界、リソースベースのポリシーなど複数の要素が関わります。「許可したはずなのに操作できない」ときは、別のポリシーやSCPでDenyされていないかを真っ先に疑うのが定石です。この挙動はAWS公式のポリシーの評価ロジック（AWS公式ドキュメント）に明記されています。

5. IAMの使い方｜ルートユーザーの保護からMFA設定まで

ここからは、実際にIAMを使い始める基本の流れを見ていきます。細かい画面のUIは変わることがあるため、考え方の順序をつかんでおくのがおすすめです。

5-1. ルートユーザーで最初にやるべきこと

アカウント作成直後は、まずルートユーザーを保護します。具体的には、MFAを設定し、ルートユーザーのパスワードやMFAデバイス、アクセスキーなどを厳重に管理します。

そのうえで、日常的な作業はルートユーザーでは行わず、IAM Identity Centerや外部IDプロバイダーと連携した一時的な認証情報を使う構成を検討します。ルートユーザーは、ルートユーザーでしか実行できない操作に限定して使いましょう（ルートユーザーのベストプラクティス（AWS公式））。

5-2. 通常アクセスの構成（IAM Identity Center／フェデレーション）

人間の利用者のアクセスは、IAM Identity Centerや外部IDプロバイダー連携を軸に構成するのが現在の推奨です。これにより、利用者はログインのたびに一時的な認証情報でAWSへアクセスでき、長期的なパスワードやアクセスキーを持たせずに済みます。複数のAWSアカウントを運用する組織では、この構成がとくに重要になります。

5-3. IAMユーザーを限定的に使う場合の作成手順

フェデレーションが使えないなど、やむを得ずIAMユーザーを作成する場合は、共有アカウントを避け、利用者ごとに個別のユーザーを作成します。手順の考え方は次のとおりです。

マネジメントコンソールで「IAM」を開き、「ユーザー」→「ユーザーの作成」を選ぶ
ユーザー名を入力し、コンソールへのアクセスを許可するか選ぶ
権限を付与する（グループ経由で最小限の権限を付けるのが管理しやすい）
MFAを必ず設定し、サインイン情報を安全に本人へ渡す

ポイントは、MFAを必須にし、必要最小限の権限だけを付与することです。

5-4. MFA（多要素認証）の設定

MFA（Multi-Factor Authentication／多要素認証）とは、パスワードに加えてスマホアプリなどが生成する一時コードの入力を求める、二段構えの認証です。パスワードが漏れても、手元の認証デバイスがなければログインできないため、不正アクセスを大幅に防げます。AWS公式もMFAの有効化を推奨しており、特に権限の強いユーザーやルートユーザーには必須と考えてください。

5-5. アクセスキーの扱い方と注意点

アクセスキーとは、CLI（コマンド操作）やSDKからAWSを操作するための、文字列の長期認証情報です。漏えいすると不正利用に直結するため、可能な限りIAMロールやIAM Identity Centerによる一時的な認証情報を使いましょう。GitHubなどに誤って公開してしまう事故も後を絶ちません。やむを得ずアクセスキーを作成する場合は、必要最小限の権限にし、使用状況を定期的に確認し、不要になったらすぐ削除・ローテーション（定期的な入れ替え）を行ってください（アクセスキーの管理（AWS公式））。

6. IAMのセキュリティベストプラクティス【現役エンジニアの視点】

IAMで最低限おさえるべきは「ルートユーザーを日常利用しない」「最小権限」「一時的な認証情報の活用」「MFA」「定期的な棚卸し」の5点です。以下はAWS公式が示すIAMセキュリティベストプラクティスを、現場で特に効くものに絞って整理したものです。

6-1. ルートユーザーは日常利用しない

ルートユーザーは、AWSアカウント内のすべての操作が可能な非常に強い権限を持ちます。MFAを設定したうえで認証情報を厳重に管理し、日常業務では使用しないようにしましょう。

6-2. 最小権限の原則を徹底する

最小権限の原則とは、「業務に必要な権限だけを、必要な範囲で与える」という考え方です。最初から強い権限を配ると、事故や不正の被害が大きくなります。「とりあえず全部許可（管理者権限）」を避け、必要になったら足していく運用が安全です。

6-3. 人にもワークロードにも一時的な認証情報を使う

人間の利用者にはIDプロバイダーと連携した一時的な認証（フェデレーション）やIAM Identity Centerを、EC2やLambdaなどのサービス（ワークロード）にはIAMロールを割り当てます。長期間有効なアクセスキーを極力作らないことが、漏えいリスクを根本から減らします。

6-4. MFAを有効にする

IAMユーザーやルートユーザーを使う場面では、MFAを有効にします。MFAは追加コストを抑えながら、不正ログインのリスク低減に有効な対策です。設定していないユーザーがいないか定期的に確認しましょう。

6-5. IAM Access Analyzerで点検する

IAM Access Analyzerは、意図しない外部アクセスの検出、ポリシーの検証、アクセス履歴に基づくポリシー生成などに役立つAWSの機能です。権限が膨らみがちな運用フェーズで特に役立ちます。利用条件や料金の扱いは機能によって変わる場合があるため、導入時はAWS公式の最新情報を確認してください。

やること	目的	優先度
ルートユーザーにMFA設定＋日常利用しない	最も強い権限の悪用を防ぐ	最優先
最小権限でポリシーを設計	事故・不正の被害を最小化	高
人・サービスとも一時的な認証情報を活用	アクセスキー漏えいリスクを下げる	高
権限の強いユーザーにMFAを必須化	パスワード漏えい時の不正ログイン防止	高
未使用の権限・ユーザーを棚卸し	攻撃対象（リスク）を減らす	中

7. IAMの料金は？ IAM Identity Centerとの違い

7-1. IAM自体は無料

結論として、IAM自体は追加料金なしで利用できます。AWS公式のFAQでも「IAM is offered at no additional charge（IAMは追加料金なしで提供される）」と明記されています（AWS IAM よくある質問（公式））。ただし、IAMで認証・認可したうえで利用するEC2、S3、LambdaなどのAWSサービスには、それぞれ通常の利用料金が発生します。

7-2. IAM Identity Centerとの違い

IAMはAWSリソースへのアクセス権限を管理する基本サービス、IAM Identity Centerは複数のAWSアカウントやアプリケーションへのシングルサインオンを一元管理するサービスです。

1つのアカウント内の権限管理がIAM、複数アカウントをまたいだログインの一元管理がIAM Identity Center、というイメージです。シングルサインオン（一度のログインで複数サービスを使える仕組み）を使い、組織で多数のアカウントを運用する段階で重要になります。

8.よくある質問（FAQ）

Q1. IAMユーザーとルートユーザーの違いは何ですか？

ルートユーザーはアカウント作成時に作られる、すべての操作が可能な非常に強い権限のユーザーです。IAMユーザーは、必要な権限だけを与えて作る個別のユーザーです。ルートユーザーは日常業務では使わず厳重に管理し、通常はIAM Identity Centerや一時的な認証情報を使うのが現在の推奨です。

Q2. IAMユーザーはもう使わない方がよいですか？

完全に使えないわけではありませんが、人間の利用者にはIAM Identity Centerや外部IDプロバイダー連携を使い、一時的な認証情報でアクセスさせる方法が推奨されています。IAMユーザーは、フェデレーションが使えない特定のケースなどに限定して利用しましょう。

Q3. IAMロールとIAMユーザーはどう使い分けますか？

「一時的に権限を借りる」「サービス間連携をする」場合はロール、「長期的な認証情報が必要な限定的な場面」ではユーザーです。EC2からS3を操作させたい場合や、人間が一時的にアクセスする場合はロールを使います。近年はセキュリティ上、人にもロール（一時認証）を使わせる流れが主流です。

Q4. IAMの利用に料金はかかりますか？

IAM自体は追加料金なしで利用できます（AWS公式FAQで明記）。ただしIAM経由で使うEC2やS3などのサービスには、各サービスの料金が発生します。

Q5. IAMポリシーでAllowしたのにアクセスできないのはなぜですか？

AWSでは明示的なDenyがAllowより優先されます。また、SCP、権限境界、リソースベースポリシーなど、他の制御によって拒否されている場合もあります。許可設定だけでなく、拒否設定がないかを確認しましょう。

Q6. IAM Identity CenterとIAMの違いは何ですか？

IAMはAWSリソースへのアクセス権限を管理する基本サービスです。IAM Identity Centerは、複数のAWSアカウントやアプリケーションへのシングルサインオンを一元管理するサービスです。組織で複数アカウントを運用する場合は、IAM Identity Centerの利用が重要になります。

Q7. MFAの設定は必須ですか？

仕様上は必須ではありませんが、実務上は必須と考えてください。特にルートユーザーや権限の強いユーザーには、AWS公式も推奨しています。追加コストを抑えて不正ログインのリスクを下げられるため、設定しない理由はほぼありません。

まとめ｜IAMはAWSセキュリティの土台

IAMは、AWSのセキュリティを支える土台です。ユーザー、グループ、ロール、ポリシーの違いを理解することは大切ですが、実務ではさらに「長期的な認証情報を減らす」「一時的な認証情報を使う」「最小権限を徹底する」という考え方が重要になります。

本記事のポイントをまとめます。

AWS IAMとは、「誰が・何に・何をできるか」を管理するアクセス管理サービス。AWSを安全に使うための土台
構成要素は4つ。ユーザー（長期認証情報を持つID）・グループ（束ね）・ロール（一時的な権限）・ポリシー（権限の中身）
現在の推奨は、人間の利用者にはIAM Identity Center／フェデレーションで一時的な認証情報を使うこと。IAMユーザーは限定利用
ポリシーはJSONで書かれ、Effect・Action・Resourceの3要素で読める。判定は単純な足し算ではなく、明示的Denyが常に優先される
ベストプラクティスの軸は、ルート非日常利用・最小権限・一時認証情報・MFA・定期点検
IAM自体は無料。複数アカウント管理にはIAM Identity Centerを使う

まずは、ルートユーザーを厳重に管理し、MFAを設定すること。そして、人間の利用者にはIAM Identity Centerやフェデレーションを使い、ワークロードにはIAMロールを割り当てること。この基本を押さえるだけでも、AWS環境の安全性は大きく高まります。