はじめに
こんにちは、開発部の一筒です。AWSを学んでいく上で、多くの初心者が最初にぶつかる壁が IAM（Identity and Access Management) です。
「ユーザーを作成したのに、なぜかコンソールにログインできない」
「EC2に権限を付与したいのに、ユーザーとロールどちらを使えばいいのかわからない」
このような悩みを持っている方も多いのではないでしょうか。実は、この混乱はIAMの基本的な考え方を理解していないために起こります。
この記事では、初心者が本当につまずく部分にフォーカスして、IAMの全体像をシンプルに説明します！
IAMの基本的な考え方
IAMとは「AWSのサービスに対して、誰が何ができるかを管理するシステム」です。
ここで重要な点は「誰が」という部分です。IAMでは以下の2つを区別しています。
・人間（AWSのコンソールにログインする人）
・もの（EC2やLambdaなどのAWSリソース）
この区別を理解できていないと、IAMの設定で迷子になってしまいます。
ユーザーとは何か
IAMユーザーの正体
IAMユーザーは、AWSコンソールにログインする人を表現するための存在です。
例えば、あなたの会社のAWS環境に新しい社員が入ってきたとします。その人がAWSコンソールにアクセスして「EC2を起動したい」「RDSのデータベースを確認したい」といった作業をするために必要なのがIAMユーザーです。
ユーザーにできること、できないこと
ユーザーに権限を付与する方法はポリシーをアタッチすることです。
ユーザー → ポリシーをアタッチ → 「S3のバケットを読み取る」「EC2を起動する」
などの権限を獲得
ここで初心者がよくやってしまう間違いが、ユーザーを作成した後の権限設定を忘れることです。
「ユーザーを作成したのにログインできない」という問題の大半は、以下のいずれかです。
・ユーザーにパスワードを設定していない
・ユーザーに対してポリシーをアタッチしていない
・正しくないポリシーをアタッチしている
つまり、ユーザー作成は第一ステップに過ぎず、ポリシーをアタッチして初めて「何ができるのか」が決まるということです。
ロールとは何か
ロールの正体
ロールは、一見するとユーザーと似ていますが、全く異なる用途を持っています。
ロールは 「AWSリソース（もの）が他のAWSサービスにアクセスするための権限を与える仕組み」 です。
具体例で説明します。あなたがLambda関数を作成して、その関数がS3のファイルを読み取りたい場面を想像してください。
Lambda関数は「人間」ではなく「もの」です。このもの（Lambda）が別のサービス（S3）にアクセスするためには、S3へのアクセス権限が必要です。この権限を与えるために使うのがロールです。
Lambda（もの）→ ロールをアタッチ → S3にアクセスするための権限を獲得
ユーザーとロールの決定的な違い
以下のように整理してください。
ユーザー
誰向けか：人間
どこでログイン：AWSコンソール、APIアクセスキー
使う場面：開発者、管理者がAWSを操作するとき
ロール
誰向けか：AWSリソース（EC2、Lambda、その他）
どこでログイン：リソースが自動的に受け取る一時的な認証情報
使う場面：あるAWSサービスが別のAWSサービスにアクセスするとき
実践的なシナリオで学ぶ
① 新しい開発者をプロジェクトに追加したい
あなたの会社に新しい開発者が入ってきました。
この人がAWSコンソールでEC2を起動したり、RDSを確認したりするには、
以下の2つのステップを実行します。
ステップ1：ユーザーを作成
IAMダッシュボードから新しいユーザーを作成します。
ステップ2：ポリシーをアタッチ
「EC2を操作できる」「RDSを閲覧できる」などのポリシーをアタッチします。
② EC2インスタンスがS3のファイルを読み取りたい
あなたがEC2インスタンスを起動して、そのインスタンス上で動いているアプリケーションがS3から設定ファイルを読み込みたいとします。
ステップ1：ロールを作成
IAMダッシュボードから新しいロールを作成します。ここで「EC2」を信頼するエンティティとして指定します。
ステップ2：ポリシーをアタッチ
ロールに対して「S3の特定のバケットを読み取る」というポリシーをアタッチします。
ステップ3：EC2インスタンスにロールをアタッチ
起動したEC2インスタンスに対して、先ほど作成したロールをアタッチします。これで、インスタンス上のアプリケーションは自動的にS3にアクセスできるようになります。
よくある誤解と対策
誤解1：「ユーザーをEC2にアタッチできるだろう」
初心者がよくやってしまう間違いです。EC2インスタンスにアタッチできるのはロールだけです。ユーザーをアタッチしようとしても、AWSのコンソールではそもそもそういう選択肢は出てきません。
重要なのは、誰が（人間か、もの か）によって、使う方法が決まるということです。
誤解2：「ロールには誰がログインするのか」
ロールには誰もログインしません。ロールはあくまで「権限のセット」であり、AWSリソースが自動的に使用する一時的な認証情報です。人間がログインする必要はありません。
誤解3：「権限を付与したのに、なぜアクセスできないのか」
IAMの重要な原則が 「明示的な許可がない限り、すべてはデフォルトで拒否される」 ということです。これを「デフォルト拒否の原則」と言います。
つまり、ユーザーやロールにポリシーをアタッチしても、そのポリシーが「本当に必要な権限」を含んでいなければアクセスできません。例えば、「AmazonEC2ReadOnlyAccess」というポリシーをアタッチしても、S3へのアクセスはできません。
さいごに
IAMは複雑に見えますが、「人間」と「もの」という軸で考えると、ぐっとシンプルになります。基本的な考え方が身につけば、AWSを安全かつ効果的に運用できるようになります。
少しでもご参考になれば幸いです
はつかぜ株式会社では、IT学習や業務に役立つ情報を定期的にお届けしていきたいと思っています。システム開発のお問い合わせ・ご相談はこちら
https://www.hatsukaze.co.jp/inquire/