あるチームがCloudWatchのカスタムメトリクスを大量のLambda関数から送信している。一部のLambda呼び出しで「ThrottlingException: Rate exceeded」というエラーがPutMetricData呼び出し時に発生している。コスト増加を抑えつつこの問題を解決する最も適切な方法はどれか。

正解: A

PutMetricData APIにはリクエストレート制限があり（リージョンごとに1,000リクエスト/秒）、大量のLambda関数から並行して呼ばれるとスロットリングが発生する。EMF（Embedded Metrics Format）に切り替えると（選択肢A）、PutMetricData API呼び出しをまったく行わずにCloudWatch Logsへのログ書き込みだけでカスタムメトリクスを送信できる。CloudWatch Logsのスループット制限はPutMetricDataよりも大幅に高く、スロットリングが解消される。またログはLambdaの実行環境から直接CloudWatch Logsに送られるためAPI呼び出しコストも発生しない。選択肢Bのメモリ増加はPutMetricDataのレート制限とは無関係。選択肢Cの非同期化はLambdaのメインロジックは保護されるがThrottlingException自体は発生し続け、メトリクスが欠損する。選択肢DのSQS集約はコストと複雑性が増え、集約Lambda関数も同様にPutMetricDataのレート制限に当たる可能性がある。EMFはPutMetricDataのスロットリング問題の根本解決策。