導入
背景・目的
- 2025/4/25にアップデートがあり、「Amazon Q Developerの運用上の調査」機能が東京リージョンでもプレビュー開始しました！
- これにより、東京リージョンでもCloudWatchとAmazon Q Developerとを統合したトラブルシューティングを試せるようになりました。
- 本記事では、AWSコンソールにて本機能を有効化したうえで、CloudWatchアラームトリガでのトラブルシューティングを実施してみます。
対象読者
- 本記事は、AWS 認定ソリューションアーキテクト - アソシエイトレベルの知識を持つ読者を想定しており、AWSサービスの基本的な解説は省略します。
「Amazon Q Developerの運用上の調査」機能の有効化
AWSコンソールにて東京リージョンのCloudWatch画面にアクセスしたところ、サイドバーにAIオペレーションセクションが追加されていました。
このアカウント用に設定をクリックして、当該機能を有効化します。(今回は全オプションデフォルト設定値で有効化しました。)
CloudWatchアラームベースでの調査
事前準備
事前準備として、意図的に実行エラーを発生させるLambda関数と、当該関数のエラーメトリクスを監視するアラームを作成します。
まずはPython 3.13ランタイムでLambda関数を作成します。
- Lambda関数のタイムアウトは3秒に設定しておきます。
- イベント起動時に渡される値に応じて待ち時間を調整し、意図的にタイムアウトエラーを発生するようにしています。(Amazon Q Developerによる調査時にDurationメトリクスが提案されることを期待しています。)
import json
import time
def lambda_handler(event, context):
# eventから秒数を取得（デフォルト0秒）
wait_seconds = event.get('wait_seconds', 0)
# 秒数が数値かどうかチェック
try:
wait_seconds = float(wait_seconds)
except (ValueError, TypeError):
return {
'statusCode': 400,
'body': json.dumps('Invalid wait_seconds value')
}
# 待機
time.sleep(wait_seconds)
# メッセージ出力
print("Hello World")
return {
'statusCode': 200,
'body': json.dumps('Hello World')
}
次に、当該Lambda関数のエラーを監視するアラームを作成します。
調査アクションを追加し、アラーム状態時にAmazon Q Developerによる調査がトリガーされるように設定します。
Amazon Q Developerでの調査
事前準備が完了したので、実際に調査を試してみましょう。
複数回Lambda関数を実行して意図的にLambdaエラーを発生させると、先ほど作成したAlarmがアラーム状態となりました。
アラーム発生後、AIオペレーションの調査画面から調査が自動的に開始されていることが確認できました。
調査の詳細画面にアクセスしてみたところ、画面右側に観察結果の提案[1]が表示されていました。
期待通りの観察(Durationメトリクス)が提案[2]されたことから、承諾をクリックしたところ、フィードに観察結果が追加されました。
調査を終了ボタンをクリックすることで、調査ステータスがアーカイブ済みになりました。
所感
- Amazon Q Developerが観察結果や仮説を提案してくれるだけでなく、人間がメモを追加したり、提案を承諾・破棄したりでき、人とAIとが連携した障害調査向けにデザインされたサービスであることに好感を持ちました。
- バージニア北部リージョンであればServiceNowやJiraと統合することもできるようですが、東京リージョンは未対応なのが少し残念でした。(GA時には東京リージョンでも対応していることに期待…！)
参考資料
注意事項
- 本記事は万全を期して作成していますが、お気づきの点がありましたら、ご連絡よろしくお願いします。
- なお、本記事の内容を利用した結果及び影響について、筆者は一切の責任を負いませんので、予めご了承ください。
アクセンチュア株式会社に所属する社員有志による運営です。アクセンチュアの社員による様々な発信をまとめています。なお、投稿内容は社員個人の見解であり、所属する組織を代表するものではありません。
Discussion