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
iOS 27でニュースアプリはどう変わる!? 〜日経電子版の新機能対応と、開発事例から〜
lynnswap
7
13k
AmebaブログはKMPから卒業します
kmars0605
0
200
自サークルのIdPからログアウトできるようになるまで
taiseiue
1
140
Agents on Rails - Rails at Scale 2026
irinanazarova
0
570
IBM Bob でAI駆動開発『QC-Playbook』
ichirokano2
0
110
Optunaを作ったときにやりたかったこと、その後 (2026/10/16, Optuna Meetup #3)
iwiwi
1
440
Verilogで学ぶCPU自作入門
uyuki234
8
4.1k
コードレビューのボトルネックを"する側"と"される側"の両面から解消する
yub0n
2
1.6k
ChromeでローカルLLM
ryu1013
0
140
最近”作らせてる” ローカルAIアプリの話
akit37
0
480
GemmaをJevのように使ってみる / Use Gemma like Jev
kishida
5
790
[2026-09-26]空論ジェネリックプロセス~テスト資産とAIで紡ぐ、再現可能なパフォーマンスチューニングの話~
tosite
0
270
Featured
See All Featured
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
1
3.4k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.6k
Intergalactic Javascript Robots from Outer Space
tanoku
273
28k
The browser strikes back
jonoalderson
0
1.8k
Building Applications with DynamoDB
mza
96
7.2k
Jess Joyce - The Pitfalls of Following Frameworks
techseoconnect
PRO
1
450
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
120
120k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
3.1k
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.6k
What's in a price? How to price your products and services
michaelherold
247
13k
Odyssey Design
rkendrick25
PRO
2
880
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. 私に権限をください)