Amazon DevOps Guru 完全ガイド v2.0

ML 駆動の運用異常検知・根本原因分析・推奨事項の自動化

Amazon DevOps Guru は、CloudWatch メトリクス・ログ・イベント・AWS CloudTrail・Config・X-Ray を継続的に解析し、機械学習で運用上の異常を自動検知 するフルマネージド AIOps サービスです。Reactive Insight（既に発生している問題）と Proactive Insight（将来発生しそうな問題予測）を提供。デプロイ・設定変更・リソース追加イベントとの相関分析で根本原因を特定し、具体的な修復推奨事項を即座に提示します。2025-2026 年には End-of-Life（2026 年 4 月 30 日）を予定 しており、CloudWatch Application Signals + Q Developer Operations への移行 が推奨されています。本ガイドは DevOps Guru の本質・最新動向・移行戦略を網羅した完全リファレンスです。

ドキュメントの目的

本ガイドは以下を対象としています。

• 初心者向け： DevOps Guru とは何か、従来の CloudWatch アラームとの違いを学びたい方
• 運用エンジニア向け： Resource Collection・Insight 対応・EventBridge 統合の実装
• SRE / DevOps 責任者向け： 組織全体の運用効率化・Cost Optimization・MTTR 削減戦略
• アーキテクト向け： CloudWatch Application Signals への段階的移行計画
• 意思決定者向け： Datadog Watchdog・New Relic AIOps・Splunk Observability・IBM Watson AIOps・BigPanda との比較・投資判断

重要なお知らせ：End-of-Life（2026 年 4 月 30 日）

Amazon DevOps Guru は 2026 年 4 月 30 日に End-of-Life となります。AWS は以下への移行を推奨しています。

• CloudWatch Application Signals: SLO・エラーバジェット・自動スケーリング推奨
• Q Developer Operations: 生成 AI による自動トラブルシューティング・提案
• CloudWatch Anomaly Detector: CloudWatch メトリクス単位の異常検知

本ガイドでは DevOps Guru の概要・使用方法を説明しつつ、CloudWatch Application Signals への移行パス を最後のセクションで詳解します。

概要

初心者向けメモ： CloudWatch アラームと DevOps Guru の違いは「学習」です。

CloudWatch アラーム:
    メトリクス > 固定閾値 → アラート
    例: CPU > 80% → アラート
    
    問題点: 
    - 複数メトリクスの相関見えない
    - 異常と通常の違いを区別できない
    - 根本原因は手動分析
    
DevOps Guru（ML ベース）:
    CloudWatch・ログ・イベントを 継続解析
      ↓ 正常パターン学習（2 週間）
    複数メトリクスの相関 + デプロイイベント関連付け
      ↓
    異常を自動検知 → 根本原因を特定 → 修復推奨提示
    
    メリット:
    - 複合異常（複数メトリクス同時異常）を検知
    - 閾値設定不要
    - 根本原因が自動提示

DevOps Guru が実現する価値

DevOps Guru が解決する課題

1. CloudWatch 閾値設定の困難性・閾値の陳腐化

課題：

CloudWatch 閾値を手動設定:
    CPU > 70% → High
    Memory > 80% → High
    
問題:
    - 値が大きすぎて本来の異常検知できず
    - 値が小さすぎてアラートノイズ多発
    - 季節・時間帯で最適値変わる（黒金曜のトラフィック急増等）
    - 手動メンテナンスで忘れられたまま（アラート応答率低下）

DevOps Guru の解決：

DevOps Guru の学習:
    ├─ 最初の 2 週間: 正常なメトリクス動作パターン記録
    │  （朝 6 時の自動スケール・午前の定期バッチ処理・金曜夜間の DynamoDB 削除クエリ等）
    │
    ├─ その後: 正常パターンからの統計的偏差を検知
    │  （通常 100 req/s → 突然 500 req/s は偏差 = 異常の可能性）
    │
    └─ 自動調整: 学習パターンが更新され続ける
       （季節変動・トラフィック増加を自動反映）

2. 複数メトリクスの相関分析困難性

課題： CloudWatch ダッシュボードで複数メトリクスを並べても、「こちらの増加がこちらの原因」という相関は見えない。

• 実例: Lambda エラー率 ↑ + DynamoDB スロットリング ↑ が同時
• ← どちらが根本原因か？
• ← Lambda タイムアウト + DynamoDB リトライ？
• ← DynamoDB スロットリング → Lambda エラー？

DevOps Guru の解決：

DevOps Guru Insight: "Lambda Performance Degradation"
├─ メトリクス異常:
│  ├─ Lambda/Errors: 85（通常: 2）
│  ├─ Lambda/Duration P99: 8500ms（通常: 200ms）
│  ├─ DynamoDB/ConsumedWriteCapacityUnits: 450（通常: 50）
│  └─ DynamoDB/UserErrors: 127（通常: 0）
│
├─ 根本原因分析:
│  └─ DynamoDB Write Throttling → Lambda タイムアウト
│     （DynamoDB キャパシティ枯渇が主原因）
│
└─ 推奨事項:
   └─ DynamoDB キャパシティ設定を 50 WCU → 500 WCU に増加
      推定効果: Lambda エラー 99% 削減

3. デプロイ後の性能劣化検出遅延

課題： デプロイ直後に エラー増加・レイテンシ悪化が起きても、CloudWatch ダッシュボードで気づくまで数時間。

DevOps Guru の解決：

デプロイ（14:32）
    ↓
DevOps Guru: Event Correlation で デプロイイベントを検出
    ↓
メトリクス異常が同時に発生
    ↓
Insight 作成: "[REACTIVE] Lambda Error Rate Increase After Deployment"
    ├─ 異常開始: 14:35（デプロイ 3 分後）
    ├─ 関連イベント: CodeDeploy deployment d-... 実行
    └─ 推奨事項: 新バージョンに未検出の無限ループ。前バージョンロールバック推奨
    
運用チーム → 2 分で対応可能

4. 手動根本原因分析の時間コスト

課題： 本番障害時、CloudTrail ログを手動で分析。「何が変わった」を人力で探索。MTTR 長い。

DevOps Guru の解決：

Insight: "RDS CPU Anomaly Detected"
├─ 異常検知: 13:45
├─ 関連リソース:
│  ├─ RDS instance: prod-db-1
│  └─ Associated Lambda: order-processing-fn
│
├─ Root Cause Analysis:
│  └─ 新しく追加されたクエリが N+1 パターン（1 秒で 100 回の SELECT）
│
├─ CloudTrail Event との関連付け:
│  └─ 13:40: Lambda function code updated (source: CodeDeploy)
│
└─ Recommendation:
   └─ クエリ最適化 OR Lambda バッチサイズ増加 OR RDS スケールアップ

主な特徴

アーキテクチャ

┌─────────────────────────────────────────────────────────────┐
│ AWS リソース（本番環境）                                   │
├─────────────────────────────────────────────────────────────┤
│ • Lambda                                                    │
│ • EC2 / ECS / Fargate                                      │
│ • RDS / Aurora                                             │
│ • DynamoDB                                                 │
│ • ElastiCache                                              │
│ • SQS / Kinesis                                            │
│ • API Gateway                                              │
│ • CloudFront                                               │
│ • EKS                                                      │
│ • Step Functions                                           │
└────────┬──────────────────────────────────────────────────┘
         │
         ├─ CloudWatch メトリクス（自動収集）
         │  ├─ Lambda: Errors, Duration, Throttles, ConcurrentExecutions
         │  ├─ RDS: CPUUtilization, DatabaseConnections, ReadLatency
         │  ├─ DynamoDB: ConsumedWriteCapacityUnits, UserErrors
         │  └─ EC2: CPUUtilization, NetworkPackets
         │
         ├─ CloudWatch Logs（自動収集）
         │  ├─ Lambda ログ
         │  ├─ ECS ログ
         │  └─ RDS ログ
         │
         ├─ AWS X-Ray（トレース）
         │  └─ マイクロサービス間の依存関係・レイテンシ
         │
         ├─ AWS CloudTrail（API ログ）
         │  ├─ デプロイイベント（CodeDeploy, CodePipeline）
         │  ├─ リソース設定変更（ec2:RunInstances, rds:ModifyDBInstance）
         │  └─ IAM 権限変更
         │
         └─ AWS Config（リソース設定）
            └─ リソース設定の変更履歴
            
         ▼ データ転送（VPC Endpoint 経由）
         
┌─────────────────────────────────────────────────────────────┐
│ DevOps Guru ML エンジン                                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ Step 1: ベースライン学習（最初の 2 週間）                 │
│  ├─ 正常なメトリクス動作パターン記録                     │
│  ├─ 時間帯・曜日ごとのトラフィック変動パターン          │
│  ├─ リソース種別ごとの平均リソース消費                  │
│  └─ デプロイ・バッチ処理による定期的な異常を学習        │
│                                                             │
│ Step 2: 異常検知（継続的）                               │
│  ├─ 新規メトリクスが正常パターンから大きく偏差           │
│  ├─ 複数メトリクスの統計的相関が変化                   │
│  ├─ エラー率・レイテンシ・キャパシティの組み合わせ異常  │
│  └─ 異常スコア計算（0-100, 50以上で Insight 生成）      │
│                                                             │
│ Step 3: 根本原因分析                                     │
│  ├─ CloudTrail デプロイイベントとの時間軸関連付け       │
│  ├─ Config リソース設定変更との相関                    │
│  ├─ リソース間の依存関係グラフ分析                     │
│  └─ 複数異常の因果関係推定                             │
│                                                             │
│ Step 4: Insight 生成 + Recommendation                     │
│  ├─ REACTIVE INSIGHT: 既発生問題の詳細・推奨           │
│  └─ PROACTIVE INSIGHT: 将来予測（SQS キュー増加トレンド） │
│                                                             │
└─────────────────────┬──────────────────────────────────────┘
                      │
     ┌────────────────┼────────────────┐
     ▼                ▼                ▼
 CloudWatch         EventBridge      DevOps Guru Console
 Dashboard          (通知)           (UI 確認)
   
 ├─ Insight         ├─ SNS           ├─ Insight リスト
 │  ダッシュボード  ├─ Slack         ├─ リソース別分析
 │                  ├─ PagerDuty     ├─ Event Correlation
 ├─ 関連メトリクス ├─ Lambda        └─ Recommendation
 └─ 推奨事項       └─ Webhook
                        (Jira等)

Insight（インサイト）の種類

1. Reactive Insight（反応型・事後対応）

既に発生している運用問題を検知・分析。

[REACTIVE] Lambda Error Rate Increase
├─ 開始時刻: 2026-04-26 14:30 UTC
├─ 重大度: HIGH
├─ 影響リソース:
│  ├─ Lambda: order-processing-function
│  ├─ DynamoDB: orders-table
│  └─ SQS: order-queue
│
├─ 異常メトリクス:
│  ├─ Lambda/Errors: 85/min （通常: 2/min）
│  ├─ Lambda/Duration P99: 8500ms （通常: 200ms）
│  └─ DynamoDB/UserErrors: 127/min （通常: 0/min）
│
├─ Event Correlation:
│  └─ 14:20: CodeDeploy Deployment 実行（新バージョンデプロイ）
│
├─ Root Cause Analysis:
│  └─ DynamoDB Write Capacity 枯渇（WCU 消費 450/min、上限 100）
│     → Lambda リトライ多発 → エラー増加
│
└─ Recommendation:
   ├─ 即座対応:
   │  ├─ DynamoDB WCU を 100 → 500 に増加（推定効果: エラー 99% 削減）
   │  └─ または Lambda Timeout を 30s → 60s に増加（一時対応）
   │
   └─ 根本対策:
      ├─ Lambda バッチ処理サイズ見直し（1 件 → 10 件 バッチ）
      └─ DynamoDB Query 最適化（全件スキャン → インデックス使用）

2. Proactive Insight（予測型・事前予防）

将来発生しそうな潜在的問題を予測。

[PROACTIVE] EC2 Memory Exhaustion Predicted
├─ 予測時刻: 2026-04-26 17:00 UTC
├─ 重大度: MEDIUM
├─ 予測発生時刻: 2026-04-29 09:30 UTC （72 時間以内）
├─ 影響リソース:
│  ├─ EC2: i-0123456789abcdef （app-server-prod-1）
│  └─ Auto Scaling Group: app-servers-asg
│
├─ トレンド分析:
│  └─ メモリ使用率: 45% → 65% → 78%
│     （毎日 + 15-20%）
│
├─ Root Cause:
│  └─ アプリケーション メモリリーク（毎日の データ キャッシュ蓄積）
│
└─ Recommendation:
   ├─ 短期対応:
   │  ├─ Auto Scaling Group スケールアップ（min: 2 → 4）
   │  └─ CloudWatch アラーム: 60% で alert
   │
   └─ 根本対策:
      ├─ アプリケーション コード修正（メモリリーク削除）
      │  推定効果: メモリ使用率 78% → 35%
      │
      └─ 自動スケール ポリシー調整
         現在: CPU > 70% でスケール
         推奨: メモリ > 60% でスケール

3. Event Correlation（イベント相関分析）

CloudTrail・Config イベントと Insight を自動関連付け。

Insight: "RDS Slow Query Detected"

CloudTrail イベント時系列:
   10:45 - EC2 Lambda function code updated
   10:50 - EC2 ECS task deployment
   11:00 - RDS instance scale down （t3.medium → t3.small）
   11:15 - RDS slow query ログ 増加開始

DevOps Guru 分析:
   └─ RDS scale down（11:00） → slow query（11:15）
      の時間的相関を自動検出

Recommendation:
   └─ RDS を t3.small → t3.large に scale up
      またはクエリを最適化（N+1 クエリ問題修正）

主要ユースケース（10+）

1. 本番デプロイ後の自動異常検知

要件： デプロイ直後にエラー増加・レイテンシ悪化 → DevOps Guru が自動検知・推奨。

実装：

# DevOps Guru Resource Collection でアカウント全体監視
aws devops-guru update-resource-collection \
  --action ADD \
  --resource-collection '{
    "CloudFormation": {
      "StackNames": ["*"]  # 全 CloudFormation スタック
    }
  }'

# デプロイ実行
aws codedeploy create-deployment \
  --application-name my-app \
  --deployment-group-name prod-group \
  --deployment-config-name CodeDeployDefault.OneAtATime

# CodeDeploy イベント → CloudTrail → DevOps Guru が自動検出
# → メトリクス異常と時間軸で関連付け
# → 2-5 分で Insight 生成

成果： デプロイ性能問題を数分で検知。MTTR 大幅短縮。

2. RDS パフォーマンス・スロークエリ検知（DevOps Guru for RDS）

要件： RDS Aurora で突然 slow query 急増。クエリレベルで原因特定。

実装：

# DevOps Guru for RDS 有効化
aws devops-guru put-feedback \
  --insight-feedback '[
    {
      "id": "arn:aws:devops-guru:us-east-1:123456789012:insight/reactive/RDS_CPU_Anomaly",
      "feedback": "VALID_BUT_NEEDS_ATTENTION"
    }
  ]'

# Performance Insights データ自動分析
# → Top SQL クエリ特定
# → 実行時間トレンド可視化

DevOps Guru for RDS Insight:

[REACTIVE] RDS Database CPU Anomaly Detected
├─ Instance: prod-aurora-cluster-1
├─ CPU: 92% （通常: 15%）
├─ Top SQL Query:
│  ├─ Query: SELECT * FROM orders WHERE user_id = ? INNER JOIN payments ...
│  ├─ Execution Count: 1,200/sec （通常: 50/sec）
│  ├─ Avg Duration: 2.3s （通常: 0.01s）
│  └─ Lock Time: 850ms （通常: 0ms）
│
└─ Recommendation:
   ├─ user_id カラムにインデックス追加
   ├─ INNER JOIN 順序最適化
   └─ N+1 クエリパターン解消

成果： SQL 実行計画から最適化提案。DBA の手動分析時間削減。

3. DynamoDB・ElastiCache キャパシティ予測・最適化

要件： DynamoDB WCU・RCU スロットリング事前検知。キャパシティ増加提案。

実装：

# DevOps Guru で DynamoDB テーブル 監視
aws devops-guru update-resource-collection \
  --action ADD \
  --resource-collection '{
    "Tags": [{
      "AppBoundaryKey": "Environment",
      "TagValues": ["production"]
    }]
  }'

# メトリクス監視
# → ConsumedWriteCapacityUnits トレンド
# → UserErrors（スロットリング）検知

Proactive Insight:

[PROACTIVE] DynamoDB Write Throttling Risk Predicted

Current Trend:
└─ ConsumedWCU: 80/min → 90/min → 95/min
   （毎日 + 5-10 WCU）

Prediction:
└─ 7 日以内に WCU 上限（100）に達する可能性 95%
   推定達成時刻: 2026-05-03 14:30 UTC

Recommendation:
├─ 段階的スケール:
│  ├─ 今すぐ: 100 WCU → 200 WCU
│  ├─ 3 日後: 200 → 400 WCU
│  └─ 7 日後: 400 → 800 WCU
│
├─ または Auto Scaling 有効化:
│  ├─ Target Utilization: 70%
│  ├─ Min WCU: 100
│  └─ Max WCU: 40000
│
└─ 費用影響:
   └─ オンデマンド課金（従量制）への切り替え検討
      通常: $1.25/WCU
      推奨: 変動が多い場合 Pay-per-request（WCU 自動管理）

成果： スロットリング予防・コスト最適化。

4. マイクロサービス環境の依存関係・障害波及分析

要件： Service A が遅延 → Service B・C に波及。相関を自動分析。

実装：

# ECS Fargate マイクロサービス + X-Ray トレース有効化
aws ecs create-cluster --cluster-name microservices-prod
# X-Ray Daemon デプロイ

# DevOps Guru で X-Ray トレース解析
# → Service 間レイテンシ相関を自動検出

Insight:

[REACTIVE] Payment Service Latency Degradation

Service Dependency Graph:
└─ API Gateway
   └─ Order Service (P99: 2500ms, 通常: 100ms)
      └─ Payment Service (P99: 8000ms, 通常: 500ms)
         ├─ Database (slow query)
         └─ Payment Gateway API (timeout 多発)

Root Cause:
└─ Payment Gateway API が 8 秒遅延
   → Payment Service がその遅延をそのまま継承
   → Order Service も遅延
   → エンドユーザーに 10 秒遅延体験

Recommendation:
├─ Payment Service に timeout 設定（3 秒）追加
│  → timeout 後は fallback ロジック実行
│  → ユーザー体験を 10 秒 → 4 秒に改善
│
└─ Payment Gateway API への request timeout も 8 秒 → 3 秒に短縮

成果： 複数サービス間の障害波及メカニズム可視化・改善。

5. Lambda バッチ処理・スケジューリング最適化

要件： 毎晩の Lambda バッチ処理が遅延。DynamoDB スロットリング検知。

実装：

# CloudWatch Events + Lambda 監視
aws events put-rule \
  --name batch-processing-schedule \
  --schedule-expression "cron(0 22 * * ? *)"  # 毎晩 22:00

# DevOps Guru で Lambda + DynamoDB 相関分析

Insight:

[REACTIVE] Lambda Batch Processing Duration Increase

Lambda Metrics:
├─ Duration: 1200s （通常: 300s）
├─ Error Rate: 15% （通常: 0.5%）
└─ Throttles: 0 （問題なし）

DynamoDB Metrics:
├─ ConsumedWriteCapacityUnits: 450/min （上限: 100）
├─ UserErrors: 450 （スロットリング）
└─ Latency P99: 2500ms （通常: 50ms）

Recommendation:
├─ オプション 1: Lambda batch size 削減
│  └─ 現在: 1000 レコード/バッチ → 100 レコード/バッチ
│     効果: DynamoDB WCU 消費 450 → 45（10 倍削減）
│
├─ オプション 2: DynamoDB キャパシティ増加
│  └─ 100 WCU → 500 WCU
│     費用: +$0.47/時間（約 $11/月増加）
│
├─ オプション 3: DynamoDB Batch Write Item API
│  └─ 通常 Write: 各呼び出しで 1 WCU 消費
│     Batch: 複数アイテムを 1 回のバッチリクエストで効率化
│
└─ オプション 4: Lambda 並列実行
   └─ ランダムディレイ追加で DynamoDB 書き込みを時間分散
      Lambda 1: 0-10 分割（0-10%）
      Lambda 2: 10-20 分割（10-20%）
      ...
      効果: ピークスロットリング回避

成果： バッチ処理の效率化・コスト削減。

6. API Gateway・CloudFront 統合システムの性能分析

要件： API Gateway 背後の Lambda + CloudFront キャッシュレイヤーの統合性能監視。

実装：

# CloudFront キャッシュ統計 + Origin（API Gateway）レイテンシ相関分析
aws devops-guru update-resource-collection \
  --action ADD \
  --resource-collection '{
    "CloudFormation": {
      "StackNames": ["api-infrastructure"]
    }
  }'

Insight:

[REACTIVE] API CloudFront Cache Hit Ratio Decrease

Metrics:
├─ CloudFront Cache Hit Ratio: 95% → 72%
├─ Origin Latency: 100ms → 850ms
├─ 4xx Errors: 0.1% → 12%
└─ 5xx Errors: 0% → 3%

Root Cause Analysis:
└─ 新デプロイ後、Lambda が Cache-Control ヘッダー削除
   → CloudFront キャッシュ無効化
   → Origin（Lambda）への request 増加
   → Origin ダウン → エラー増加

CloudTrail Event:
└─ 14:20: Lambda function code updated

Recommendation:
├─ Lambda デプロイから Cache-Control ヘッダー削除を修正
│  修正: response.headers['Cache-Control'] = 'max-age=3600'
│
├─ CloudFront キャッシュ キー最適化
│  現在: ホスト名のみ
│  推奨: ホスト名 + API バージョン + ユーザーセッション属性
│
└─ CloudFront Function（エッジキャッシュ）活用
   キャッシュ多いクエリを エッジで処理 → Origin 負荷削減

成果： キャッシュ戦略の可視化・最適化。

7. EKS クラスタ・ノード リソース枯渇予測

要件： EKS ノードのメモリ・CPU 残容量が急減。Pod Eviction 前に予測。

実装：

# EKS + DevOps Guru 統合
aws devops-guru update-resource-collection \
  --action ADD \
  --resource-collection '{
    "Tags": [{
      "AppBoundaryKey": "Workload",
      "TagValues": ["eks-production"]
    }]
  }'

Proactive Insight:

[PROACTIVE] EKS Node Memory Exhaustion Risk

Affected Nodes:
└─ ip-10-0-1-100.ec2.internal
   ├─ Memory Utilization: 45% → 62% → 78% （毎日 +15%）
   ├─ Allocatable Memory: 7.5 GB
   ├─ Used: 5.9 GB
   └─ Available: 1.6 GB

Prediction:
└─ 3 日以内にメモリ枯渇（OOM） → Pod Eviction → サービス中断
   リスク: 72%

Affected Pods:
├─ order-service-5d4f3e
├─ payment-service-2a9f1c
└─ notification-service-7b2e5a

Recommendation:
├─ 即座対応:
│  ├─ ノード数スケールアップ（node count: 3 → 5）
│  │  推定効果: 1 ノード あたりメモリ消費 78% → 46%
│  │
│  └─ または Pod リソース要件見直し
│     現在: 1 Pod = 1.2 GB
│     最適化: 不要な Sidecar 削除 → 900 MB
│
└─ 根本対策:
   ├─ HPA（Horizontal Pod Autoscaler）設定
   │  └─ Memory > 70% でスケールアップ
   │
   └─ アプリケーション メモリリーク修正
      Profiler（pprof）で メモリ使用パターン分析

成果： Pod Eviction 事前予防・クラスタ安定化。

8. SQS・Kinesis メッセージキューの処理遅延検知

要件： SQS キュー が積み上がる → Lambda コンシューマーが処理遅延。原因分析。

実装：

# SQS + Lambda 監視
aws devops-guru update-resource-collection \
  --action ADD \
  --resource-collection '{
    "Tags": [{
      "AppBoundaryKey": "MessageType",
      "TagValues": ["event-processing"]
    }]
  }'

Insight:

[REACTIVE] SQS Queue Depth Increase

SQS Metrics:
├─ ApproximateNumberOfMessagesVisible: 1,200 → 8,500
│  （通常: 10-50）
├─ ApproximateAgeOfOldestMessage: 180s （通常: 10s）
└─ NumberOfMessagesSent: 5,000/min （通常: 1,000/min）

Lambda Consumer Metrics:
├─ Duration: 3200ms （通常: 800ms）
├─ Error Rate: 5% （通常: 0%）
├─ Concurrent Executions: 50 （上限: 1,000）
└─ Throttles: 0 （問題なし）

Root Cause:
└─ Lambda duration 増加が Lambda 処理スピード減少
   → SQS キュー処理が追いつかない
   → キューが積み上がる

Lambda Duration 増加の原因:
├─ DynamoDB クエリレイテンシ増加（150ms → 2500ms）
├─ 外部 API（Payment Service）timeout 多発
└─ Lambda 新バージョン（v2.5）でのコード パフォーマンス低下

Recommendation:
├─ 短期対応:
│  ├─ Lambda コンカレンシー上限引き上げ（1000 → 3000）
│  └─ または Lambda memory 増加（512 MB → 1024 MB）
│     効果: CPU スロットリング解消 → Duration 短縮 → キュー処理加速
│
├─ 中期対応:
│  ├─ DynamoDB Query 最適化（slow query 修正）
│  └─ Lambda v2.5 の コードプロファイリング
│     メモリリークまたは計算量多いロジック特定
│
└─ 長期対応:
   ├─ 自動スケーリング ポリシー導入
   │  └─ SQS queue depth > 100 で Lambda コンカレンシー自動増加
   │
   └─ メッセージ処理の並列化
      Batch Size 増加（10 件 → 100 件/Lambda 実行）

成果： キュー遅延の根本原因特定・処理効率化。

9. EventBridge 統合による自動対応・通知

要件： DevOps Guru Insight 生成時に Slack・PagerDuty へ自動通知・Lambda で自動修復。

実装：

# EventBridge ルール: DevOps Guru Insight 生成時
aws events put-rule \
  --name devops-guru-insight-notification \
  --event-pattern '{
    "source": ["aws.devops-guru"],
    "detail-type": ["DevOps Guru New Insight Open"],
    "detail": {
      "insightSeverity": ["HIGH", "MEDIUM"]
    }
  }'

# Target: Slack
aws events put-targets \
  --rule devops-guru-insight-notification \
  --targets '[{
    "Id": "1",
    "Arn": "arn:aws:events:us-east-1:123456789012:event-bus/default",
    "HttpParameters": {
      "HeaderParameters": {
        "X-Slack-Token": "xoxb-..."
      },
      "QueryStringParameters": {
        "channel": "#devops-alerts"
      }
    }
  }]'

# Target: Lambda（自動修復）
aws events put-targets \
  --rule devops-guru-insight-notification \
  --targets '[{
    "Id": "2",
    "Arn": "arn:aws:lambda:us-east-1:123456789012:function:auto-remediate-devops-guru-insight"
  }]'

Lambda 関数（自動修復）:

def lambda_handler(event, context):
    insight = event['detail']
    insight_type = insight['insightType']
    
    if insight_type == 'DynamoDB Write Throttling':
        # DynamoDB WCU 自動増加
        scale_dynamodb_wcu(insight['resourceName'], increase_percentage=50)
        
    elif insight_type == 'Lambda Duration Increase':
        # Lambda メモリ自動増加
        increase_lambda_memory(insight['resourceName'], new_memory=1024)
        
    elif insight_type == 'RDS Slow Query':
        # RDS スケールアップ
        scale_rds_instance(insight['resourceName'], new_instance_class='db.r5.large')
    
    # Slack 通知
    notify_slack(f"""
    DevOps Guru Auto-Remediation Executed
    Insight: {insight_type}
    Resource: {insight['resourceName']}
    Action Taken: {action_name}
    """)
    
    return {'statusCode': 200}

成果： Insight 生成時に自動通知・自動修復開始。MTTR 最小化。

10. CloudFormation スタック単位の環境別監視

要件： dev・staging・prod を CloudFormation スタック単位で分離監視。

実装：

# Prod スタック監視設定
aws devops-guru update-resource-collection \
  --action ADD \
  --resource-collection '{
    "CloudFormation": {
      "StackNames": ["prod-*"]
    }
  }'

# Staging スタック監視設定
aws devops-guru update-resource-collection \
  --action ADD \
  --resource-collection '{
    "CloudFormation": {
      "StackNames": ["staging-*"]
    }
  }'

# Dev は監視スキップ（コスト節約）

成果： 環境別管理・本番との分離・コスト最適化。

2025-2026 最新動向・End-of-Life 計画

重要：DevOps Guru End-of-Life（2026 年 4 月 30 日）

AWS は 2026 年 4 月 30 日に Amazon DevOps Guru のサポート終了を発表しています。

移行推奨先:

1. CloudWatch Application Signals: SLO・エラーバジェット・自動スケーリング推奨
2. Q Developer Operations: 生成 AI による自動トラブルシューティング
3. CloudWatch Anomaly Detector: メトリクス単位の異常検知

移行パス

Phase 1: 情報収集・評価（2026 年 1-2 月）

# DevOps Guru Insight を CloudWatch Logs にエクスポート
# 過去 6 ヶ月の Insight をダウンロード
aws devops-guru list-insights \
  --insight-type REACTIVE \
  --status CLOSED \
  --start-time-range Before=2026-04-01,After=2025-10-01 > insight_history.json

# Application Signals 対応言語・フレームワーク確認
# Python / Node.js / Java / .NET / Go がサポート対象

Phase 2: Application Signals への移行（2026 年 2-3 月）

# CloudFormation で Application Signals 有効化
Resources:
  ApplicationSignalsEnabled:
    Type: AWS::CloudWatch::ApplicationSignals
    Properties:
      Enabled: true
      EKSCluster: eks-prod-cluster
      Services:
        - Name: order-service
          Port: 5000
        - Name: payment-service
          Port: 8080

  # SLO 定義（従来の DevOps Guru Insight の代わり）
  OrderServiceSLO:
    Type: AWS::CloudWatch::ServiceLevelObjective
    Properties:
      ServiceName: order-service
      Objectives:
        - Name: Availability
          Target: 99.9
          Window: 30DAY
        - Name: Latency
          Metric: LatencyP99
          Target: 200ms
          Window: 30DAY

Phase 3: Q Developer Operations トライアル（2026 年 3-4 月）

# Q Developer Operations で自動トラブルシューティング試用
aws bedrock generate-text \
  --model-id claude-3-5-sonnet \
  --messages '[{
    "role": "user",
    "content": "CloudWatch アラートを解析して、root cause を特定し、修復ステップを提案してください"
  }]'

# Application Insights を Q に統合
# → 自動異常検知 → 生成 AI で根本原因分析 → Slack 通知

Phase 4: DevOps Guru 廃止（2026 年 5 月以降）

# DevOps Guru 無効化
aws devops-guru put-feedback \
  --insight-feedback '[{
    "id": "arn:aws:devops-guru:us-east-1:123456789012:insight/reactive/...",
    "feedback": "CLOSED"
  }]'

# 全 Resource Collection 削除
aws devops-guru delete-resource-collection \
  --resource-collection '{
    "CloudFormation": { "StackNames": ["*"] }
  }'

ベストプラクティス・チェックリスト

✅ 推奨

• [ ] CloudFormation / Tag ベースで Resource Collection を指定（Account 全体はコスト高）
• [ ] Insight を CloudWatch Logs に記録（監査・分析用）
• [ ] EventBridge でSlack・PagerDuty に自動通知
• [ ] DevOps Guru for RDS を有効化（本番 RDS がある場合）
• [ ] ベースライン学習期間（2 週間）を尊重。その後にアラート調整
• [ ] Insight Recommendation を定期的に確認・実装（CI/CD に組み込み）
• [ ] 2026 年 4 月 30 日の End-of-Life に備え、早期に Application Signals へ移行計画

❌ アンチパターン

• [ ] Account 全体を Resource Collection に追加（不要なリソースまで監視 → コスト高）
• [ ] Insight 無視（アラート疲れ）
• [ ] DevOps Guru Insight を見るだけで実装しない（改善効果なし）
• [ ] ベースライン学習期間を無視（初期誤検知多い）
• [ ] End-of-Life 対応を遅延（2026 年 5 月以降、DevOps Guru サポートなし）

学習リソース・参考文献

公式ドキュメント

• Amazon DevOps Guru ユーザーガイド
• DevOps Guru API Reference
• CloudWatch Application Signals

移行リソース

• DevOps Guru End-of-Life 公式発表
• Application Signals Migration Guide

競合ツール比較

• Datadog Watchdog
• New Relic AIOps
• Splunk Observability
• IBM Watson AIOps
• BigPanda

まとめ

Amazon DevOps Guru は、ML 駆動の自動異常検知・根本原因分析サービスです。

主な利点

• 自動異常検知: 固定閾値不要。ML が正常パターン学習
• 複合異常検知: 複数メトリクスの相関・イベント関連付け
• 具体的推奨: 修復ステップを自動生成
• 低運用負荷: ベースライン学習後は自動動作

重要な注意事項

⚠️ DevOps Guru は 2026 年 4 月 30 日に End-of-Life となります。

新規プロジェクトは CloudWatch Application Signals への導入を推奨。既存 DevOps Guru ユーザーは、早期に移行計画を開始してください。

推奨対象

• 本番環境の異常検知が必須: 金融・医療・SaaS
• 複数 AWS サービス統合環境: マイクロサービス・EKS・RDS 等
• DevOps 文化強い組織: 自動化・CI/CD 重視

DevOps Guru は 2025-2026 年の最後の主力リリース期間です。End-of-Life 前に、最大限の異常検知・推奨事項活用を実現し、段階的に CloudWatch Application Signals へ移行することで、スムーズな AIOps への進化が実現できます。

最終更新：2026-04-27 バージョン：v2.0 重要：DevOps Guru End-of-Life は 2026 年 4 月 30 日です。