IAM グループを使うべき理由：ユーザーへの直接ポリシーアタッチとの比較
新しい開発者が入社するたびに、IAM ユーザーを作成してポリシーを一枚一枚アタッチしていた運用が、ある日突然破綻する。10人のユーザーに同じポリシーを直接アタッチしていた環境で権限変更が必要になったとき、10回の手作業が発生する。IAM グループはこの問題を構造的に解決するための仕組みだ。 TL;DR：IAM グループ vs. ユーザーへの直接アタッチ 観点 ユーザーへの直接アタッチ IAM グループ経由 権限変更のコスト 対象ユーザー数分の操作が必要 グループポリシーを1回変更するだけ 新規ユーザーへの権限付与 毎回ポリシーを手動アタッチ グループに追加するだけ 権限の一貫性 ユーザーごとにズレが生じやすい グループ単位で統一される 監査・レビューのしやすさ ユーザーごとに確認が必要 グループのポリシーを見れば全体像が分かる IAM ポリシー上限への影響 ユーザーあたりのアタッチ上限を消費 グループ側で集約できる IAM グループの仕組みを理解する IAM グループはユーザーの集合体であり、それ自体がプリンシパルとして AWS リソースにアクセスするわけではない。グループにアタッチされたポリシーは、そのグループに所属するすべての IAM ユーザーに対して有効になる。ユーザーが複数のグループに所属している場合、各グループのポリシーはすべて評価される。 重要な点として、IAM グループは IAM ロールとは異なり、フェデレーションユーザーや AWS サービスに対してアタッチすることはできない。また、グループをネストする（グループの中にグループを入れる）ことも IAM ではサポートされていない。 graph TD GroupDev["IAM グループ: Developers"] GroupOps["IAM グループ: Operators"] PolicyS3["ポリシー: S3ReadOnly"] PolicyEC2["ポリシー: EC2FullAccess"] ...