あるサーバーレスアーキテクチャで、本番 Lambda 関数に断続的なタイムアウトエラーが発生しています。一部の実行でメモリ使用量が急増していることが疑われますが、標準の CloudWatch Lambda メトリクスでは関数レベルの集計値しか確認できず、個々の呼び出しの詳細情報が不足しています。また、処理したレコード数やエラー種別ごとのカウントなどのカスタムビジネスメトリクスも発行したいですが、PutMetricData API 呼び出しを最小限に抑えたい要件があります。これらの要件を満たす組み合わせとして最も適切な 2 つを選択してください。
正解： Lambda Insights を有効化して、呼び出し単位のメモリ使用量・CPU 使用率・初期化時間などの詳細なパフォーマンスメトリクスを収集する。Embedded Metrics Format（EMF）を使用してカスタムメトリクスを CloudWatch Logs に埋め込み、PutMetricData 呼び出しを排除する。 Lambda Insights は Lambda Extension として動作し、呼び出しごとのメモリ使用量・コールドスタート時間・CPU 使用率などの詳細メトリクスを EMF 形式で収集します。EMF（Embedded Metrics Format）はカスタムメトリクスを構造化ログとして出力し、CloudWatch が自動的にメトリクスに変換するため PutMetricData API 呼び出しが不要です。 選択肢Bの Lambda のデッドレターキュー（DLQ）はタイムアウト時の再処理に使用するもので詳細な原因分析には不適切です。 選択肢Dの X-Ray トレーシングにはメモリプロファイリング機能はありません。 選択肢ECloudWatch Logs Insights クエリはスケジュール実行可能ですが、これはメトリクス収集ではなく事後分析であり、ハイパフォーマンス要件には対応できません。