🔐 AWS マネージドポリシー vs カスタマーマネージドポリシー

IAMポリシーの2つの管理方式を徹底比較！初心者でもわかる完全ガイド

📚 AWS IAM 基礎知識

🎯 たとえ話で理解しよう！「既製服 vs オーダーメイド」

👔
既製服（プレタポルテ）

デパートで売っている完成品の服。
サイズは決まっているけど、すぐ着られる！

= AWS マネージドポリシー
VS
✂️
オーダーメイドスーツ

自分の体型に合わせて仕立てる服。
ぴったりだけど、時間と知識が必要！

= カスタマーマネージドポリシー
💡 ポイント： 既製服（AWSマネージド）は「すぐ使える便利さ」、オーダーメイド（カスタマーマネージド）は「自分にぴったりのフィット感」が魅力です！
🏢
AWS マネージドポリシー
AWSが作成・管理するポリシー
  • 🏭
    AWSが作成・更新 AWSのエキスパートが設計し、サービス変更時も自動更新される
  • 📦
    すぐに使える 数百種類のポリシーが最初から用意されている
  • 🔄
    自動メンテナンス 新機能追加や仕様変更に合わせてAWSが自動更新
  • 🔒
    編集不可 内容の変更はできない（読み取り専用）
  • 📋
    代表例 AdministratorAccess, ReadOnlyAccess, PowerUserAccess など
🛠️
カスタマーマネージドポリシー
ユーザーが作成・管理するポリシー
  • 👤
    自分で作成・管理 組織の要件に合わせて自由にカスタマイズ可能
  • ✏️
    完全にカスタマイズ可能 必要な権限だけを精密に設定できる
  • 📊
    バージョン管理 最大5バージョンまで保持、ロールバック可能
  • 🎯
    最小権限の原則 必要最低限の権限だけを付与できる
  • 📋
    命名例 MyCompany-S3ReadOnly, Dev-EC2Access など

🔗 IAMにおけるポリシーの位置づけ

👤 IAMユーザー/ロール/グループ
⬅️ アタッチ
🏢 AWSマネージドポリシー
👤 IAMユーザー/ロール/グループ
⬅️ アタッチ
🛠️ カスタマーマネージドポリシー
📎
両方アタッチ可能
1つのユーザー/ロールに両タイプのポリシーを混在して使用できます
🔢
最大10ポリシー
1つのIAMエンティティにアタッチできるマネージドポリシーは最大10個
➕
権限は合算
複数ポリシーをアタッチすると、許可された権限がすべて有効になります

📊 詳細比較表

項目 🏢 AWSマネージドポリシー 🛠️ カスタマーマネージドポリシー
作成者 AWS お客様（あなた）
編集可否 ❌ 編集不可 ✅ 自由に編集可能
更新管理 ✅ AWSが自動更新 ⚠️ 自分で管理が必要
バージョン管理 AWSが管理（ユーザーは制御不可） ✅ 最大5バージョン保持
削除 ❌ 削除不可 ✅ 削除可能
再利用性 ✅ 全AWSアカウントで共通 作成したアカウント内のみ
最小権限の原則 ⚠️ やや過剰な権限になりがち ✅ 精密に制御可能
セットアップ時間 ✅ 即座に使用可能 ⚠️ 設計・作成が必要
専門知識 ✅ 不要 ⚠️ IAMの知識が必要

🎯 どちらを使うべき？選択フローチャート

❓ 細かい権限制御が必要ですか？
↓
はい ✓
↓
🛠️ カスタマーマネージドポリシー
最小権限の原則に沿って設計
いいえ ✗
↓
❓ 標準的なアクセスパターン？
↓
はい ✓
🏢 AWSマネージドポリシー
ReadOnlyAccess など既存を活用

💼 具体的なユースケース

👨‍💻
開発者にEC2フルアクセス
🏢 AWSマネージド推奨
使用ポリシー： AmazonEC2FullAccess

EC2の全機能を使いたい開発者には、AWSマネージドポリシーで十分。設定の手間なく即座に利用開始できます。
🔐
特定S3バケットのみアクセス
🛠️ カスタマーマネージド推奨
理由： AWSマネージドのS3ポリシーは全バケットにアクセスを許可してしまう

「production-logs」バケットだけにアクセスさせたい場合は、カスタムで作成が必要です。
📖
監査用の読み取り専用アクセス
🏢 AWSマネージド推奨
使用ポリシー： ReadOnlyAccess または ViewOnlyAccess

監査担当者には読み取り専用が最適。AWSマネージドで即座に設定可能です。
🏭
本番環境の厳密な権限管理
🛠️ カスタマーマネージド推奨
理由： 最小権限の原則を厳密に適用

本番環境では「必要な操作だけ」を許可。過剰な権限はセキュリティリスクになります。
🚀
プロトタイプ・検証環境
🏢 AWSマネージド推奨
使用ポリシー： PowerUserAccess

素早く試したい検証環境では、細かい権限設計より開発スピードを優先。PowerUserAccessで広めの権限を付与。
🔄
組み合わせて使う
🎯 両方を組み合わせ
例： AmazonS3ReadOnlyAccess（AWS）+ 特定バケットへの書き込み権限（カスタム）

基本はAWSマネージドで、追加で必要な権限だけカスタムで作成する方法が実務では多い！

💻 実際のポリシー例

🏢 AWSマネージドポリシー例
// AmazonS3ReadOnlyAccess（AWSが管理） { "Version" : "2012-10-17" , "Statement" : [ { "Effect" : "Allow" , "Action" : [ "s3:Get*" , "s3:List*" , "s3:Describe*" ], "Resource" : "*" // ← 全てのS3バケットが対象 } ] }
🛠️ カスタマーマネージドポリシー例
// 特定バケットだけにアクセス許可（自分で作成） { "Version" : "2012-10-17" , "Statement" : [ { "Effect" : "Allow" , "Action" : [ "s3:GetObject" , "s3:PutObject" ], "Resource" : "arn:aws:s3:::my-app-logs/*" // ← 特定バケットのみ！ }, { "Effect" : "Allow" , "Action" : "s3:ListBucket" , "Resource" : "arn:aws:s3:::my-app-logs" , "Condition" : { "StringLike" : { "s3:prefix" : [ "logs/*" ] // ← 特定プレフィックスのみ } } } ] }

✨ ベストプラクティス

✅ 推奨される使い方
  • 👍 まずAWSマネージドで要件を満たせるか確認する
  • 👍 本番環境ではカスタマーマネージドで最小権限を実現
  • 👍 両方を組み合わせて効率的に権限管理
  • 👍 カスタムポリシーは命名規則を統一する
  • 👍 定期的にポリシーの棚卸しを行う
❌ 避けるべき使い方
  • 👎 本番環境でAdministratorAccessを安易に使う
  • 👎 AWSマネージドの内容を確認せずに使う
  • 👎 カスタムポリシーを作りすぎて管理できなくなる
  • 👎 Resource: "*" を安易に使う
  • 👎 ポリシーのバージョン管理を怠る

❓ よくある質問

Q. AWSマネージドポリシーをコピーしてカスタマイズできますか？
A. はい！AWSマネージドポリシーの内容をコピーして、カスタマーマネージドポリシーとして作成できます。これは「ベースラインとして使って微調整する」という一般的なパターンです。
Q. インラインポリシーとの違いは何ですか？
A. インラインポリシーは特定のユーザー/ロール/グループに直接埋め込まれるポリシーです。マネージドポリシー（AWS・カスタマー両方）は再利用可能で複数のエンティティにアタッチできますが、インラインは1対1の関係です。現在はマネージドポリシーの使用が推奨されています。
Q. AWSマネージドポリシーが更新されたらどうなりますか？
A. 自動的に更新が適用されます。これはメリット（最新機能に対応）でもあり、デメリット（意図しない権限変更の可能性）でもあります。重要なシステムでは、カスタマーマネージドで固定することも検討してください。
Q. カスタマーマネージドポリシーの制限は？
A. 1アカウントあたり最大1,500個まで作成可能。1ポリシーあたりの最大サイズは6,144文字。バージョンは最大5つまで保持できます。

📝 まとめ：使い分けのポイント

🏢 AWSマネージドを選ぶとき

✅ 素早く始めたいとき
✅ 標準的なアクセスパターン
✅ メンテナンスの手間を省きたい
✅ 検証・開発環境

🛠️ カスタマーマネージドを選ぶとき

✅ 細かい権限制御が必要
✅ 特定リソースへのアクセス制限
✅ コンプライアンス要件がある
✅ 本番環境のセキュリティ強化

💡 実務での黄金ルール

「まずAWSマネージドで始めて、要件に合わなければカスタマーマネージドで調整」
これが最も効率的なアプローチです！

Created by SSuzuki1063

AWS SAP Learning Resources