IAM を覚える時って、結構面倒臭い。そして、なんとなく覚える・教える
これはとても怖いしあぶない。時には炎上、しらべてみたらざるだったなんてこともある。
そこで、ハッカソンでIT知識・AWS知識なしからスタートした病院診療士さん・看護婦さんたちと共同メンバーで参加し、まず最初に覚えるIAMとして使った教材ファイル「IAMの覚え方」を共有させてください。実績として、しっかり皆で覚えて最終選考の頂上決戦まで結果を残すことができました。
（最後に内製化支援のできるAWSというのをご紹介）

👻結果と怖い話：

めんどくさいからコピペ、そして事故る「みたことあるので驚いたのは Actionも、リソースも全て *」なRoleで動いてるコントローラのあるシステムを見たことがある。

でも、そうはいってもむずいじゃない？（こう覚えてPolicy構造も理解しちまおうぜ）

呪いの指輪、ロトの剣、魔法使いの杖

（「ドラゴンクエスト」シリーズの著作権は、株式会社スクウェア・エニックスおよび関連会社（ARMOR PROJECT、BIRD STUDIO、SPIKE CHUNSOFT）が保有しています。動画や画像をネットに公開する際は、各作品の公式ガイドラインを守り、指定された著作権表示を記載する必要があります。）

それでははじまりはじまり・・・なのじゃ

設計したら、IAM ポリシシミュレーターで確認しよう

IAM を設計したら、机上の空論・ManagedPolicyだから大丈夫・AIに任せたから安全（SecurityAgentに利用するリソースから適正なIAMを作ってくれる支援サービスがある）

それでもやっぱり手動で動作の確認はしたほうがいい。どんなに安全な飛行機だって、安全な手術室だって、安全とおもったIAMも同じで必ず利用前に指差し確認やしっかり作動できるということを確認することは必要。そのためにも、　地味ではあるけど作り出すと意外と便利な「Policy Simulatorを利用するのが便利。実際の動作とは変わることがあるというのは、システムがアップグレードする可能性があるための注意書きではあるが、そもそも動かない・ざるで動きを確認できないなんて事のないようにするための手段の選択肢。
」

ひとまず、IAM画面で作ってS3なりECSに割り当てて、ぶっつけ本番でアクセスできるできないとかやってると危ない！（もっと危ないのは　アクセス対象を * とかAction も＊にして一時的だからとやること。）

※ちゃんと設計するシステムの場合は、一時的とはいえ理由をつけられたとしても＊をつかうことは、設計方針で禁止したほうがいいと思う。

ログインした後にManagedPolicyを使い、対象のリソースへの適性を確認する

（ベストプラクティスだよって行をちゃんと読もう）：
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/TemplateReference/aws-resource-iam-managedpolicy.html

内製化支援 Angel道場2025

ここでは、AIを利用して画面を起こし、アプリケーションの出力するデータ精製のロジックを生成AIで作成。デプロイや状態の確認までメンバー皆で発表し最終選考の頂上決戦まで結果を残すことができました。
内製化の支援を３ヶ月でアプリケーションリリース（ちゃんと動く）まで持っていくことができる、AIとシステム設計を、僕らアプリケーションとインフラの気持ちのわかるエンジニアで展開させることでチームを立ち上げることができる。そしてこのクラウド利用をすることで開発や落とし込みが迅速に行える。クラウドジャーニーの提唱するステップを一気に飛躍させることができるのはAWSだけです。

参考：AngelDojoについて:　

る「内製化における生成 AI 活用支援サービスオファリング」についても取り上げます。

AWS では様々な AWS パートナープログラムを通じ、AWS パートナーとともにお客様のデジタルトランスフォーメーションの支援を行っています。その中で、AWS に対する深い知見と多くの経験を持ち、ユーザー企業の内製化を支援するためのソリューションを持った AWS パートナーを、日本独自に「内製化支援推進 AWS パートナー」と位置づけました。AWS は、「内製化支援推進 AWS パートナー」とともに企業の内製化に向けての課題解決に取り組んでいます。

2025 ANGEL Dojo 頂上決戦 - AWS 初心者が 3 か月で DX に挑戦！:
http://youtube.com/watch?v=jnrVg3Sw7vg&themeRefresh=1

みんなに共有するときは以下のこと命じてもらおう覚えちゃおう

1: IAM ってのがある AWS はこれで全体制御する
2: IAM は　User/Role というのがあり、そこにPolicyというものを紐づける
3: Policyの文法を覚えようぜ
4: IAM と　IAM Identity Center は別のサービス
5: どんなことがあってもIAMで「＊」で試したり運用しない。リリース、運用しそうになったのに気づいたらどんな力を使っても、声を出して「それダメ」をさけぶ。

このサブに興味だけ持ってもらおうといくつかの追加話をする

Groupは、Userをたばねるから親であるよりも、UserとRoleと扱いは似てる
User とRoleの違いは、AWSコンソールにログインできる（人）　と　ログインできない（アプリ）
DocumentPolicyとProfileRoleっていうのがある
IAM のManaged Poilicyは、ベストなプラクティスであって保証をするもんじゃないから、ちゃんと使うときはちゃんと設計を考えよう
（意訳） IAMのUserにはRoleを割り当てて認可制御、IAMIdentityCenterのUserにはIAMのUserを割り当てて認可制御する。という例などがあるのでちゃんとぼえないといけない

みななで学び、ときには僕ら有識メンバーをたよりにAWS開発ライフたのしみましょ〜

素材サイト：
https://dot-illust.net/category/fantasy/

さいごに

「先輩、おれ　どらくえわかんねっす。ファイナルファンタジー世代っす」って言われたときは読み替えて　BoardnYourT（気長にじっくり教えて、３年後の自分の味方になってくれる後輩、イラッとしないで教えよう）