こんにちは～ 浮田です。
AWS を触りはじめて最初にぶつかる壁、それが IAM だと思っています。
ユーザー、グループ、ロール、ポリシーなど似たような言葉が 4 つも出てきて、正直なところ私も最初は「とりあえず権限つけとけば動くでしょ」くらいの感覚で乗り切っていました。
でも、なんとなくで権限を渡していると、あとで必ず「これ誰がなんで持ってるの？」を調べる時間が発生します（しました）。
結論を先に言うと、登場人物は 4 人だけで、それぞれの役割さえ掴めばポリシーの JSON も実質 3 行で読めるようになります。後半では実際に IAM ユーザーを作る手順まで通します。
■ そもそも IAM って？（認証と認可）
IAM（Identity and Access Management）は、ひとことで言うと AWS の入館証システムです。
無料で、すべての AWS アカウントに最初から入っています。
やっていることは 2 つだけです。
会社の入館証でたとえると分かりやすいです。
ゲートでカードをかざして本人確認されるのが認証、そのカードでどの部屋のドアが開くかが認可。
「入館できること」と「金庫室に入れること」は別の話。これが IAM の全てです。
＜補足：英語だとどちらも Auth で始まるので混同しやすいですが、AuthN（認証）/ AuthZ（認可）と略し分ける習慣があります。＞
IAM の用語が覚えにくいのは、役割ではなく名前で覚えようとするからだと思っています。
まず対応表を置きます。
|
登場人物 |
たとえ |
役割 |
認証情報 |
|
IAMユーザー |
社員本人 |
個人・アプリの ID |
持つ（パスワード / アクセスキー） |
|
IAMグループ |
部署 |
ユーザーをまとめる箱 |
持たない |
|
IAMロール |
借り物の腕章 |
一時的な権限の貸し出し |
持たない（一時認証情報） |
|
IAMポリシー |
ルールブック |
許可 / 拒否の定義（JSON） |
— |
コンソールにログインする個人や、プログラムからアクセスするアプリケーションに割り当てる ID です。パスワード（コンソール用）とアクセスキー（CLI / SDK 用）という長期の認証情報を持てるのが特徴で、あとで書きますが、実はこの「長期」というところが現在の AWS 的には悩ましいポイントになっています。
ユーザーをまとめる箱です。グループにポリシーをアタッチすると、所属メンバー全員に権限が適用されます。「Developers 部署に入った人は自動的に開発用の部屋に入れる」感覚ですね。人が増えるたびに個別に権限を配るのは辞令を一人ずつ手書きするようなものなので、権限は原則グループに付けるのがラクです。
ロールは「一時的に借りる権限の腕章」です。EC2 や Lambda がこの腕章を借りて仕事をし、終わったら（正確には有効期限が切れたら）自動的に返します。
何がすごいかというと、ロールはパスワードもアクセスキーも持ちません。腕章を借りている間だけ有効な一時認証情報が発行されるだけ。
つまり「サーバーにアクセスキーをベタ書きして、それが漏れて大惨事」というお約束の事故が、構造的に起きようがないんです。
「何を許可 / 拒否するか」を JSON で書いた文書です。ユーザー・グループ・ロールにアタッチして初めて効きます。AWS があらかじめ用意している AWS 管理ポリシー（AmazonS3ReadOnlyAccess など）と、自分で書くカスタマー管理ポリシーの 2 種類があります。最初は管理ポリシーで十分です。
JSON と聞くと身構えますが、読むのは実質 3 行です。S3 の読み取りだけを許可するポリシーを貼ります。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": "*"
}
]
}
▲ 読むのは Effect / Action / Resource の 3 つだけ。Version の日付は固定のおまじないです（自分で今日の日付に変えないでください。私は最初変更してました）
|
行 |
意味 |
この例では |
|
Effect |
許可か拒否か |
Allow（許可） |
|
Action |
何を |
S3 のオブジェクト取得と一覧 |
|
Resource |
どれに対して |
*（すべてのバケット） |
ここで最初の勘違いポイントを 1 つ。
この JSON のどこにも「誰が」は書いてありません。
「誰が」はポリシーの中身ではなく、どこにアタッチしたかで決まります。
同じルールブックでも、渡す相手によって効く相手が変わる、というだけの話です。
細かい推奨事項は山ほどありますが、最初に守るのは 4 つで十分だと思っています。
3 と 4 は要するに同じことを言っています。
「長期の認証情報を、なるべくこの世に存在させない」
AWS の推奨は全部この一本の軸で読めると思ってます。
ここからが手順……の前に、但し書きを 1 つ。
2026 年現在、AWS は人間のコンソールアクセスには IAM ユーザーではなく IAM Identity Center（旧 AWS SSO）を推奨しています。
IAM ユーザー作成画面にもその旨の案内が出ます。
「これから IAM ユーザーの作り方を解説する記事」としてはやや気まずい事実ですが、隠しても仕方ないので先に整理しておきます。
|
ケース |
IAM ユーザー |
|
社員が日常的にコンソールへログイン |
❌ Identity Center 推奨 |
|
Identity Center が使えない環境・組織 |
✅ |
|
サードパーティツール連携（長期キーが必須のもの） |
✅（ただし定期ローテーション） |
|
個人の検証・学習用アカウント |
✅ 現実的な選択 |
なぜ推奨が変わったのか。ちょっと考えてみます。
IAM ユーザーの本質は「長期の認証情報を持てる ID」で、それはつまり漏えいリスクの塊を常設するということだからです。
Identity Center なら人間のログインも一時認証情報ベースになる。
さっきの「長期の認証情報をこの世に存在させない」そのままですね。
とはいえ、個人の学習用途やツール連携では IAM ユーザーが現実解であることも多いです。
「使ってはいけない」ではなく「使いどころを選ぶ」が正しい理解だと思います。
ここからは手を動かします。マネジメントコンソールでの手順です。
コンソール上部の検索で「IAM」を検索 → 左メニュー「ユーザー」→「ユーザーの作成」をクリック。
ユーザー名を入力します。
コンソールにログインさせたい場合は「AWS マネジメントコンソールへのユーザーアクセスを提供する」にチェックを入れ、「IAM ユーザーを作成します」を選択。
ここで例の「Identity Center を推奨します」の案内が出ますが、今回は学習用途なので IAM ユーザーで進めます。
パスワードは自動生成か手動設定を選び、「次回サインイン時に新しいパスワードの作成を要求する」は他人用に作るならチェック推奨です。
方式は 3 つから選べます。
推奨はグループ経由です。
理由は単純で、直接アタッチを重ねると「この人なんでこの権限持ってるんだっけ？」の棚卸しが地獄になるからです。
今回は コミュニティのGAWSに参加するひと向けに作成するので、すでに作成されてるユーザーグループを選択します。
内容を確認して「ユーザーの作成」。
完了画面にコンソールのサインイン URL・ユーザー名・初期パスワードが表示されます。
人のユーザーを作成したときはこれらを安全な方法で共有してください。
注意：この画面を閉じると、パスワードは二度と表示できません。 csvファイルをダウンロードしておくと安心です。
csvファイルをダウンロードせずに画面を閉じようとすると警告してくれます。
パスワードは二度と表示できません！ご注意ください。
同じ「セキュリティ認証情報」タブから MFA デバイスを割り当てます。
認証アプリ、パスキー、ハードウェアトークンから選べます。
コンソールログインするユーザーなら必須と思ってください。
デバイス名を入力し、認証方法を選択します。 今回は認証アプリで認証する方法を選択します。
QRコードを表示をクリックした後に、アプリを開き、QRコードを読み込みます。
MFAコードを２つ入力します。
（Authenticatorでは30秒ごとに番号が変わります）
■ 初心者がハマりがちなポイント
|
症状 |
原因 |
対処 |
|
完了画面を閉じてパスワードが分からない |
初期パスワードは再表示不可 |
ユーザー詳細 → セキュリティ認証情報 →「コンソールアクセスを管理」からパスワードをリセット（再発行）できます。 |
|
ログインできたのに「アクセスが拒否されました」だらけ |
ポリシー未アタッチ or グループ入れ忘れ |
ユーザー詳細の「許可」タブで、グループ経由の許可も含めて何が付いているか確認。 |
|
アクセスキーを Git に push しかけた |
~/.aws/credentials ではなくコードにベタ書きした |
そもそもコードに書かない。git-secrets などの検知ツールを入れておくと、うっかりを機械が止めてくれます。漏らした場合は即座にキーを無効化 |
2 つ目は切り分けのコツがあって、「認証は通っている（ログインできた）のに認可で弾かれている」状態なので、疑うべきはパスワードではなくポリシー側です。
認証と認可を分けて考える癖がつくと、エラーを見た瞬間にどっちの話か判別できるようになります。
最後に要点だけ置いておきます。