aws-resource-health-diagnose

AWS リソースの健全性と問題の診断

このワークフローでは、特定の AWS リソースを分析して健全性ステータスを評価し、CloudWatch のログとメトリクスを使用して潜在的な問題を診断し、発見された問題に対する包括的な修復計画を策定します。

前提条件

• AWS CLI の設定と認証が完了していること
• 対象の AWS リソースが特定されていること（名前、タイプ、必要に応じてリージョン／アカウント）
• 対象リソースで CloudWatch のログ記録とメトリクスが有効になっていること

ワークフローの手順

ステップ 1：AWS の診断に関するベストプラクティスを確認する

診断方法の参考として、監視とトラブルシューティングのガイダンスを得るために https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ を取得します。

ステップ 2：リソースの検出と特定

リソースのタイプに適した AWS CLI コマンドを使用して対象リソースを特定します。

# EC2
aws ec2 describe-instances --filters "Name=tag:Name,Values=<name>"
# Lambda
aws lambda get-function --function-name <name>
# RDS
aws rds describe-db-instances --db-instance-identifier <name>
# ECS
aws ecs describe-services --cluster <cluster> --services <name>
# ALB
aws elbv2 describe-load-balancers --names <name>
# DynamoDB
aws dynamodb describe-table --table-name <name>
# SQS
aws sqs get-queue-attributes --queue-url <url> --attribute-names All
# API Gateway
aws apigatewayv2 get-apis

複数の一致が見つかった場合は、リージョン／アカウントを指定するようユーザーに求めます。

ステップ 3：健全性ステータスの評価

サービス固有の健全性チェックを実行します。

# EC2
aws ec2 describe-instance-status --instance-ids <id>

# RDS
aws rds describe-db-instances --db-instance-identifier <name> \
  --query 'DBInstances[0].DBInstanceStatus'

# Lambda - error rate over 24h
aws cloudwatch get-metric-statistics --namespace AWS/Lambda \
  --metric-name Errors --dimensions Name=FunctionName,Value=<name> \
  --start-time $(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 3600 --statistics Sum

# ECS
aws ecs describe-services --cluster <cluster> --services <name> \
  --query 'services[0].[status,runningCount,desiredCount,pendingCount]'

サービスのタイプごとの主な健全性指標：

• Lambda：エラー率、スロットリング率、実行時間 P99、同時実行数
• RDS：CPU 使用率、FreeStorageSpace、DatabaseConnections、ReadLatency／WriteLatency
• ECS：実行中のタスク数と希望タスク数の比較、タスクの停止理由
• ALB：TargetResponseTime、HTTPCode_ELB_5XX_Count、UnHealthyHostCount
• SQS：ApproximateNumberOfMessagesNotVisible、ApproximateAgeOfOldestMessage
• DynamoDB：ConsumedReadCapacityUnits、ThrottledRequests、SuccessfulRequestLatency

ステップ 4：ログとメトリクスの分析

ロググループを見つけ、CloudWatch Logs Insights のクエリを実行します。

# Find log groups
aws logs describe-log-groups --log-group-name-prefix /aws/<service>/<name>

# Start a query (last 24h errors)
aws logs start-query \
  --log-group-name /aws/lambda/<name> \
  --start-time $(date -u -d '24 hours ago' +%s) \
  --end-time $(date -u +%s) \
  --query-string 'filter @message like /ERROR/ | stats count(*) as errorCount by bin(1h)'

# Get results
aws logs get-query-results --query-id <id>

# Lambda cold starts
aws logs start-query \
  --log-group-name /aws/lambda/<name> \
  --start-time $(date -u -d '24 hours ago' +%s) \
  --end-time $(date -u +%s) \
  --query-string 'filter @type = "REPORT" | filter @initDuration > 0 | stats count() as coldStarts by bin(1h)'

# RDS Performance Insights (if enabled)
aws pi get-resource-metrics \
  --service-type RDS --identifier db:<identifier> \
  --metric-queries '[{"Metric":"db.load.avg"}]' \
  --start-time $(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period-in-seconds 3600

繰り返し発生するエラーパターン、デプロイとの相関関係（CloudTrail）、パフォーマンスの傾向、依存関係の障害を特定します。

ステップ 5：問題の分類と根本原因の分析

重大度：

• 重大：サービス停止、データ損失、セキュリティインシデント
• 高：パフォーマンスの低下、エラー率が 5% を超える状態、断続的な障害
• 中：警告、最適でない設定、軽微なパフォーマンスの問題
• 低：情報提供を目的とするアラート、最適化の機会

根本原因のカテゴリ：

• 設定の問題：誤った設定、環境変数の不足、IAM 権限の拒否
• リソースの制約：CPU／メモリ／ディスクの上限、Lambda のスロットリング、RDS の接続枯渇
• ネットワークの問題：セキュリティグループのルール、VPC ルーティング、DNS、NACL
• アプリケーションの問題：コードのバグ、メモリリーク、未処理の例外、低速なクエリ
• 依存関係の問題：下流サービスのタイムアウト、SQS／SNS の障害、外部 API の制限
• セキュリティの問題：KMS キーの問題、証明書の有効期限切れ

ステップ 6：修復計画を作成する

即時対応（重大）：

# Lambda throttling — increase reserved concurrency
aws lambda put-reserved-concurrency \
  --function-name <name> --reserved-concurrent-executions 100

# RDS connection exhaustion — reboot to reset connections
aws rds reboot-db-instance --db-instance-identifier <name>

短期的な修正（高／中）：設定の調整、適正なリソースサイズへの変更、CloudWatch アラームの改善、IAM 権限の修正。

長期的な改善：耐障害性を高めるためのアーキテクチャ変更、予防的な監視、EventBridge を介した AWS Health Dashboard 通知の有効化。

ステップ 7：結果の報告とユーザーの確認

調査結果を提示します。

🏥 AWS Resource Health Assessment

📊 Resource Overview:
• Resource: [Name] ([Type])
• Status: [Healthy/Warning/Critical]
• Region: [Region] | Account: [Account ID]

🚨 Issues Identified:
• Critical: X | High: Y | Medium: Z | Low: N

🔍 Top Issues:
1. [Issue]: [Description] — Impact: [High/Medium/Low]
2. [Issue]: [Description] — Impact: [High/Medium/Low]

🛠️ Remediation: X immediate, Y short-term, Z long-term actions

❓ Proceed with detailed remediation plan? (y/n)

次に、健全性メトリクス、根本原因分析を含む問題、段階的な修復手順と AWS CLI コマンド、CloudWatch アラームの推奨事項、検証チェックリストを網羅した完全な Markdown レポートを作成します。

エラー処理

• リソースが見つからない：名前／リージョンを確認するようユーザーに求めます
• 認証の問題：aws configure の手順を案内します
• 権限不足：必要な IAM アクション（logs:*、cloudwatch:*、pi:*）を列挙します
• ログがない：そのリソースタイプで CloudWatch のログ記録を有効にするよう提案します
• クエリのタイムアウト：より短い時間範囲を使用します

成功基準

• ✅ すべての主要なメトリクスに基づいて、リソースの健全性が正確に評価されている
• ✅ 重大な問題がすべて特定され、重大度別に分類されている
• ✅ 主要な問題について根本原因の分析が完了している
• ✅ AWS CLI コマンドを含む、実行可能な修復計画がある
• ✅ CloudWatch の監視に関する推奨事項が含まれている
• ✅ 実装手順に検証とロールバックの手順が含まれている