「なんとなく監視」を卒業！AWS Lambda運用を”自信”に変える実践オブザーバビリティ

1. はじめに

この記事では、サーバーレス（Function as a Service、FaaS）アプリケーションを対象に、どのように監視（モニタリング／オブザーバビリティ）を設計・実装すれば運用が安定し、問題発生時の対応がスムーズになるかを一緒に見ていきましょう😼

対象読者は

• AWS Lambda をこれから導入／高度化したい方
• 業務で AWS サーバーレス（Lambda + API Gateway など）を使っていて監視の自動化や改善を検討している方
• 障害対応時間短縮・コスト最適化・SLO 達成率向上を目指したい方

🎯 この記事で記載していること（Before/After）

項目	Before（監視未整備）	After（実践後）
障害検知	ユーザー報告で発覚（30分～数時間）	アラームで即1分以内に検知
原因特定	ログ検索に30分以上	相関ID+トレースで5分以内
MTTR	平均2時間	平均15分（自動復旧含む）
コスト視認性	月末の請求で初めて把握	日次ダッシュボードで即時把握
SLO達成率	計測していない	99.9%可用性を維持・証明可能

📖 この記事の使い方

初めての方 「2. 背景」→「3.6 クイックスタート」→「3.1 主要メトリクス（基本のみ）」を読む
実装中の方 「3.2 ログ・トレース戦略」→「3.3 ツール・設定例」を中心に
最適化したい方 「3.4 コスト最適化」→「3.5 自動対応」を参照
という風にお使いください🐱

📝 目次

1. はじめに - 対象読者・記事の使い方
2. 背景・前提知識 - なぜ監視が重要か・SLO/SLIの基礎
3. 本題
   • 3.1 監視すべき主要メトリクス（基本→発展）
   • 3.2 ログ・トレース戦略（構造化ログ・分散トレース）
   • 3.3 ツール・設定例（コード・アラート設定）
   • 3.4 コスト最適化（Power Tuning・SnapStart）
   • 3.5 異常検知後の自動対応（上級）
   • 3.6 ⚡ クイックスタート（30分で始める監視）
4. よくあるミスや注意点 - トラブルシューティング
5. まとめ - 学び・今後の展望
6. 出典 - 参考資料

2. 背景・前提知識

なぜサーバーレス監視が重要か

サーバーレスアプリケーションには、従来のサーバーベース（VM／コンテナ等）とは異なる以下のような特徴があります。

• インスタンスが短命である（関数実行時のみ起動） → 状態を保持するものが少ない
• スケーラビリティが自動であるため、呼び出し回数・同時実行数（concurrency）等が急変する
• コールドスタート（初回起動遅延）がレイテンシばらつき要因になる
• 課金が実行回数・時間・メモリに直接紐づくため非効率がコストに直結してしまう

🏗️ 参考）監視アーキテクチャ全体像

📈 現在の監視状態

まずは自社／自分の現在地をチェックしてみてください💡
一気に完璧を目指さず、段階的にステップアップしていくことが大切です。

レベル	特徴	具体例	次のステップ
Lv.0 なし	監視未導入	ユーザー報告で障害発覚	→ 3.6 クイックスタート
Lv.1 基本	ダッシュボード+アラーム	Errors/Duration 監視	→ 構造化ログ導入
Lv.2 構造化	相関ID+トレース	5分以内で原因特定	→ SLO定義+エラー予算
Lv.3 SLO駆動	エラー予算運用	リリース判断に活用	→ 自動復旧導入
Lv.4 自律的	自動復旧+予測	MTTR 15分以下	→ 予測的運用

前提知識

• Lambda の実行モデル（同期/非同期/イベントソースマッピング、timeout、メモリ、同時実行設定）
• ログ / メトリクス / 分散トレース基礎
• CloudWatch (Metrics / Logs / Logs Insights / Dashboard / Alarms)
• X-Ray / ADOT（OpenTelemetry）概要
• SLI / SLO / エラー予算の概念

代表的な SLO / SLI 例（API 主体）

目的	SLI 定義	集計期間	SLO 例	備考
可用性	成功数 / 総 Invocations	30日	99.9%	Timeout/例外/権限失敗含む
レイテンシ	p95 Duration	30日	< 800ms	コールドスタート込み
エラー予算	1 - 可用性	30日	0.1%	使い切りで変更凍結
コスト効率	GB-秒 / 成功リクエスト	7日	基準 +10% 以内	Power Tuning 指標

※注意事項
可用性 SLI は「再試行を含む最終結果ベース」を推奨。非同期イベントは初回失敗後の再試行成功でユーザー影響が吸収されるため、初回試行ベース ErrorRate と差異が出る。初回試行を別 KPI とする場合は InitialAttemptErrorRate など別名で併存させ指標混同を防ぎましょう。

---

3. 本題

3.1 監視すべき主要メトリクス／指標

🔰 初心者の方へ 「メトリクス多すぎ！」と感じたら、まずは下表の 太字 の5つ（Invocations、Errors、Duration、Throttles、ConcurrentExecutions）だけ押さえればOKです👍 詳細は「3.6 クイックスタート」から読み始めると理解しやすいです！

基本メトリクス（必須）

メトリクス名	意味	重要性 / 活用ポイント
Invocations	呼び出し総数（成功/失敗含む）	トラフィック把握・キャパ計画・コスト試算 (AWS ドキュメント)
Errors	失敗数（未処理例外 / Timeout / OOM / 権限エラー などの関数実行失敗。Throttles は含まれない）	品質/安定性指標。内訳分類（種別、例外名）で改善領域特定。スロットルはThrottles で別監視 (AWS ドキュメント)
Duration	実行時間 (ms)	レイテンシ管理 / コスト最適化 / 性能退行検知 (AWS ドキュメント)
Throttles	制限超過で拒否された呼び出し数	キャパ不足・予測外スパイクの指標 (AWS ドキュメント)
ConcurrentExecutions	同時実行インスタンス数	上限接近検知・他関数干渉防止 (AWS ドキュメント)
ProvisionedConcurrencyUtilization	プロビジョンド確保分の利用率	事前ウォーム最適化・コストバランス (AWS ドキュメント)
IteratorAge (イベントソース)	ストリーム/キュー遅延	バックログ遅延 → ユーザー影響前検知
DeadLetterErrors	失敗イベントの DLQ 移送失敗	再処理不能リスクの早期検知
コールドスタート（派生）	新環境初期化遅延（公式標準メトリクス無し）	p95/p99 悪化要因切り分け CloudWatch Logs REPORT 行 "Init Duration" 抽出 / Insights / カスタム近似 (signoz.io)
Max Memory Used	使用最大メモリ	過不足判定→メモリ調整 & Power Tuning (Datadog)

補足 Ephemeral Storage 利用量、外部依存呼び出し失敗率、Retries、AsyncEventsReceived / AsyncEventsRetried / AsyncEventsFailed / AsyncEventsDropped / AsyncEventAge（Failed=全再試行後も失敗、Dropped=期限/上限超過破棄、Retried=再試行投入数）、AsyncEventsThrottle、ProvisionedConcurrencySpilloverInvocations（本表では Spillover と簡略）、DLQ 送信失敗数 なども観測候補。

Lambda Insights 拡張メトリクス（主要）

UI 表示ラベル（管理コンソール上）。以下“識別ラベル”は本文内便宜名称で内部 API 公式 ID ではない（名称ロックイン回避）。ダッシュボード作成時は CloudWatch 公式 Metric 名で再確認すること（例 UI "Init Duration" → InitDuration,UI "Billed Duration" → BilledDuration）。

UI 表示 / 意味	識別ラベル	観点	活用ポイント
Init Duration	init_duration	コールドスタート初期化	初期化 vs 実行の内訳分解、ウォーム戦略評価
Post Init Duration	post_init_duration	初期化後オーバーヘッド	拡張/後処理最適化余地把握
Post Runtime Extensions Duration	post_runtime_extensions_duration	拡張初期化	不要 Extension 削減検討
Runtime Duration	runtime_duration	ハンドラー実行	Duration との差で初期化・計測オーバーヘッド推定
Billed Duration	billed_duration	課金対象時間	実時間との差異監視（課金効率）
Max Memory Used	max_memory_used	メモリピーク	割当再調整と CPU/帯域向上効果検証
Memory Utilization	memory_utilization	メモリ使用率	>70% 継続で割当増検討 / <40% 継続で減量検討
CPU Total Time	cpu_total_time	CPU 使用総時間	I/O 待ち切り分け（runtime_duration 比）
Network RX Bytes	network_rx_bytes	ネットワーク入力	外部依存増大/スローダウン兆候
Network TX Bytes	network_tx_bytes	ネットワーク出力	ペイロード肥大/圧縮検討トリガ

運用指針例

• コールドスタート最適化： init_duration + post_init_duration の合計 7日移動平均を基準にスパイク検出
• メモリ調整： max_memory_used / total_memory (割当) ≈ 0.4 未満継続なら減量検討 / 0.75 超継続なら増量ベンチ（ヒューリスティック： I/O/CPU 特性に応じ再調整）
• CPU ボトルネック判定： cpu_total_time / runtime_duration が高く memory_utilization 低 → メモリ増で CPU 割当増→短縮余地
• ネットワーク異常： network_rx_bytes or network_tx_bytes の急上昇 + Duration 悪化 → 外部 API レイテンシ/ペイロード肥大調査
• スムージング： エラー率/初期化遅延などスパイク多発指標は 5 点移動平均や EMA(α≈0.3) を併記し、アラームは平滑値+連続評価(≥2 期間) 条件でノイズ低減
• アーキテクチャ比較： 同一コードで x86_64 / arm64 の init_duration / p95 Duration をカスタム次元 arch 付きで記録し比較→コスト/レイテンシ両面の切替判断材料
• メモリしきい値補足： 0.4 / 0.75 は経験則。CPU バウンドや外部 I/O 比率で適正帯は変動するため定期リベース（Power Tuning 再実行）

コールドスタート計測実装例：

1. CloudWatch Logs REPORT 行から Init Duration: の数値を抽出→初回のみカスタムメトリクス ColdStartCount 送信。
2. Lambda Insights の Init Duration を集計。
3. ADOT ランタイム初期化フックで cold_start=true 属性付きスパン送信→スパン件数集計。

イベントソース別 追加指標（抜粋）

ソース	重点指標	目的	代表メトリクス	補足
API Gateway(REST)	4XXError / 5XXError / Latency / IntegrationLatency	UX / 下流遅延	AWS/ApiGateway Latency	IntegrationLatency=バックエンド区間
API Gateway(HTTP)	Count / 4XX / 5XX / DataProcessed	トラフィック/異常	AWS/ApiGateway v2	v2 メトリクス差異
SQS	ApproximateAgeOfOldestMessage / ApproximateNumberOfMessagesVisible	バックログ遅延	AWS/SQS ApproximateAgeOfOldestMessage	Age 長期化で遅延
Kinesis	GetRecords.IteratorAgeMilliseconds / Throttles	遅延/供給不足	AWS/Kinesis GetRecords.IteratorAgeMilliseconds	変換=レイテンシ指標
DynamoDB Streams	GetRecords.IteratorAgeMilliseconds	変更反映遅延	AWS/DynamoDB GetRecords.IteratorAgeMilliseconds	Streams 同名
Step Functions	ExecutionsFailed / TimedOut / Throttled	ワークフロー健全性	AWS/States ExecutionsFailed	状態遷移失敗率
EventBridge	FailedInvocations / PutEventsFailedEntries	配送失敗	AWS/Events FailedInvocations	DLQ 別監視
Cognito	SignInFailures / SignInSuccesses	認証可用性	AWS/Cognito SignInFailures	リージョン差異注意
Event Source Mapping	IteratorAge / DeadLetterErrors	消費遅延/再送失敗	AWS/Lambda IteratorAge	Kinesis / DynamoDB Streams 対象（SQS には該当しない）

---

3.2 ログ・トレース戦略

ロギングベストプラクティス

• 構造化 JSON： requestId、function、level、timestamp、cold_start などキー統一 (Movestax)
• レベル運用： 本番 INFO 以上 / 調査時一時的 DEBUG（自動 TTL 解除）
• 相関 ID： X-Correlation-Id ヘッダ伝播・外部 API 連携で再利用
• マスキング： PII / Secrets / Token は出力前フィルタリング
• サンプリング： 正常大量イベントは比率低下、エラーは 100% 保持でコスト最適化
• 二次転送： Logs Insights で一次分析→OTEL Collector → 外部（Datadog 等）

分散トレース

• X-Ray / ADOT で呼び出し経路・外部依存遅延集中点を可視化 (AWS ドキュメント)
• コールドスタート区間をスパン属性化 (cold_start_duration_ms)
• 外部 SDK 自動インスツルメント対象外 I/O は手動スパン

X-Ray / OpenTelemetry 最小導入手順

1. SAM/CloudFormation Tracing Active（X-Ray） or ADOT 設定
2. ADOT Collector / Layer → OTLP Export (HTTP or gRPC)
3. スパン命名 <system>.<function> (orders.createHandler 等)
4. 未自動計測 I/O を startSpan/endSpan で包む
5. REPORT 行 Init Duration と最初のスパン開始スパン差を cold start 属性に格納

Logs Insights クエリ例

関数別 p95/p99

fields @timestamp, @message
| filter @type = "REPORT" and ispresent(Duration)
| stats pct(Duration,95) as p95_ms, pct(Duration,99) as p99_ms, avg(Duration) as avg_ms by @logStream
| sort p95_ms desc

相関 ID 追跡

fields @timestamp, @message
| filter requestId = 'REPLACE_ME'
| sort @timestamp asc

直近 5 分エラー Top5 例外

fields @timestamp, @message, @logStream
| filter level = "ERROR" and @timestamp > ago(5m)
| parse @message /"errorMessage":"(?<emsg>[^"]+)/
| stats count() as c by emsg
| sort c desc
| limit 5

---

3.3 ツール・設定例

監視構成ステップ（例）

1. Lambda Insights 有効化 → CPU/メモリ/Init Duration 取得 (AWS ドキュメント)
2. 主要メトリクス/イベントソースメトリクスをダッシュボード集約
3. 構造化ログ + 相関 ID ミドルウェア組込
4. X-Ray または ADOT トレース導入（外部依存遅延の可視化）
5. ダッシュボード Invocations、ErrorRate、Duration p95/p99、Throttles、IteratorAge、ColdStartCount
6. アラート（Metric Math）： 下記条件例

アラート条件例

• ErrorRate = Errors / MAX(Invocations,1) > SLO×2 （連続 N 期）
• ColdStartCount > 7日移動平均 + 3σ
• ConcurrentExecutions / AccountLimit > 0.8
• IteratorAge p90 > 閾値（Lambda Event Source Mapping） / GetRecords.IteratorAgeMilliseconds p90 > 閾値（Kinesis/DynamoDB Streams）※ バッチサイズ変更直後 1-2 評価期間は抑制
• ProvisionedConcurrencySpilloverInvocations > 0 （連続 2 評価）

構造化ログ例（Node.js）

// lambda_function.js
const { v4: uuidv4 } = require('uuid');

exports.handler = async (event, context) => {
  const requestId = context.awsRequestId || uuidv4();
  const functionName = context.functionName;
  const coldStart = !!context.getRemainingTimeInMillis && !global._init; // 簡易判定
  if (!global._init) global._init = true;
  const start = Date.now();

  const log = (level, msg, extra={}) => console.log(JSON.stringify({
    requestId,
    function: functionName,
    level,
    message: msg,
    cold_start: coldStart,
    timestamp: new Date().toISOString(),
  // PII/Secrets を含むフィールドは投入前に除去/マスキング
  ...redact(extra)
  }));

  try {
    log('INFO', 'Function invoked');
    await someBusinessLogic(event); // ユーザ処理
    const duration = Date.now() - start;
    log('INFO', 'Function succeeded', { durationMs: duration });
    return { statusCode: 200, body: JSON.stringify({ success: true }) };
  } catch (err) {
    const duration = Date.now() - start;
    log('ERROR', 'Function failed', { durationMs: duration, errorMessage: err.message, stack: sanitizeStack(err.stack) });
    throw err;
  }
};

function redact(obj){
  const c = { ...obj };
  if (c.password) c.password = '[REDACTED]';
  if (c.token) c.token = '[REDACTED]';
  return c;
}
function sanitizeStack(stack){
  if(!stack) return undefined;
  return stack.split('\n').slice(0,5).join('\n'); // 最初の数フレームのみで情報量最小化
}

CloudTrail 経由イベントは通常 15分以内の遅延があるため、即時性が要求されるクリティカルシークレットでは補助として失敗検知メトリクス (例：アプリ側認証失敗率急増) やヘルスチェックアラームを併用する。

実運用：detail.alarmName 固定マッチは名前変更でドリフトするため detail.alarmArn の ARN 前方一致や、アラームへ共通タグ (例 auto-remediate=true) を付与し EventBridge でタグフィルタ（resources 条件）する設計が堅牢。

CloudWatch アラーム（Metric Math エラー率）

条件：5 分間で Invocations ≥ 100 かつ ErrorRate > 1%

{
  "AlarmName": "LambdaErrorRateHigh",
  "ComparisonOperator": "GreaterThanOrEqualToThreshold",
  "EvaluationPeriods": 1,
  "Threshold": 1,
  "TreatMissingData": "notBreaching",
  "Metrics": [
    {"Id": "e", "MetricStat": {"Metric": {"Namespace": "AWS/Lambda", "MetricName": "Errors", "Dimensions": [{"Name": "FunctionName", "Value": "my-function"}]}, "Period": 300, "Stat": "Sum"}},
    {"Id": "i", "MetricStat": {"Metric": {"Namespace": "AWS/Lambda", "MetricName": "Invocations", "Dimensions": [{"Name": "FunctionName", "Value": "my-function"}]}, "Period": 300, "Stat": "Sum"}},
    {"Id": "er", "Expression": "IF(i<100,0,(e/i)*100)", "Label": "ErrorRatePercent"}
  ],
  "AlarmActions": ["arn:aws:sns:us-east-1:123456789012:NotifyTopic"]
}

注 TreatMissingData を notBreaching にすることでデプロイ直後や低トラフィックで欠損した期間の誤警報を抑制。Metric Math の IF(i<100,0,...) と組み合わせ母数不足ノイズを更に低減。

エラー率解釈注意 Errors は試行 (attempt) 毎にカウントされ再試行で複数増加し得る。一方 SLO 可用性 (最終結果) は再試行成功なら成功扱い。差分は RetrySalvageRate = IF(InitialFailures=0,0,(InitialFailures - FinalFailures) / InitialFailures) として可視化し、再試行がどれだけユーザー影響を吸収しているかを把握する。

実装例（初回試行失敗カウント）

1. ハンドラーラッパで最初の attempt 時にのみ InitialAttemptFailureCount カスタムメトリクス (EMF) を出力。
2. 最終失敗は既存 Errors と同じ（非同期は再試行最終結果）。
3. Logs Insights スケジュールクエリで attempt=1 失敗ログ集計→InitialAttemptFailures として PutMetricData。
4. Metric Math で RetrySalvageRate & Salvage 数をダッシュボード化。

この 2 系列から Salvage (吸収) 数 = InitialAttemptFailures - FinalFailures を算出可能。

コールドスタート検出（REPORT 行 Init Duration 抽出時のみ）:

aws cloudwatch put-metric-data \
  --namespace Custom/Lambda \
  --metric-name ColdStartCount \
  --value 1 \
  --dimensions FunctionName=my-function

---

3.4 コスト最適化（基礎）

テクニック	目的	アクション	注意
メモリ最適化 (Power Tuning)	実行/GB-秒削減	メモリ別ベンチ → 最小コスト点	CPU/帯域増効果再計測 (PowerTuning)
Provisioned Concurrency	レイテンシ安定	ピーク前スケジュール / Auto Scaling	過剰分縮退 & コスト試算
Reserved Concurrency	他関数保護	重要関数へ下限/上限設定	誤設定でスロットル誘発注意
SnapStart	コールド削減	有効化 + 初期化軽量化	Java 11以降、Python 3.12以降、.NET 8以降対応。非対応言語は Provisioned Concurrency + 初期化軽量化で代替 / 暗号鍵リシード・一時状態考慮。大量ランダム初期化 / 重い外部 API 起動時呼び出しが残ると効果限定的 (SnapStart)
DLQ / Destinations	失敗隔離	OnFailure ルーティング	保存期間 & 再処理 Runbook
Cost Anomaly Detection	逸脱検出	検出結果 → ChatOps 通知	誤検知でしきい調整
AWS Budgets	予算逸脱予兆	月次/日次通知	Free Tier 差分考慮

概算式（簡易）

総コスト ≈ (有料 Invocations * リクエスト単価)
  + (有料 GB-秒 * GB-秒単価)
  + (Provisioned Concurrency GB-秒 * 単価)
  + (CloudWatch Logs: 取り込み + 保持 + Logs Insights クエリ)
  + (X-Ray + Lambda Insights + 外部 APM 等)
  + (SnapStart: Python/.NET の場合はスナップショット保存料金 + リストア料金)

注: Free Tier (1M リクエスト / 400,000 GB-秒) 差引後。リージョン単価差あり。
SnapStart は Java の場合は追加料金なし。Python/.NET の場合はスナップショット保存料金とリストア料金が発生（2025年11月時点）。

改善サイクル: メモリスイープ → 実行時間短縮 → Concurrency 最適化 → コールド削減(SnapStart) → 週次コストレビュー。

💰 コスト試算例（月間100万リクエストの場合）

項目	設定	計算	月額（東京）
リクエスト費用	100万回	(100万 - 100万 Free) × $0.20/100万	$0
実行時間	512MB, 平均200ms	100万 × 0.5GB × 0.2秒 = 10万 GB-秒	$0 (Free Tier内)
CloudWatch Logs	1リクエストあたり500バイト	100万 × 500B = 500MB	~$0.25
合計			~$0.25/月

最適化前後の比較例:

構成	メモリ	Duration	GB-秒/月	コスト
最適化前	1024MB	300ms	30万	$5.01
Power Tuning後	512MB	250ms	12.5万	$2.08
削減率	-50%	-17%	-58%	-58%

注: Billed Duration は 2020年12月以降、1ms 単位で課金（旧 100ms 最低単位から変更済み）。

---

3.5 異常検知後の自動対応（自動復旧）

監視は「検知」で終わらせず、再現性のある軽微な問題は自動復旧（Auto Remediation）で MTTR をさらに短縮できます。「これ、手動でやらなくて良くない？」と思った対応は、自動化のチャンスです🛠️

全体パターン

1. Detect: CloudWatch Alarm / Anomaly Detection / DevOps Guru / Logs Insights スケジュール結果
2. Route: Alarm 状態変化 EventBridge ルール（source=aws.cloudwatch） or SNS → EventBridge
3. Decide: Lambda (ルール判定/冪等制御) or Step Functions（分岐/リトライ/承認）
4. Act: Application Auto Scaling / Lambda API / SQS 操作 / Systems Manager Automation Runbook / CodeDeploy ロールバック
5. Verify: 変更後メトリクス再評価（成功→記録 / 失敗→再試行 or エスカレーション）
6. Audit: CloudTrail + 監査ログ（auto_remediation=true 属性）

代表ユースケースとアクション

シナリオ	トリガー指標/条件	自動アクション例	安全策（歯止め）
コールドスタート急増	init_duration 7日平均 +3σ	一時的 Provisioned Concurrency 引き上げ	上限閾値 / 期間 TTL / 手動解除優先度
エラー率急増 (デプロイ直後)	新バージョン+ ErrorRate > 直前 30分平均×2	CodeDeploy カナリア or ロールバック	最低母数 (≥100 invocations) / 一度のみ実行
SQS バックログ拡大	Age > 閾値 & VisibleMessages 増加	関数 Reserved Concurrency 増 / バッチサイズ調整	最大増加ステップ制限 / 連続失敗で停止
Kinesis IteratorAge 悪化	p90 IteratorAge > SLA	ParallelizationFactor 増加	シャードリミット監視 / 連続 N 回でエスカレート
Lambda メモリ過少	memory_utilization > 75% 継続	次回デプロイ用パラメータストア値更新	即時本番反映せず PR 自動生成
コスト逸脱	Anomaly Detection 高優先度	詳細レポート生成 + SnapStart 有効候補列挙	変更は人間承認フローへ
Secrets ローテーション失敗	RotateSecret 失敗 / 連続エラー N 回	直前正常版へエイリアス戻し + 再試行スケジュール	1 日最大リトライ回数 / 連続失敗で手動エスカレーション

EventBridge ルール（Alarm 変化検知）例

{
  "Name": "alarm-to-remediation",
  "EventPattern": {
    "source": ["aws.cloudwatch"],
    "detail-type": ["CloudWatch Alarm State Change"],
    "detail": {"state": {"value": ["ALARM"]}, "alarmName": ["LambdaErrorRateHigh"]}
  },
  "Targets": [{"Arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:auto-remediator","Id": "remediator"}]
}

自動スケール（Provisioned Concurrency 増減）Lambda 例（Node.js）

// autoRemediate.js
import { LambdaClient, PutProvisionedConcurrencyConfigCommand, GetProvisionedConcurrencyConfigCommand } from '@aws-sdk/client-lambda';
const client = new LambdaClient({});

const MAX_PC = 50; // 安全策の上限値
const STEP = 5;    // 増分

export const handler = async (event) => {
  const functionName = 'my-func';
  const qualifier = 'live'; // エイリアス
  try {
    const current = await client.send(new GetProvisionedConcurrencyConfigCommand({ FunctionName: functionName, Qualifier: qualifier }));
    const pc = current.RequestedProvisionedConcurrentExecutions;
    if (pc >= MAX_PC) return { skipped: true, reason: 'at_max' };
    const next = Math.min(pc + STEP, MAX_PC);
    await client.send(new PutProvisionedConcurrencyConfigCommand({ FunctionName: functionName, Qualifier: qualifier, ProvisionedConcurrentExecutions: next }));
    return { updated: true, from: pc, to: next };
  } catch (e) {
    // 冪等/失敗記録
    console.error(JSON.stringify({ level: 'ERROR', message: 'remediation_failed', error: e.message }));
    throw e;
  }
};

Step Functions オーケストレーション（簡略 ASL）

{
  "StartAt": "CheckRecentDeploy",
  "States": {
    "CheckRecentDeploy": {"Type": "Task", "Resource": "arn:aws:states:::lambda:invoke", "Parameters": {"FunctionName": "check-deploy"}, "ResultPath": "$.deploy"},
    "NeedRollback?": {"Type": "Choice", "Choices": [{"Variable": "$.deploy.errorRateSpike", "BooleanEquals": true, "Next": "Rollback"}], "Default": "Notify"},
    "Rollback": {"Type": "Task", "Resource": "arn:aws:states:::lambda:invoke", "Parameters": {"FunctionName": "rollback"}, "Next": "Verify"},
    "Verify": {"Type": "Task", "Resource": "arn:aws:states:::lambda:invoke", "Parameters": {"FunctionName": "verify"}, "Next": "Done"},
    "Notify": {"Type": "Task", "Resource": "arn:aws:states:::sns:publish", "Parameters": {"TopicArn": "arn:aws:sns:...:incident"}, "Next": "Done"},
    "Done": {"Type": "Succeed"}
  }
}

Secrets Manager ローテーション失敗 自動復旧例

考え方: ローテーション Lambda が失敗し AWSCURRENT が壊れた状態になる前に、直前の正常バージョンへ即時戻し（ロールバック）し、失敗版を隔離。再試行は制限回数内で行い、恒常的失敗はインシデント化。(Secrets Rotation)

EventBridge ルール（RotateSecret 失敗検知 / CloudTrail 経由）例

{
  "Name": "secret-rotation-failure",
  "EventPattern": {
    "source": ["aws.secretsmanager"],
    "detail-type": ["AWS API Call via CloudTrail"],
    "detail": {
      "eventName": ["RotateSecret"],
      "errorCode": [{"exists": true}]
    }
  },
  "Targets": [{"Arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:secret-rotation-remediator","Id": "secret-rollback"}]
}

ロールバック & 再試行 Lambda（Node.js / AWS SDK v3）例

// secretRotationRemediator.js
import { SecretsManagerClient, ListSecretVersionIdsCommand, UpdateSecretVersionStageCommand, RotateSecretCommand } from '@aws-sdk/client-secrets-manager';
import { DynamoDBClient, UpdateItemCommand } from '@aws-sdk/client-dynamodb';

const sm = new SecretsManagerClient({});
const ddb = new DynamoDBClient({});
const TABLE = process.env.METADATA_TABLE; // { pk: 'secret#<name>', attr: attemptCount, lastRollback }
const MAX_DAILY_ATTEMPTS = 5;

export const handler = async (event) => {
  const detail = event.detail || {};
  const arn = detail.requestParameters?.secretId; // CloudTrail イベントから抽出
  if (!arn) return { skipped: true, reason: 'no_secret_arn' };

  const name = arn.split(':').pop();
  // 1. リトライ回数チェック（冪等 & 安全策）
  const attemptOk = await registerAttempt(name);
  if (!attemptOk) return { skipped: true, reason: 'attempt_limit' };

  // 2. バージョン一覧取得
  const versions = await sm.send(new ListSecretVersionIdsCommand({ SecretId: arn, IncludeDeprecated: false }));
  // AWSCURRENT と AWSPREVIOUS を特定
  const current = versions.Versions?.find(v => v.VersionStages?.includes('AWSCURRENT'));
  const previous = versions.Versions?.find(v => v.VersionStages?.includes('AWSPREVIOUS'));
  if (!previous) return { skipped: true, reason: 'no_previous' };

  // 3. 失敗中 current を previous に戻す（current を外し previous を current へ昇格）
  await sm.send(new UpdateSecretVersionStageCommand({
    SecretId: arn,
    VersionStage: 'AWSCURRENT',
    MoveToVersionId: previous.VersionId,
    RemoveFromVersionId: current?.VersionId
  }));

  // 4. 再ローテーション（失敗一時的なら成功する可能性）
  try {
    await sm.send(new RotateSecretCommand({ SecretId: arn }));
  } catch (e) {
    console.error(JSON.stringify({ level: 'ERROR', message: 'rotate_retry_failed', secret: name, error: e.message }));
  }

  return { rolledBackTo: previous.VersionId, previousWas: current?.VersionId };
};

async function registerAttempt(name) {
  const pk = `secret#${name}`;
  const now = Math.floor(Date.now()/1000);
  // DynamoDB で当日カウンタを増加 (TTL は別途設定可)
  const res = await ddb.send(new UpdateItemCommand({
    TableName: TABLE,
    Key: { pk: { S: pk } },
    UpdateExpression: 'ADD attempts :one SET lastAttempt = :ts',
    ExpressionAttributeValues: { ':one': { N: '1' }, ':ts': { N: String(now) } },
    ReturnValues: 'ALL_NEW'
  }));
  const count = parseInt(res.Attributes.attempts.N, 10);
  return count <= MAX_DAILY_ATTEMPTS;
}

安全策補足

• アクセス制御: ロールは対象シークレットの UpdateSecretVersionStage / RotateSecret のみ許可
• 繰り返し発動防止: 同一シークレットでロールバック連続発生 → しきい値超えで Incident Manager
• 監査: CloudTrail + Remediator ログに action=rollback 属性付与
• メトリクス: SecretRollbackCount, SecretRotationRetryCount, 成功率 (RetrySuccess/Retry) を発行

セキュリティ留意点

• ログにシークレット値を絶対出力しない（値→長さ/ハッシュ）
• 古いバージョンの削除ポリシー: ロールバック後に不要となった失敗バージョンは手動確認後廃棄
• KMS キー: ローテーション中にキー権限不足が典型的失敗 → IAM/KMS ポリシー事前テスト
• ロールバック前ヘルスチェック: AWSPREVIOUS 版で DB/外部 API 接続の短時間検証を行い破損シークレットへの巻き戻し防止

---

安全策の設計ポイント

• 繰り返し発動防止: 直近 N 分 (例: 10分) 以内に同種アクション実行済みならスキップ
• 最低母数条件: ErrorRate など割合系は Invocations ≥ 閾値
• Idempotency: DynamoDB / Parameter Store で「最新適用値」記録
• リトライ戦略: 一時的 API スロットルは指数バックオフ + 最大試行回数
• タイムボックス: アクションは短時間で完了しない場合中断（オーケストレーションに委譲）
• エスカレーション: 自動失敗 3 回 (または 30 分内再発 2 回) で Incident Manager 起票

メトリクス（自動対応の健全性）

指標	定義	目的
AutoRemediationAttempts	試行回数	過剰トリガー検知 / ノイズ把握
AutoRemediationSuccess	成功回数	有効性測定
AutoRemediationFailures	Attempts - Success	失敗多発パターン検知
AutoRemediationSuccessRate	Success / Attempts	品質指標（閾値下回りで人手フロー見直し）
MeanAutoRemediationTime	成功までの平均時間	自動化内部効率
EffectiveMTTR	検知→安定まで	利用者影響ウィンドウ評価

補足: MeanAutoRemediationTime (内部処理) と EffectiveMTTR (外部影響) を区別し、後者を短縮するために「自動化後の確認/承認待ち」や下流回復遅延を別途ボトルネック分析する。

追加サービス

• Systems Manager Automation: 標準 Runbook 実行 (SSM Automation)
• Incident Manager: インシデント起票 / オンコールエスカレーション (IncidentManager)
• DevOps Guru: 機械学習による異常検知と推奨アクション提示 (DevOpsGuru)
• Application Auto Scaling: Lambda Provisioned Concurrency のターゲットトラッキング (AppAutoScaling)
• CodeDeploy + CloudWatch Alarms: デプロイ中エラー増で自動ロールバック (CodeDeployRollback)
• Fault Injection Service: 障害注入で自動化 Runbook 検証 (FIS)

導入ステップ（最小実行）

1. 候補選定: Runbook で手動時間が長く成功率高いステップ
2. 成功条件定義: 修復後メトリクス閾値 & タイムウィンドウ
3. CloudWatch Alarm → EventBridge ルール → Lambda 骨格実装
4. 安全策（母数/頻度/上限）追加
5. メトリクス発行（Attempts/Success）+ ダッシュボード化
6. カナリア扱い（限定 1 サービス）→ 逐次展開
7. Chaos/FIS で自動復旧演習 & 証跡保存

---

3.6 ⚡ クイックスタート（30分で始める監視）

「とにかく今すぐ監視を始めたい！」という方、こちらの最小構成からスタートしましょう🚀

Step 1: 基本メトリクスのダッシュボード作成（5分）

CloudWatch コンソールで以下を5つを追加:

1. Invocations (呼び出し数) - Sum, 5分
2. Errors (エラー数) - Sum, 5分
3. Duration (実行時間) - p95, 5分
4. Throttles (スロットル) - Sum, 5分
5. ConcurrentExecutions (同時実行) - Max, 1分

# AWS CLI でダッシュボード作成例
aws cloudwatch put-dashboard --dashboard-name "Lambda-QuickStart" \
  --dashboard-body file://dashboard-basic.json

📄 dashboard-basic.json（クリックで展開）

{
  "widgets": [
    {
      "type": "metric",
      "x": 0, "y": 0, "width": 12, "height": 6,
      "properties": {
        "title": "Invocations & Errors",
        "region": "ap-northeast-1",
        "metrics": [
          ["AWS/Lambda", "Invocations", "FunctionName", "my-function", {"stat": "Sum", "period": 300}],
          [".", "Errors", ".", ".", {"stat": "Sum", "period": 300, "color": "#d62728"}]
        ],
        "view": "timeSeries"
      }
    },
    {
      "type": "metric",
      "x": 12, "y": 0, "width": 12, "height": 6,
      "properties": {
        "title": "Duration (p95)",
        "region": "ap-northeast-1",
        "metrics": [
          ["AWS/Lambda", "Duration", "FunctionName", "my-function", {"stat": "p95", "period": 300}]
        ],
        "view": "timeSeries",
        "annotations": {"horizontal": [{"label": "SLO 800ms", "value": 800}]}
      }
    },
    {
      "type": "metric",
      "x": 0, "y": 6, "width": 12, "height": 6,
      "properties": {
        "title": "Throttles & ConcurrentExecutions",
        "region": "ap-northeast-1",
        "metrics": [
          ["AWS/Lambda", "Throttles", "FunctionName", "my-function", {"stat": "Sum", "period": 300}],
          [".", "ConcurrentExecutions", ".", ".", {"stat": "Maximum", "period": 60, "yAxis": "right"}]
        ],
        "view": "timeSeries"
      }
    },
    {
      "type": "metric",
      "x": 12, "y": 6, "width": 12, "height": 6,
      "properties": {
        "title": "Error Rate (%)",
        "region": "ap-northeast-1",
        "metrics": [
          [{"expression": "IF(invocations > 0, errors / invocations * 100, 0)", "label": "ErrorRate%", "id": "rate"}],
          ["AWS/Lambda", "Errors", "FunctionName", "my-function", {"stat": "Sum", "period": 300, "id": "errors", "visible": false}],
          [".", "Invocations", ".", ".", {"stat": "Sum", "period": 300, "id": "invocations", "visible": false}]
        ],
        "view": "timeSeries",
        "annotations": {"horizontal": [{"label": "SLO 1%", "value": 1, "color": "#d62728"}]}
      }
    }
  ]
}

Step 2 エラー検知アラーム設定（10分）

エラー発生数が 1回以上（5分間） で通知
（※初心者はまず「エラーが出たら即通知」から始めるのが確実です）

aws cloudwatch put-metric-alarm \
  --alarm-name "Lambda-Error-Count-High" \
  --alarm-description "Lambda関数でエラーが発生しました" \
  --metric-name Errors \
  --namespace AWS/Lambda \
  --statistic Sum \
  --period 300 \
  --threshold 0 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --dimensions Name=FunctionName,Value=my-function \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:alerts

Step 3: 構造化ログ導入（15分）

関数コードに最小限のロギング追加:

🟢 Node.js 版

// 最小構造化ログ
exports.handler = async (event, context) => {
  const log = (level, message, extra = {}) => {
    console.log(JSON.stringify({
      level,
      message,
      requestId: context.awsRequestId,
      timestamp: new Date().toISOString(),
      ...extra
    }));
  };

  log('INFO', 'Function started');
  try {
    const result = await processEvent(event);
    log('INFO', 'Function succeeded', { resultSize: result.length });
    return result;
  } catch (error) {
    log('ERROR', 'Function failed', { error: error.message });
    throw error;
  }
};

🐍 Python 版

import json
import logging
from datetime import datetime

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def structured_log(level: str, message: str, context, **extra):
    log_entry = {
        "level": level,
        "message": message,
        "requestId": context.aws_request_id,
        "timestamp": datetime.utcnow().isoformat() + "Z",
        **extra
    }
    print(json.dumps(log_entry))

def handler(event, context):
    structured_log("INFO", "Function started", context)
    try:
        result = process_event(event)
        structured_log("INFO", "Function succeeded", context, resultSize=len(result))
        return result
    except Exception as e:
        structured_log("ERROR", "Function failed", context, error=str(e))
        raise

🎯 これで完了！おつかれさまでした🎉

この3ステップで 「エラー検知」「レイテンシ監視」「ログ追跡」 ができるようになりました！

次のステップ:

• コールドスタート監視 → 「3.1 Lambda Insights」
• コスト最適化 → 「3.4 コスト最適化」
• 分散トレース → 「3.2 トレース戦略」

---

4. よくあるミスや注意点💡

📝 監視導入チェックリスト

導入時に以下を確認してみてください👀

• 基本メトリクス: Invocations / Errors / Duration / Throttles / ConcurrentExecutions をダッシュボード化
• エラー率アラーム: 母数条件付き（Invocations ≥ 100）で設定
• 構造化ログ: requestId / level / timestamp を含む JSON 形式
• 相関 ID: X-Correlation-Id ヘッダ伝播設計
• ログ保持期間: コストと調査必要性のバランス（30日推奨）
• SLO 定義: 可用性 / レイテンシの目標値を明文化
• DLQ 設定: 非同期呼び出しの失敗イベント捕捉
• コストアラート: Budgets or Anomaly Detection 設定

🔄 トラブルシューティングフロー

アラームが鳴ったら、このフローで落ち着いて対応しましょう！

よくあるミス一覧

ミス／問題	背景	対策
呼び出し少でエラー率過大評価	母数が極小	Invocations 最低閾（例 ≥100/5分）+ ErrorRate の AND 条件
相関不能ログ	requestId/相関 ID 欠如	全関数でミドルウェア化・外部 API へヘッダ伝播
コールドスタート見逃し	平均 Duration に埋没	REPORT 行 Init Duration 抽出 + p95/p99 + ColdStartCount 監視
メモリ過多/過少	過多=無駄コスト / 過少=遅延	MaxMemoryUsed 比較 → Power Tuning 実施
キュー遅延放置	IteratorAge/Queue Age 非監視	Age / Backlog / DLQ Failures にアラート

4.1 初動 Runbook（抜粋）

シナリオ	初期確認	深掘り	主要指標	Esc 条件例
エラー急増	ErrorRate アラーム	直近デプロイ差分 / 例外 TopN	Errors / ErrorRate% / Invocations	>1% 10分継続 (初回試行) AND Invocations ≥100/5分 or 可用性 SLO 逸脱予兆
レイテンシ悪化	Duration p95/p99 上昇	X-Ray 外部依存 / ColdStartCount / Retries	p95/p99 / Throttles	p95 SLO 超過 5分
スロットル	Throttles	同時実行上限 / 他関数競合	Throttles / ConcurrentExec / PC Util	3 期連続発生 (Invocations ≥100/5分)
キュー遅延	Queue / IteratorAge 増	消費速度 / Visibility Timeout	ApproxAgeOfOldestMessage / IteratorAge	閾値超 10分
コスト急増	Anomaly Alert	リクエスト種別比率 / Duration 退行	Cost / GB-秒 / Invocations	予算逸脱予兆 >10% (SLO 影響なし確認)

🚨 実際の障害事例と対応

実際に運用している際に、遭遇する可能性が高い障害パターンとその対応例をご紹介します。
コールドスタートによるレイテンシ悪化は、構築当初の頃に私も苦しめられたことがあります😅

事例1：デプロイ直後のエラー率急増

タイムライン:
14:00 デプロイ完了
14:02 ErrorRate アラーム発報 (1% → 15%)
14:03 Slack 通知受信
14:05 Logs Insights でエラー内容確認
       → "Cannot read property 'items' of undefined"
14:08 直前コミットで API レスポンス形式変更を発見
14:12 ロールバック完了
14:15 ErrorRate 正常化確認

影響時間: 15分（監視未整備なら2時間以上）

教訓: デプロイ直後の ErrorRate 急増は自動ロールバック対象として設定

事例2：コールドスタートによるレイテンシ悪化

状況:
モーニングのトラフィック急増時間帯に p95 Duration が 800ms → 3000ms に悪化

調査:
1. Lambda Insights で Init Duration 確認 → 2200ms
2. 夜間の低トラフィックでインスタンスがスケールインしていた
3. 朝の急増で大量のコールドスタートが発生

対策:
- Provisioned Concurrency をピーク前にスケジュール設定
- SnapStart（Java/Python/\.NET対応）または初期化軽量化を実施

事例3：外部API障害の影響

状況:
Duration が全体的に悪化、Timeout エラーが急増

調査:
1. X-Ray トレースで外部 API 呼び出し区間を確認 → 平均 5000ms
2. 外部サービスのステータスページで障害発生を確認
3. Lambda 側では正常だが、外部依存がボトルネック

対策:
- 外部 API のタイムアウト設定を適切に（5秒→2秒）
- フォールバック処理（キャッシュ返却/エラー時デフォルト値）を実装

教訓: 外部依存の監視と適切なタイムアウト・フォールバック設計が重要

❓ よくある困り事など（FAQ）

よくある困り事を私の主観によりまとめてみましたので、ご確認ください。

Q1: CloudWatch とサードパーティツール（Datadog等）どちらが良い？

結論: まず CloudWatch で始め、必要に応じて拡張

観点	CloudWatch	Datadog/New Relic等
コスト	従量課金（低トラフィックなら安価）	ホスト数/ログ量課金
統合性	AWSネイティブで即使用	設定必要だが高機能
UI/UX	機能的	直感的で高機能
マルチクラウド	AWSのみ	複数クラウド統合可

推奨パス:

• 小規模/単一クラウド → CloudWatch + Lambda Insights
• 大規模/マルチクラウド → サードパーティ検討

Q2: アラームが多すぎて無視されることが多い。どうすれば？

アラーム疲れ（Alert Fatigue）対策

1. 母数条件追加: Invocations ≥ 100 でフィルタ
2. 連続評価期間: 1回でなく 2-3 期間連続で発報
3. 動的しきい値: 固定値でなく Anomaly Detection 使用
4. 重要度分類: Critical / Warning / Info で通知先分岐
5. 統合: 類似アラームは Composite Alarms で集約

Q3: ログ保持期間はどのくらいが適切？

推奨設定:

環境	保持期間	理由
本番	30日	月次分析+調査用
ステージング	7日	デバッグ用最小限
開発	1日	コスト最小化
監査対象	1年以上	S3へエクスポート+Athena

コスト最適化: 重要ログのみ長期保持、詳細ログは短期で削除

Q4: 監視コストが高くなってきた。どう抑える？

コスト削減テクニック:

1. ログサンプリング: 正常リクエストは 10-20% のみ記録
2. ログレベル調整: 本番は INFO 以上のみ
3. メトリクス解像度: 1分でなく 5分で十分なケースが多い
4. 保持期間短縮: 90日 → 30日 ※十分に検討が必要
5. Logs Insights クエリ最適化: スキャン範囲を絞る

---

5. まとめ

今回のポイント！

この記事でお伝えしたかったポイントを改めてまとめます📝

• 監視は単一メトリクスではなく、トラフィック／品質／パフォーマンス／コスト／遅延伝播 を束ねる設計が大事です。
• 構造化ログ + 相関 ID + 分散トレース を導入すると、根本原因の特定がグッと早くなるのでオススメです！
• Metric Math で 「意味のある率」+ 母数閾値条件 を組むと、アラームノイズが激減します。
• コスト最適化は 「メモリ調整→実行時間短縮→ウォーム戦略→継続的レビュー」 の反復がポイント。ただし、メモリ削減でコスト低下しても p95 レイテンシ SLO が悪化する場合は SLO 優先です（コスト／性能トレードオフを明確にしましょう）。

📋 キーメトリクス早見表

いつでも参照できるようにまとめました！

カテゴリ	メトリクス	統計	アラーム目安
トラフィック	Invocations	Sum	前週比 +50%
品質	Errors / Invocations	-	> 1%
レイテンシ	Duration	p95	> SLO (800ms等)
キャパシティ	ConcurrentExecutions	Max	> 上限の80%
スロットル	Throttles	Sum	> 0
コールドスタート	Init Duration	p95	> 1000ms
キュー遅延	IteratorAge / ApproxAge	p90	> 要件毎に設定

今後の展望

さらに深く学びたい方は、こんなテーマもおすすめです😊

• 深化: プロファイリング (init / CPU / I/O 待ち) と統合視覚化
• 予測的運用: トラフィック予測 + 需要前ウォーム + エラー予兆モデル
• 標準化: OpenTelemetry ベースで将来他クラウド統合容易化
• ガバナンス: Runbook / SLO / コストレポートの自動生成パイプライン化

🚀 まずはここから始める

「どこから始めればいい？」という方は、この表を参考にしてみてください。無理のないペースで進めていきましょう🌱

時間	アクション	成果
30分	3.6 クイックスタート実施	基本監視+アラート稼働
1時間	Lambda Insights 有効化 + ダッシュボード拡充	コールドスタート可視化
半日	構造化ログ + 相関 ID 導入	障害時の追跡性向上
1日	X-Ray / ADOT 導入	外部依存ボトルネック特定
1週間	Power Tuning 実施 + SLO 定義	コスト最適化 + 品質基準確立

まずは「3.6 クイックスタート」から始めてみてください！

---

6. 出典

2023-2025 年の主要情報源:

1. AWS Lambda: Types of metrics for Lambda functions — AWS Documentation (AWS ドキュメント)
2. AWS Lambda Monitoring with CloudWatch, X-Ray, and … — Lumigo article (Lumigo)
3. Essential Guide to AWS Lambda Monitoring – Best Practices — SigNoz ［Oct 2024］ (signoz.io)
4. Serverless Monitoring Best Practices — CloudNativeNow, Neel Shah，Aug 2025 (Cloud Native Now)
5. AWS Lambda monitoring-metrics types — AWS Documentation (AWS ドキュメント)
6. AWS Lambda Power Tuning — GitHub (PowerTuning)
7. AWS Lambda SnapStart — AWS Documentation (SnapStart)
8. AWS Cost Anomaly Detection — AWS Documentation (Anomaly)
9. AWS Budgets — AWS Documentation (Budgets)
10. AWS Distro for OpenTelemetry — AWS Documentation (ADOT)
11. Amazon API Gateway metrics — AWS Documentation (APIGW)
12. Amazon SQS metrics — AWS Documentation (SQS)
13. AWS Step Functions metrics — AWS Documentation (SFN)
14. AWS Incident Manager — AWS Documentation (IncidentManager)

---