AWS Identity and Access Management

AWSで「誰に、どの操作を許可するか」を管理するセキュリティの基本サービス。

AWSリソースへのアクセス権限を管理するサービス。ユーザー、グループ、ロール、ポリシーを使って、誰が何を操作できるかを制御する。

• 管理者・開発者の権限管理
• LambdaやEC2に付与する実行ロール管理
• 最小権限のポリシー設計

• rootユーザーの日常利用は避ける
• IAMユーザーにはMFAを設定する
• IAMロールはAWSサービスや外部ID連携に権限を委任する

• アプリケーションからAWSサービスへアクセスする場合はアクセスキー直書きではなくIAMロールを使う
• 権限はActionとResourceを絞る
• クロスアカウントアクセスでは信頼ポリシーを理解する

AWS Identity and Access Management（IAM）は、AWS リソースへのアクセスを認証・認可する ためのサービスである。IAM ユーザー、IAM グループ、IAM ロール、IAM ポリシーという 4 つの要素を組み合わせて、「誰が、どの AWS リソースに対して、どの操作を許可されているか」 を制御する。IAM ポリシーは JSON 形式で記述し、Action（許可・拒否する API 操作）と Resource（対象リソース）と Condition（追加条件）を指定する。 IAM ロールは、IAM ユーザーに直接付与するのではなく、AWS サービス（EC2、Lambda など）、 別 AWS アカウント、外部 ID 連携（SAML / OIDC）などに対して権限を委任する仕組みである。 たとえば Lambda 関数が S3 にオブジェクトを書き込む場合、関数にアクセスキーを直書きする のではなく、S3 への PutObject 権限を持つ IAM ロールを Lambda に割り当てて利用する。 これによりアクセスキーの漏洩リスクを抑え、キーローテーションの運用負荷も減らせる。 CLF-C02 では root ユーザーと IAM ユーザーの違い、MFA の重要性、最小権限の原則、IAM ロールによる権限委任が頻出論点となる。SAA-C03 以降ではクロスアカウントアクセスにおける 信頼ポリシーの設計、IAM ポリシーと S3 バケットポリシー・KMS キーポリシーの優先順位、 IAM Identity Center を使った組織横断のシングルサインオンなど、より踏み込んだ設計が 問われる。IAM 自体の利用に追加料金はかからないが、権限ミスによる不要リソース作成や 意図しない API 呼び出しは課金事故につながるため、運用設計の重要度は高い。

• AWS Identity and Access Management とは（AWS公式ドキュメント）↗
• IAM ロール（AWS公式ドキュメント）↗
• IAM のセキュリティのベストプラクティス（AWS公式ドキュメント）↗

最終更新日：2026-06-19