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で制限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があれば実現することができます。
全体の構成
まずは今回作成した全体の構成図を紹介します。
ざっくりした流れは以下のとおりです。
- DevOps Agentへユーザーが調査指示を出す
- DevOps AgentがAgentCore GatewayにMCPリクエストを送信
- AgentCore GatewayがJWTを検証
- 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で制限
AgentCore Gatewayはパブリックに公開することもできますが、今回はDBを扱うためCognitoが発行したJWTを必須にしました。
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サーバーとして登録します。
認証フローではOAuthクライアント認証を選択肢、クライアントIDやシークレットを登録します。
次に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データを調査させる能力を追加することで、より実務で役に立つインシデント調査エージェントになりました。
今回はDevOps Agentに追加するAgentCore GatewayのMCPサーバーの認証方式としては、Cognitoが発行したJWTを検証するOAuth認証にしていましたが、実はAgentCore Gateway側では既に が対応されています。
しかし、DevOps Agent側が現時点で対応しておらず、今回のCognitoによるJWTの方式を選択せざるをえませんでした。DevOps Agent側でSigV4/IAM認証へ対応してもらえると、IAMロールによる制御が可能になり、全体の構成をさらにシンプルにすることが可能です。この件はサポートへ機能要望として連絡しましたので、今後の進化に期待しています。
みなさんもドンドンDevOps Agentを使っていきましょう！
SRGにご興味ありましたらぜひこちらからご連絡ください。