What Is the Difference Between Lambda Enhanced Monitoring and CloudWatch?

CloudWatch is the default monitoring layer for Lambda – it collects invocation metrics automatically, at no extra charge, from the moment your function is first invoked. Lambda Enhanced Monitoring (CloudWatch Lambda Insights) is an optional add-on that runs as a Lambda extension and captures a second layer of data: system-level metrics like actual memory consumption, CPU time, disk I/O, and network I/O per invocation. The two work together, not in place of each other.

The distinction that matters in practice: CloudWatch tells you what your function did. Lambda Insights tells you what it consumed while doing it.

What Standard CloudWatch Gives You (Free, Always On)

Lambda publishes these metrics to the AWS/Lambda namespace automatically, in 1-minute intervals, with no setup required:

These metrics answer the operational question: Is my function working, and is it keeping up?

What they don’t answer: Why a function is slow. Whether it’s using 90% of its allocated memory. Whether it’s CPU-bound or waiting on I/O. Whether cold starts are lasting 800ms or 80ms. For those questions, you need Lambda Insights.

What Lambda Insights Adds (Opt-In, Per-Invocation Cost)

Lambda Insights runs as a Lambda layer – a lightweight extension that executes after your handler returns and writes a single structured log event per invocation to /aws/lambda-insights/. CloudWatch parses those events into metrics in the LambdaInsights namespace.

The additional metrics you get:

These metrics answer the resource question: is my function sized correctly, and where is time going?

The practical value of memory_utilization: Lambda allocates CPU proportionally to memory. If your function consistently uses 30% of its allocated memory, you’re likely over-provisioned – and paying for CPU you’re not using. If it’s regularly hitting 85-90%, the next spike will cause an OOM kill. Neither scenario is visible in standard CloudWatch.

How Lambda Insights Works Under the Hood

Lambda Insights is implemented as a Lambda layer. When you enable it, AWS attaches the LambdaInsightsExtension layer to your function. After each invocation, the extension:

1. Collects CPU, memory, disk, and network data from the execution environment
2. Writes a single structured log event in Embedded Metric Format (EMF) to /aws/lambda-insights/
3. CloudWatch processes the EMF logs and surfaces them as time-series metrics

This is why Lambda Insights adds 10-20ms of overhead per invocation – the data collection and write happen synchronously after your handler exits, before the execution environment freezes.

How to Enable Lambda Insights

AWS Console: Lambda function → Configuration → Monitoring and operations tools → Edit → Enable Enhanced monitoring

AWS CLI:

# Step 1: Attach the layer (replace region and version as needed)

aws lambda update-function-configuration \

  --function-name your-function-name \

  --layers arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:49

aws lambda update-function-configuration \

  --function-name your-function-name \

  --layers arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:49

# Step 2: Attach the required IAM policy to your function’s execution role

aws iam attach-role-policy \

  --role-name your-function-execution-role \

  --policy-arn arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy

aws iam attach-role-policy \

  --role-name your-function-execution-role \

  --policy-arn arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy

Terraform:

resource "aws_lambda_function" "example" {

  # ... your existing config

  layers = ["arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:49"]

}

resource "aws_iam_role_policy_attachment" "insights" {

  role       = aws_iam_role.lambda_exec.name

  policy_arn = "arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy"

}

resource "aws_lambda_function" "example" {

  # ... your existing config

  layers = ["arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:49"]

}

resource "aws_iam_role_policy_attachment" "insights" {

  role       = aws_iam_role.lambda_exec.name

  policy_arn = "arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy"

}

Find the current layer ARN for your region in the Lambda Insights documentation.

Cost Comparison

At 100 million monthly invocations, Lambda Insights adds roughly $20 in metric costs plus ~100GB of additional log data. Under CloudWatch’s 2025 tiered pricing starting at $0.50/GB, that’s approximately $50 in additional log ingestion – around $70/month total for the Insights layer alone, on top of your standard CloudWatch spend.

The practical implication: Enable Lambda Insights selectively on your most critical or resource-intensive functions, not uniformly across your entire Lambda fleet. For functions you rarely investigate, standard CloudWatch is sufficient.

Side-by-Side: Which Questions Each Tool Answers

The Gap Neither Fills

Both standard CloudWatch and Lambda Insights are function-scoped. They tell you what happened inside a Lambda invocation – not what happened across the request chain that triggered it.

If a Lambda function took 3 seconds, CloudWatch tells you the duration. Lambda Insights tells you memory and CPU during those 3 seconds. Neither tells you that 2.6 of those seconds were spent waiting on a slow DynamoDB query – or that this Lambda was invoked by another Lambda that was itself responding to an API Gateway request.

That gap – the one between “my function was slow” and “here’s exactly why, and here’s the full request chain” – is where distributed tracing lives. It’s also the gap that neither CloudWatch nor Lambda Insights was designed to fill.

CubeAPM connects these dots. It instruments Lambda via the OpenTelemetry layer – the same layer you may already have for metrics – and gives you the full request trace: from the upstream trigger, through your function’s execution, to every downstream service it called. When a function shows high duration in CloudWatch and high memory in Lambda Insights but no obvious cause, the trace in CubeAPM is usually where the answer is. Self-hosted in your own AWS account, no data leaves your environment.

Summary

Start with standard CloudWatch. Add Lambda Insights to functions where you need to answer resource questions – memory sizing, CPU utilization, or cold start duration tracking – rather than enabling it everywhere by default.

Disclaimer: Configurations, thresholds, and code examples are for guidance only. Verify against the current AWS and OpenTelemetry documentation before applying to production. AWS service details change frequently. CubeAPM references reflect genuine use cases; evaluate all tools against your own requirements.