Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
CloudTrail 見ろ、ドキュメントちゃんと読め
Search
Kai
March 10, 2026
Programming
54
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
CloudTrail 見ろ、ドキュメントちゃんと読め
Kai
March 10, 2026
More Decks by Kai
See All by Kai
AmazonConnectを コンタクトセンターと 呼んでいた頃
aki_pin0
0
38
ふん…おもしれぇ Parser。RubyKaigi 行ってやるぜ
aki_pin0
0
160
Rubyが好きな話
aki_pin0
0
37
Other Decks in Programming
See All in Programming
月間100万人のサービス刷新で、 技術選定をHonoに振り切った話
yutobara
8
6.7k
golang-bob.pdf
iwatsukayura
0
130
ActionController meets Protocol Buffers
sorah
0
560
Next.js: The final boss of Web Performance
guaca
0
290
Apple Intelligence を用いた個人情報誤送信防止、及びユーザーリクエスト体験の改善について
yukiny
0
350
気持ちぃ〜角丸 Squircle
ryu1013
0
320
Event is what happens
moro
2
960
Findy - エンジニア向け会社紹介/Findy Company Deck
findyinc
6
400k
[Rails World 2026] Durable orchestration on Rails: from continuation to workflow
palkan
1
780
コードレビューのボトルネックを"する側"と"される側"の両面から解消する
yub0n
2
1.6k
AWSに止められる覚悟してますか?
morizo_1984
2
540
パズルゲームの作り方 / how to make puzzle games
kaityo256
PRO
2
300
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
187
23k
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
69
67k
Building AI with AI
inesmontani
PRO
1
1.3k
KATA
mclloyd
PRO
35
16k
Art, The Web, and Tiny UX
lynnandtonic
304
22k
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
1
520
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
520
Crafting Experiences
bethany
1
390
Reality Check: Gamification 10 Years Later
codingconduct
0
2.3k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.4k
How to Talk to Developers About Accessibility
jct
2
580
Transcript
CloudTrail 見ろ、ドキュメント ちゃんと読め Kai
やりたかったこと Kiro おなじみ AWS の AI コーディング支援ツール(旧 Q Developer のリブランド)
AWS からバジェットをもらったので開発メンバー全員につかってもらうぞ IAM Identity Center (IdC ) Kiro のライセンスを「誰に割り当てるか」を管理するため、AWS の SSO 基盤 である IdC を使うぞ 従業員を User として管理し、利用者を Group (グループ) にまとめられるぞ 今回のゴール Kiro 利用希望者のGroup を作成し、そのGroup がKiro をりようできるようにするぞ ( 個人ごとに登録すると人が増えるたびに手業が必要でたいへんだぞ)
Kiro のリソース構造 概念 説明 Profile 1 アカウント × 1 リージョンに1
つ。 作成時に IdC へマネージドアプリケ ーション( QDevProfile-region ) が紐づく Plan 何を提供するか(Pro / Pro+ ) Subscription 誰にライセンスを割り当てるか ちなみに: 裏側はまだ Q Developer コンソールは Kiro にリブランドされたが、API の内 部名は Q Developer のまま。 Profile (器) ├── Plan (何を提供するか) └── Subscriptions (誰が使うか) ├── Individual: 個人単位 └── Group: グループ単位 ← 今回の対象 ※ 管理者セットアップガイド
グループサブスクリプションに必要なもの management account(親アカウント) us-east-2 IAM Identity Center 管理者グループ(私) 利用者グループ PermissionSet
member account(子アカウント) us-east-1 Kiro Profile(器) Plan(Kiro Pro+)+ Subscription(Group) 「何を提供するか」と「誰が使うか」を一括で割り当てる 操作権限 ライセンス割当 青: 管理者の操作権限の流れ / 緑: 利用者ライセンスの流れ / 破線: クロスアカウント
Tips: 利用者グループの PermissionSet は不要? IdC がリソースにアクセスする際、2 つのアクセス経路が存在するよ 経路 仕組み 用途
AWS accounts PermissionSet を割り当て → IAM ロール作成 管理者が AWS コンソールを操作 Applications マネージドアプリケーションを割り当て 利用者が Kiro を利用 管理者 → PermissionSet (AWS accounts 経路) 利用者 → マネージドアプリケーション(Applications 経路) 利用者に PermissionSet は不要。別の経路でアクセスする。 さっきの図を見て「利用者グループには PermissionSet 要らないの?」と思った方向け
セットアップの流れ management account(親アカウント) us-east-2 IAM Identity Center 管理者グループ(私) 利用者グループ PermissionSet
member account(子アカウント) us-east-1 Kiro Profile(器) Plan(Kiro Pro+)+ Subscription(Group) 「何を提供するか」と「誰が使うか」を一括で割り当てる 1 2 ③ Kiro 公式の IAM ポリシーを設定 ④ member account に割当 5 6 ❌ ここで失敗 ① グループ作成 ② PermissionSet 作成 ③ IAMポリシー設定 ④ account に割当 ⑤ Profile 作成 ⑥ 割当(失敗)
⚠ Error Your account is not authorized to make this
call. もっといっぱい喋れ( 調査開始)
右往左往した エラーメッセージは「権限がない」としか言ってくれない。何が足りないかわからず、思いつく原因を片っ端から潰していった。 リージョン不一致を疑う IdC は us-east-2 、Profile は us-east-1 。このクロスリージョン
が原因では? ❌️ 他のリージョナルサービスでは問題なく動いている。これが 原因なら他も壊れているはず。 Trusted Access を疑う AWS サービスが Organizations (マルチアカウント管理)配下 の別アカウントで動作するための仕組み。コンソールにこう表 示されていた: Amazon Q Amazon Q generates, tests, and debugs code... ❌️ 既に有効化済み。readonly 権限では参照できず "Not Enabled" に見えていただけ。勘弁してくれ ⊘ Not enabled 自分の権限では検証すらできず、試すたびに管理者への依頼が必要だぞ 一週間くらいふて寝したぞ
ついに!CloudTrail を確認 なんで見なかったの? → 公式ドキュメントの IAM ポリシーをそのままコピペしたので権限不足はないと 思っていたよ、万死万死 管理者に CloudTrail
(AWS の API 操作ログ)の確認を依頼 AccessDenied → 権限不足やんけ { "eventSource": "q.amazonaws.com", "eventName": "CreateAssignment", "errorCode": "AccessDenied", "errorMessage": "Your account is not authorized to make this call.", "requestParameters": { "principalType": "GROUP", "subscriptionType": "Q_DEVELOPER_STANDALONE_PRO_PLUS" } }
不足権限の特定:めんどい めんどいので管理者に PowerUser 権限(自分が設定したポリシーよりずっと広い権限)で同じ操 作を試してもらった。 成功 自分が設定した IAM ポリシーでは、グループサブスクリプション作成に必要な権限が足りていなかっ た。
では何が足りなかったのか Kiro 公式のポリシー例で PermissionSet を作ったが、Group 割当に必要な権限が不足していた。 最も疑わしいのは、SLR (Service-Linked Role =
AWS サービスが自動で使う IAM ロール) の作成権限かも 不足した可能性が高い権限 iam:CreateServiceLinkedRole ( AWSServiceRoleForUserSubscriptions を対象) Kiro 公式のポリシー例 含まれていない Q Developer 公式の管理者ポリシー 含まれている 自分がやったこと: Kiro 公式のポリシーをコピペして PermissionSet を作った。Q Developer 公式に別の管理者ポリシーがあることに気 づかなかった。 Kiro 公式の想定していない状態になっていたんですか?
SLR (Service-Linked Role )とは AWS サービスがリソースにアクセスするために使う専用の IAM ロ ール。 User
ではなくサービスが assume する。 特徴 説明 誰が作るか 管理者が作成 or サービスが自動作成 誰が使うか AWS サービス 編集 不可 管理者が Group 割当を実行 → Kiro が処理開始 → SLR を assume → IdC 等にアクセス → SLR 未作成なら自動作成 → 管理者に iam:CreateServiceLinkedRole が必要 参考: AWS 公式 - SLR
なぜ SLR の作成権限が必要だったのか(推測) 前提: Subscription 割当時、Kiro は SLR ( AWSServiceRoleForUserSubscriptions
)を使って 利用者グループに誰がいるかを IdC に問い合わせる。SLR が 未作成の場合、サービスが自動作成を試みる。 (Kiro 公式) 管理者 PermissionSet 1 Subscription 割当 Kiro q.amazonaws.com 2 SLR を使いたい SLR 未作成 IdC 利用者グループ 参照 3 SLR 自動作成を試みる iam:CreateServiceLinkedRole 4 管理者の権限を確認 AccessDenied 赤: 失敗した経路
教訓 1. CloudTrail は最初に見る エラーメッセージだけで推測せず、CloudTrail で実際の API コールとエラーを確認する。 切り分けの精度が段 違い。
2. 切り分けの第一歩は「広い権限で試す」 PowerUser で通れば権限の問題、通らなければサービスの問題。最初にやっていれば右往左往せずに済んだ。 3. 関連ドキュメントを横断的に読む Kiro 公式のポリシー例だけで満足した。Q Developer 公式に別の管理者ポリシーがあることに気づかなかっ た。1 つのページで満足せず、関連リンクを辿る習慣が大事。 (4. 私に権限をください)