I have a Lambda that triggers 500 times per second. I want to track a custom business metric for "RevenuePerInvoke." Should I use the SDK inside the Lambda handler, or will the API latency slow down my execution time too much? Is there a more "serverless" way to do this?
3 answers
For high-volume Lambdas, you should strictly avoid using the PutMetricData SDK call inside your handler. It adds significant "cold start" overhead and network latency to every execution, which will increase your Lambda bill. Instead, use the CloudWatch Lambda Insights extension or simply use the AWS Lambda Powertools library to emit metrics using the Embedded Metric Format (EMF). Since EMF just writes to CloudWatch Logs (stdout), it has virtually zero impact on your function's performance. The metrics are then parsed asynchronously by the CloudWatch service in the background.
Does using EMF mean you lose the ability to use "High Resolution" metrics, or can the log-based ingestion still handle sub-minute data points?
Another benefit of EMF is that if the CloudWatch API is temporarily down or throttled, your logs still exist, so you won't lose your data points once the service recovers.
I agree with Michael. Resilience is just as important as cost. Using the logs as a buffer is a much safer architectural pattern for critical financial or operational data.
Steven, EMF actually supports high-resolution metrics perfectly fine. You just need to specify the "StorageResolution" property in your JSON structure. As long as your logs are being ingested, CloudWatch will treat the extracted data with the same resolution and retention rules as if you had pushed them via the standard API, just without the performance penalty.