IAM ロールとIAM ユーザーの違いとは？AWSの権限管理で迷わない使い分けを解説

AWS Identity and Access Management（IAM）を学び始めると、IAM ユーザー、IAM ロール、IAM ポリシーという言葉が出てきます。特に混同しやすいのが、IAM ユーザーとIAM ロールの違いです。

IAM ユーザーは、人に紐づくアマゾンウェブサービス（AWS）上の利用者IDです。AWS Management Consoleへログインする場合はパスワードを使い、AWS Command Line Interface（AWS CLI）や外部ツールから操作する場合はアクセスキーを使います。

一方、IAM ロールは、Amazon EC2やAWS LambdaなどのAWSサービス、アプリケーション、一時的に権限を必要とする対象に権限を関連付ける仕組みです。

AWSサービスから別のAWSリソースへアクセスする場合は、IAM ユーザーのアクセスキーをサーバーやコードに保存せず、IAM ロールを使う設計が基本です。本記事では、IAM ユーザーとIAM ロールの違い、IAM ポリシーとの関係、利用場面ごとの使い分けを解説します。

IAM ユーザーとIAM ロールの違い

IAMは、AWSリソースへのアクセスを管理するサービスです。IAM ユーザーとIAM ロールはどちらも権限管理に関わりますが、権限を使う主体が異なります。

IAM ユーザーは、人に紐づくAWS上の利用者IDです。AWS Management Consoleへのログインや、AWS CLIからの操作に使います。一方、IAM ロールは、Amazon EC2やAWS Lambdaなど、権限を必要とするAWSサービスやアプリケーションに一時的な権限を関連付ける仕組みです。

使い分けの起点は、「人が操作するのか」「AWSサービスやアプリケーションが処理の中で使うのか」です。人がAWSへログインして操作する場合はIAM ユーザーが候補になり、Amazon EC2やAWS Lambdaなどが他のAWSリソースへアクセスする場合はIAM ロールを使います。

IAM ユーザーは人に紐づくAWS上の利用者ID

IAM ユーザーは、管理者、開発者、運用担当者など、AWSを利用する人ごとに作成するIDです。AWS Management Consoleへログインする場合はパスワードを使い、AWS CLIや外部ツールから操作する場合はアクセスキーを使います。

注意したいのは、アクセスキーが固定の認証情報として残る点です。外部に漏れると、第三者にAWSリソースを操作されるおそれがあります。ソースコードに直接書く、複数人で共有する、使わないキーを残す、広い権限を付けたまま運用する、といった状態は避けます。

IAM ユーザーは作成しやすい反面、数が増えるほど管理対象も増えます。発行先、権限、アクセスキーの利用状況を追える状態で管理します。

IAM ロールはAWSサービスなどに一時的な権限を渡す仕組み

IAM ロールは、特定の人に固定されるIDではありません。Amazon EC2、AWS Lambda、アプリケーション、別のAWSアカウントなど、権限を必要とする対象に一時的なセキュリティ認証情報を関連付ける仕組みです。

たとえば、Amazon EC2からAmazon S3のファイルを読み取る場合、Amazon EC2にIAM ロールを関連付けます。アプリケーション内にアクセスキーを保存する必要はありません。AWS LambdaからAmazon DynamoDBにアクセスする場合も、Lambda関数の実行ロールに必要な権限を設定します。

IAM ロールでは、「どの対象に、どの操作を許可するか」を明確にします。Amazon S3の読み取りだけで足りるなら、書き込みや削除の権限は不要です。必要な操作に絞れば、誤操作や不正利用が起きた場合の影響範囲を限定できます。

IAM ユーザーとIAM ロールの使い分け

IAM ユーザーとIAM ロールは、「誰がAWSを操作するのか」と「認証情報をどこで管理するのか」で判断します。人がAWS Management Consoleにログインする場合はIAM ユーザーが候補になります。一方、Amazon EC2やAWS Lambdaなどのサービスが別のAWSリソースへアクセスする場合は、IAM ロールを使います。

アクセスキーをサーバーやコードに保存する設計は、漏えいや放置のリスクを残します。サービスに権限を付与する場面では、まずIAM ロールで代替できないかを確認します。

人が使う場合はIAM ユーザーが候補になる

管理者、開発者、運用担当者など、人がAWSを操作する場合はIAM ユーザーが候補になります。AWS Management Consoleへのログインにはパスワードを使い、AWS CLIや外部ツールからの操作にはアクセスキーを使います。

ただし、IAM ユーザーは作成して終わりではありません。利用者ごとに権限を分け、多要素認証（MFA）を設定し、不要になったユーザーやアクセスキーは削除します。担当変更や退職後のユーザーが残ると、管理されていない入口がAWS環境に残ります。

企業で複数人がAWSを利用する場合は、IAM ユーザーを個別に増やすだけでなく、AWS IAM Identity Centerの利用も検討します。利用者が増えても、ログイン方法と権限を一元的に管理できます。

AWSサービスが使う場合はIAMロールを使う

Amazon EC2やAWS Lambdaなどのサービスが、Amazon S3やAmazon DynamoDBなどへアクセスする場合はIAM ロールを使います。サービスにIAM ロールを関連付け、必要な操作だけを許可します。

Amazon EC2上のアプリケーションがAmazon S3のファイルを読み取る場合は、Amazon EC2にIAM ロールを関連付けます。インスタンス作成時や設定変更時にロールを選択すれば、アプリケーション側にアクセスキーを保存する必要はありません。

AWS LambdaからAmazon DynamoDBにデータを書き込む場合も、Lambda関数に実行ロールを設定します。コード内にアクセスキーを書かず、対象テーブルへの書き込み権限だけを付与できます。

固定の認証情報をサーバーやコードに残さない点が、IAM ロールを使う最大の理由です。

アクセスキーを使う場合は管理に注意する

アクセスキーは、AWS CLIや外部ツールからAWSを操作する際に使う認証情報です。便利な反面、扱いを誤るとAWS環境への不正アクセスにつながります。

避けるべきなのは、ソースコードへの直書き、複数人での共有、未使用キーの放置、強すぎる権限を付けたままの運用です。特に、長期間使い続けるアクセスキーは、担当者変更や運用変更のあとに残りやすくなります。

アクセスキーを使う場合は、用途、利用者、権限範囲を明確にします。必要な操作だけを許可し、不要になった時点で削除します。AWSサービスからAWSリソースへアクセスする用途なら、発行前にIAM ロールで代替できないかを確認します。

IAMポリシーとの関係

IAM ユーザーやIAM ロールは、権限を持たせる対象です。実際に許可する操作は、IAM ポリシーで定義します。

Amazon S3のファイルを読み取る、Amazon EC2を起動する、Amazon DynamoDBにデータを書き込む、といった操作内容はIAM ポリシーで決まります。IAM ユーザーやIAM ロールを作成しただけでは、AWSリソースを操作できません。

IAMポリシーは許可する操作を決めるもの

IAM ポリシーは、AWSリソースに対して許可する操作を記述した設定です。Amazon S3の特定バケットだけを読み取れるようにする、Amazon EC2の起動や停止を許可する、といった制御に使います。

権限を考えるときは、「誰に持たせるか」と「何を許可するか」を分けます。IAM ユーザーやIAM ロールは権限を持たせる対象、IAM ポリシーはその対象に許可する操作を決める設定です。

同じAmazon S3へのアクセスでも、開発者がAWS CLIから操作するならIAM ユーザーにポリシーを設定します。Amazon EC2上のアプリケーションからアクセスするなら、Amazon EC2に関連付けたIAM ロールにポリシーを設定します。操作対象が同じでも、使う主体によって設定先が変わります。

IAM ユーザーにもIAM ロールにも設定できる

IAM ポリシーは、IAM ユーザーにもIAM ロールにも設定できます。IAM ユーザーに設定すれば、そのユーザーが許可された操作を実行できます。IAM ロールに設定すれば、そのロールを利用するAWSサービスやアプリケーションが操作を実行します。

避けたいのは、迷ったときに広い権限を付けることです。Amazon S3の読み取りだけで足りる処理に、書き込みや削除の権限は不要です。Amazon DynamoDBにデータを書き込む処理なら、対象のテーブルと必要な操作に絞って許可します。

開発、運用、監視では必要な操作が異なります。IAM ユーザーでもIAM ロールでも、用途を先に決め、その範囲だけをIAM ポリシーで許可します。

IAMロールの利用が推奨される理由

AWSサービスに権限を付与する場面では、IAM ユーザーのアクセスキーではなく、IAM ロールを使います。固定の認証情報をサーバーやコードに残さず、必要な権限をサービス側に関連付けられるためです。

Amazon EC2上のアプリケーションからAmazon S3にアクセスする場合、アクセスキーをOSやアプリケーションに保存する方法でも動作はします。ただし、キーがソースコード、設定ファイル、共有フォルダなどに残ると、漏えいや不正利用のリスクが発生します。担当者変更後に、使われないキーが放置されるケースもあります。

IAM ロールを使えば、Amazon EC2やAWS Lambdaなどの実行環境に必要な権限を関連付けられます。認証情報は一時的なセキュリティ認証情報として扱われるため、固定のアクセスキーを長期保管する必要がありません。

長期的なアクセスキーを持たせずに済む

アクセスキーは、AWS CLIや外部ツールからAWSを操作する際に使う認証情報です。人が操作する用途では必要になる場面もありますが、AWSサービスに権限を与える用途では、管理上のリスクが大きくなります。

Amazon EC2からAmazon S3にアクセスする場合は、Amazon EC2にIAM ロールを関連付けます。インスタンス作成時や設定変更時にロールを選択すれば、アプリケーション側でアクセスキーを保持する必要はありません。

AWS Lambdaでも、関数に実行ロールを設定します。コード内にアクセスキーを書かず、実行ロールに付与された権限でAmazon DynamoDBなどへアクセスします。

AWSサービスに必要な権限だけを付与できる

IAM ロールでは、サービスごとに必要な権限を分けて設定できます。Amazon EC2からAmazon S3のファイルを読み取るだけでよい場合は、対象のS3バケットへの読み取り権限に絞ります。書き込みや削除の権限は不要です。

AWS LambdaからAmazon DynamoDBにデータを書き込む場合も、対象のテーブルと必要な操作だけを許可します。関係のないAWSサービスやリソースまで操作できる権限を付けると、誤操作や不正利用が起きたときの影響範囲が広がります。

IAM ロールの目的は、アクセスキーを避けることだけではありません。権限管理では、「動くこと」よりも、「どのサービスが、どのリソースに、どの操作を許可されているか」を説明できる状態が求められます。

IAM ユーザーとIAM ロールの使い分け例

IAM ユーザーとIAM ロールは、利用場面で使い分けます。AWSサービスが別のAWSリソースへアクセスする場合はIAM ロール、人や外部ツールがAWSを操作する場合はIAM ユーザーやアクセスキーの扱いを確認します。

Amazon EC2からAmazon S3にアクセスする場合

Amazon EC2からAmazon S3にアクセスする場合は、IAM ロールを使います。

Amazon EC2上のアプリケーションがAmazon S3のファイルを読み取るなら、Amazon EC2にIAM ロールを関連付けます。インスタンス作成時や設定変更時にIAM ロールを選択し、そのロールに対象のS3バケットを読み取るためのIAM ポリシーを設定します。

この構成では、Amazon EC2のOS上やアプリケーションの設定ファイルにアクセスキーを保存しません。アプリケーションは、Amazon EC2に関連付けられたIAM ロールの権限でAmazon S3へアクセスします。

避けたいのは、IAM ユーザーのアクセスキーをAmazon EC2内に保存する構成です。キーが漏れたり、不要になったあとも残ったりすると、不正利用の入口になります。

AWS LambdaからAmazon DynamoDBにアクセスする場合

AWS LambdaからAmazon DynamoDBにアクセスする場合も、IAM ロールを使います。

AWS Lambdaには、実行ロールを設定します。この実行ロールに、Amazon DynamoDBの対象テーブルへアクセスするためのIAM ポリシーを付与します。読み取りだけで足りる処理なら読み取り権限に絞り、書き込みが必要な処理では書き込み権限を加えます。

コード内にアクセスキーを書く必要はありません。AWS Lambdaは、設定された実行ロールの権限でAmazon DynamoDBへアクセスします。

サーバーレス構成では、関数ごとに必要な権限が異なります。ユーザー登録用、集計処理用、通知送信用の関数では、アクセスするAWSリソースも操作内容も変わります。すべての関数に同じ広い権限を付けるのではなく、処理内容に合わせて権限を分けます。

開発者がAWS Management Consoleにログインする場合

開発者や運用担当者がAWS Management Consoleにログインする場合は、IAM ユーザーが候補になります。IAM ユーザーにはログイン用のパスワードを設定でき、多要素認証（MFA）も有効化できます。

ただし、人がAWSを操作する場合でも、常にIAM ユーザーへ直接権限を付けるとは限りません。複数のAWSアカウントを扱う場合や、通常時の権限と管理者権限を分けたい場合は、スイッチロールを使って一時的に別のIAM ロールへ切り替えることがあります。

スイッチロールでは、ログイン中のユーザーが許可されたIAM ロールに切り替え、そのロールに設定された権限でAWSリソースを操作します。元のユーザー権限と切り替え先ロールの権限が合算されるわけではありません。作業が終われば元の権限に戻せるため、必要な場面だけ強い権限を使う運用に向いています。

企業で複数人がAWSを利用する場合は、IAM ユーザーを個別に増やすだけでなく、AWS IAM Identity Centerの利用も検討します。利用者のログインと権限をまとめて管理でき、担当者が増えた場合や複数のAWSアカウントを扱う場合にも対応しやすくなります。

どの方法を使う場合でも、すべての開発者に強い権限を与えるべきではありません。検証、開発、運用、監視では必要な操作が異なります。AdministratorAccessのような広い権限を最初から付けると、誤操作や設定ミスの影響範囲が広がります。

人が使う権限では、「誰がログインできるか」だけでなく、「どのロールに切り替えられるか」「何を操作できるか」「不要になった利用者や権限が残っていないか」まで管理します。

外部ツールからAWSを操作する場合

外部ツールやスクリプトからAWSを操作する場合、IAM ユーザーのアクセスキーを使うケースがあります。AWS CLIや一部の管理ツールからAWSリソースを操作する場面です。

アクセスキーを使う場合は、用途を明確にします。どのツールで使うのか、どのAWSリソースにアクセスするのか、どの操作を許可するのかを決めたうえで、必要な権限だけを設定します。

避けたいのは、強い権限を持つアクセスキーを長期間使い回すことです。ソースコードに直接書く、複数人で共有する、担当変更後も残す、といった運用はリスクになります。

外部ツールからの操作でも、利用方法によってはIAM ロールや一時的な認証情報を使える場合があります。特に、AWS上で動く処理からAWSリソースへアクセスする用途であれば、アクセスキーを発行する前にIAM ロールで代替できないかを確認します。

IAM ユーザーとIAM ロールを使うときの注意点

IAM ユーザーとIAM ロールは、作成後の管理まで含めて設計します。作る数が増えすぎると管理漏れが起き、権限を広く付けすぎると誤操作や不正利用の影響範囲が広がります。

IAM ユーザーを増やしすぎない

IAM ユーザーは利用者ごとに作成できますが、数が増えるほど管理は複雑になります。誰がどの権限を持ち、どのアクセスキーを使っているのかを追いにくくなるためです。

特に問題になるのは、使われなくなったIAM ユーザーやアクセスキーの放置です。担当変更や退職後もIAM ユーザーが残っていると、AWS環境への入口が残ります。アクセスキーを発行していた場合は、そのキーが今も使われているのか、削除してよいのかも確認しなければなりません。

IAM ユーザーを作成する場合は、利用者、用途、権限範囲を明確にします。不要になったIAM ユーザーやアクセスキーは削除し、定期的に棚卸しします。

企業で複数人がAWSを使う場合は、IAM ユーザーを個別に増やすだけでなく、AWS IAM Identity Centerなどを使ってログインや権限をまとめて管理する方法も検討します。

権限を広く付けすぎない

IAM ユーザーやIAM ロールには、必要な操作だけを許可します。最初から広い権限を付けると設定は楽ですが、誤操作や不正利用が起きたときの影響範囲が広がります。

たとえば、Amazon S3のファイルを読み取るだけでよい場合、書き込みや削除の権限は不要です。Amazon DynamoDBにデータを書き込む処理であれば、対象のテーブルと必要な操作に絞って権限を設定します。

AdministratorAccessのような強い権限は、特に慎重に扱います。検証時に一時的に使った権限をそのまま本番環境で使い続けると、本来不要な操作まで許可された状態になります。

権限を設定するときは、「誰が使うのか」「どのAWSリソースにアクセスするのか」「どの操作を許可するのか」を確認します。IAM ユーザーでもIAM ロールでも、用途に対して過剰な権限は持たせません。

まとめ

IAM ユーザーは人に紐づくID、IAM ロールはAWSサービスやアプリケーションに一時的な権限を関連付ける仕組みです。Amazon EC2やAWS Lambdaなどから別のAWSリソースへアクセスする場合は、IAM ロールを使います。

権限の内容はIAM ポリシーで設定します。IAM ユーザーにもIAM ロールにも設定できますが、許可する操作は必要な範囲に絞ります。

人がAWSを操作する場合はIAM ユーザーが候補になります。ただし、複数人で利用する環境では、AWS IAM Identity Centerなどを使った管理方法も検討します。アクセスキーの放置や過剰な権限を避け、用途に合わせて使い分けます。