AWS DevOps Agent から DynamoDB に直接クエリできるか試してみた
こんにちは、リテールアプリ共創部のヒョンジェです。
今回は AWS DevOps Agent の調査の中で DynamoDB にクエリを直接実行できるか試してみました。結論から言うと現時点では実現できませんでしたが、その過程で得られた知見を共有します。
※ DevOps Agent の基本的な内容についてはこちらの関連ブログ一覧をご覧ください。
実現したかったこと
上記のようなサーバーレス構成の API を運用しています。この API で障害が発生したとき、「影響を受けたユーザーは誰なのか？」を調べるのが毎回なかなか大変でした。CloudWatch Logs を開いて、該当するエラーログを探して、リクエストの中身からユーザー情報を紐づけて......と、手作業でやるとかなり時間がかかります。
「これ、DevOps Agent に自動でやらせたら楽なのでは？」と思い立ったのが今回のきっかけです。
API のログにはユーザーを特定できる情報が含まれているので、それを元に DynamoDB の UserTable を検索してユーザー ID を取得する、という流れを想定していました。
やったこと
0. DevOps Agent の構成
まず、API の障害を検知する CloudWatch Alarm が発生したら、DevOps Agent の調査を開始する仕組みを構築しました。
※ 以下のブログを参考
1. DevOps Agent の Skill を作成
次に DevOps Agent の Agent Space に「ログからユーザー ID を抽出する手順」を教えるための Skill を作成しました。
Skill には以下のようなロジックを定義しています。
- CloudWatch Logs からエラーに関連するログを取得
- ログに含まれる情報で
UserTableを検索し、ユーザー ID を取得 - もし
UserTableで直接見つからない場合は、別テーブルを経由して検索
2. 調査指示の設定
次に、DevOps Agent が調査を開始する際に「影響を受けたユーザーの ID リストを報告すること」を指示として設定しました。
※ Lambda から Webhook URL にリクエスト時に渡す description
descriptionLines.push(`Reason: ${reason}`);
descriptionLines.push(`alarmArn: ${alarmArn}`);
descriptionLines.push(`Alarm trigger: ${trigger}`);
descriptionLines.push('全ての調査報告は日本語でしてください。');
descriptionLines.push('影響を受けたユーザーの ID リストを報告してください。')
3. 試してみた
準備が整ったので、意図的にエラーを発生させて DevOps Agent に調査させてみました。
タイムラインを見ると、DevOps Agent はちゃんと Skill を参照して、ユーザー ID を取得しようと動いてくれていました。
しかし、DynamoDB 読み取りの権限が不足しているため、データの取得に失敗してしまいました。
4. IAM ロールに DynamoDB 権限を追加
権限不足で失敗したため、Agent Space に紐づく IAM ロールに、DynamoDB の Query、GetItem、Scan の権限をインラインポリシーとして追加しました。
new iam.PolicyStatement({
sid: 'AllowDynamoDBReadAccess',
effect: iam.Effect.ALLOW,
actions: ['dynamodb:Query', 'dynamodb:GetItem', 'dynamodb:Scan'],
resources: [
`arn:aws:dynamodb:ap-northeast-1:${this.account}:table/*`,
],
}),
5. 再実行
権限を追加したので DevOps Agent に再調査の依頼をしましたが、同じく権限不足で失敗しました。
タイムラインのメッセージを見ると Session Policy について書かれていました。
no session policy allows the dynamodb:<operation> action
IAM ロールの権限ではなく、Session Policy が原因でした。
Session Policy とは
DevOps Agent が IAM ロールを Assume する際、AWS 側で内部的に Session Policy が適用されます。最終的に DevOps Agent が持つ権限は以下のように決まります。
最終的な権限 = ロールの権限 ∩ Session Policy
つまり、IAM ロールに DynamoDB の権限を追加しても、Session Policy 側で DynamoDB のアクションが許可されていなければ、アクセスは拒否されます。
そして、現時点では DevOps Agent がプレビュー版ということもあり、この Session Policy をユーザー側で設定・変更する手段は提供されていないようでした。
※ Session Policy の詳細
6. Lambda 経由のアプローチも検討
直接 DynamoDB からデータを取得することができないなら、調査の中で Lambda を実行し、その Lambda から DynamoDB にアクセスすることも考えました。
しかし、マネージドポリシーの AIOpsAssistantPolicy に Lambda の InvokeFunction 権限が含まれていないため、Session Policy にも含まれていない可能性が高く、こちらも断念しました。
まとめ
残念ながら、DevOps Agent から DynamoDB に直接アクセスしてユーザー情報を取得することは、現時点では実現できませんでした。
ただ、個人的にはこの制限は妥当だと感じました。DynamoDB には個人情報が保存されているケースも多く、AI エージェントが自由にアクセスできてしまうのはセキュリティ上のリスクがあります。Session Policy によるガードレールは、適切な設計と言えるのかなと思います。
現時点で影響を受けたユーザーの ID を DevOps Agent に報告させるなら、API のログ自体にユーザー ID を含めておくのが一番現実的な方法だと思います。こうすれば DevOps Agent が CloudWatch Logs から直接ユーザー ID を読み取れるため、DynamoDB へのアクセスも不要になります。
まだ DevOps Agent はプレビューなので、今後のアップデートで DynamoDB からデータを取得するのが実現できる可能性はあると思います。引き続きアップデートを追っていきたいと思います。
最後まで読んでいただき、ありがとうございました。
