【追記あり】DevOps AgentからAurora MySQLを安全に調査できるようにした話 〜 AgentCore Gateway + Lambda構成 〜
メディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、AWS DevOps AgentからAurora MySQLの調査を安全におこなえるように、Bedrock AgentCore GatewayとLambdaを使ってDB調査用ツールを作ってみた話です。
なにかの役に立てば幸いです。
DevOps AgentからAurora MySQLを調査したい全体の構成Aurora MySQL MCPサーバーではなく、AgentCore Gateway+Lambdaを採用した理由Amazon Bedrock AgentCore GatewayとはLambdaで実装した機能安全にDB調査するためにやったことGatewayの認証はCognito JWTで制限Gatewayの認証はSigV4/IAM Role認証で制限DBユーザーは読み取り専用SQL validatorで危険なSQLをブロックDevOps AgentへのMCPサーバー追加とSkillsの作成DBインシデント調査をさせてみた結果終わりに
DevOps AgentからAurora MySQLを調査したい
DevOps Agentは2026年3月31日にGAリリースされた機能で、CloudWatchやAWSリソースの情報をもとに、インシデントの原因調査や復旧提案をしてくれる機能です。
詳しくは過去にブログ記事で取り上げているのでご参照ください。
DevOps AgentはAWS内のリソースを隈無く調査してくれるのですが、DBの中のデータまでは確認することはできません。
ただ、実際の障害調査ではAWSリソースの状態だけでなくDBの中も見たいケースがよくあります。
例えば、Aurora MySQLを利用しているアプリケーションのエラーやレイテンシ悪化が発生しているときに、以下のようなことを確認したくなります。
- 対象DBにどんなテーブルがあるか
- テーブルの構成は？インデックスが適切に貼られているか
- 問題になっているSELECTのEXPLAINがどうなるか
- テーブルサイズや行数の傾向がどうなっているか
DevOps AgentにはMCPの連携機能があるため、Aurora MySQLに接続できるMCPがあれば実現することができます。
全体の構成
【2026年5月追記】
2026年4月末のブログ公開当時はDevOps Agentに登録できるMCPの認証方式に、SigV4/IAM認証がありませんでしたが、5月に入りいつのまにか認証方式が追加されていたので、今回の構成でもCognitoをつかった認証からSigV4/IAM認証へ変更しました。
変更前）CognitoをつかったJWTの認証の構成
変更後）SigV4/IAM認証
ざっくりした流れは以下のとおりです。
- DevOps Agentへユーザーが調査指示を出す
- DevOps AgentがAgentCore GatewayにMCPリクエストを送信
- AgentCore GatewayがGateway用IAM RoleでLambdaをInvoke
- Lambdaがツール名と引数をもとにAurora MySQL調査用処理を実行
- LambdaがRDS Data API経由でAurora MySQLにクエリを実行
- 結果をAgentCore Gateway経由でDevOps Agentへ返却
Aurora MySQL MCPサーバーではなく、AgentCore Gateway+Lambdaを採用した理由
しかし、DevOps Agentから追加するMCPサーバーは、remote MCP endpointとして到達できる必要があります。
一方、AWS LabsのMySQL MCP ServerはローカルMCPクライアントからstdioで利用する前提の構成だったため、そのままでは利用できませんでした。
また、仮にMySQL MCP Serverが利用できたとしても、このMCPサーバーはread-only制御や一部の危険パターン検出はありますが、任意SQLを受け取るrun_queryが中心です。
そのため、高負荷なSELECT、巨大なJOIN、LIMITなしの大量取得など、読み取りクエリによる負荷影響を用途別に制限する仕組みまではありません。
今回の用途では、本番Aurora MySQLに対して障害調査の初動で使うことを想定していたため、汎用的なSQL実行ツールではなく、調査用途に絞ったツールだけをAgentCore Gateway + Lambdaで公開する構成にしました。
Amazon Bedrock AgentCore Gatewayとは
Amazon Bedrock AgentCore Gateway(以下、AgentCore Gateway)は、Agentから見ると1つのMCPエンドポイントとして振る舞ってくれるマネージドなゲートウェイです。LambdaやAPIなどをTargetとして登録すると、GatewayがそれらをMCP互換のtoolとして公開してくれます。
AgentCore Gatewayは、MCP endpointを全公開するだけの仕組みではなく、入口に認証を設定できます。今回は、このAgentCore GatewayのMCP endpointにCognito JWT認証を付け、DevOps Agentからの正当なリクエストだけを受け付ける構成にしました。
Lambdaで実装した機能
Aurora MySQL調査用LambdaをAgentCore GatewayのTargetとして登録します。
今回は rds-inspector というLambda関数を作成し、以下のようなツールを実装しました。
| Tool | 機能 |
|---|---|
| list_databases | DB 一覧 |
| list_tables | テーブル一覧 |
| show_create_table | テーブル構造表示 |
| show_indexes | インデックス表示 |
| explain_select | EXPLAIN SELECTの実行計画表示 |
| table_stats | information_schema.TABLES から 概算行数・データ/インデックスサイズ等表示 |
AgentCore GatewayのLambda Targetでは、ツールのinputSchemaを定義しておきます。
例えば、show_create_table なら以下のようなイメージです。
ツール定義をAgentCore Gatewayに登録すると、DevOps AgentからはMCP toolとして見えるようになります。
安全にDB調査するためにやったこと
今回の構成では、DevOps AgentからAurora MySQLを調査できるようにしていますが、Agentが自由にSQLを実行できる状態にはしていません。安全に扱うために、いくつかのレイヤーで制限をかけています。
Gatewayの認証はCognito JWTで制限
Gatewayの認証はSigV4/IAM Role認証で制限
2026年5月に確認するといつのまにかSigV4による認証が追加されていました。
このアップデートによって、前述のCognitoをつかったJWTの認証は不要となりました。DevOps Agentからのアクセスのみを許可するIAM Roleのポリシーを設定し、Gatewayに紐づけてあります。
DBユーザーは読み取り専用
RDS Data APIでクエリを実行するのですが、その際に利用するDBユーザーは調査対象のスキーマだけ許可した読み取り専用ユーザーとしています。
SQL validatorで危険なSQLをブロック
ツールでは、EXPLAINを実行するだけのツールですが、生成されたクエリが万が一でもそのまま実行されないよう、Lambda側でSQLを必ず検査するようにしました。以下のような制御を入れています。
- SELECT以外は拒否
- DDL/DMLは拒否
- INTO OUTFILE は拒否
- FOR UPDATE / LOCK IN SHARE MODE は拒否
- SLEEP()やBENCHMARK()は拒否
DBユーザーが読み取り専用でも、巨大なSELECTやロックを伴うSQLはサービス影響につながる可能性があるため、SQL validatorでも制御するようにしました。
DevOps AgentへのMCPサーバー追加とSkillsの作成
まずはDevOps Agentに今回作成したAgentCore GatewayをMCPサーバーとして登録します。
認証フローでは「AWS SigV4」を選択しIAM Role を指定します。この Role は、DevOps Agent サービスからのみassumeできるよう信頼ポリシーを絞り、権限としては対象の AgentCore Gatewayを呼び出せる最小権限 (bedrock-agentcore:InvokeGateway) だけを付けます。
Gateway 側にもResource Policyで「この IAM Role 以外は Deny」をいれています。
次にDevOps AgentがうまくDB調査をできるようにSkillsを整えます。
SkillsはGAリリースの際に追加された機能で、DevOps Agentが調査をする際に調査するコンポーネントやツールを指定したりすることで、調査精度の再現性を高くすることができます。
Skillsは直接追加することができます。
DevOps Agentのチャットでの対話でもSkillsを作成可能なので、こちらの方法で作成します。
ヒアリングされた項目に以下のように回答しました。
ツールの使い方と、DBのメトリクスなどを調査する順番を指定しています。
これによって作成されたSkillsは以下のとおりです。
スキル名:
- investigate-rds-aurora-performance
Description
SKILL.md
DBインシデント調査をさせてみた結果
調査指示: 「現在Aurora MySQLの負荷は高くないですが、負荷が高かったと想定してXXX-clusterについて調査してください」
しっかりと作成したSkillsにしたがって調査が開始されました。
指示通り、CloudWatchのメトリクス全体を見ながら、パフォーマンスインサイトやスローログの分析をし、見つかった遅いクエリに対して、テーブル構造の確認をMCPのツールをつかって確認していることが確認できます。
そして、現在の原因の仮説を検証するために、MCPのツールを問題のクエリの詳細分析を開始しています。
最終的に特定テーブルへのインデックス不足を原因として結論付けています。
終わりに
DevOps AgentにAurora MySQLのDBデータを調査させる能力を追加することで、より実務で役に立つインシデント調査エージェントになりました。
【追記】2026年5月にいつのまにかSigV4/ IAM認証が追加されました！まさかブログ公開から10日程度で追加されているとは思いませんでした。これによって、Cognitoが不要になるのでよりシンプルな構成で実現することができました。
このSigV4認証がいつ追加されたアップデートなのかは、リリースノートからも確認することはできませんが、対応していること自体は公式ドキュメントでも記載されています。
AWSさんアップデートありがとうございます！！
みなさんもドンドンDevOps Agentを使っていきましょう！
SRGにご興味ありましたらぜひこちらからご連絡ください。