AWS Builder Center

Builder Center

Monitoring AWS Lambda with CloudWatch: A Practical Guide to Logs, Errors, and Alarms

Learn how to monitor AWS Lambda functions using Amazon CloudWatch Logs, metrics, and alarms. This hands-on guide covers troubleshooting failed invocations, tracking errors, and building a basic monitoring workflow for serverless applications.

Monitoring AWS Lambda with CloudWatch: A Practical Guide to Logs, Errors, and Alarms

Introduction

Serverless computing removes much of the infrastructure management that comes with traditional application hosting. However, it does not remove the need to monitor applications.
An AWS Lambda function can fail because of incorrect input, missing permissions, unavailable dependencies, or an execution timeout. Without proper monitoring, these problems can remain unnoticed until users report them.
Amazon CloudWatch helps developers understand what their Lambda functions are doing by collecting logs, tracking metrics, and triggering alarms when something goes wrong.
In this tutorial, we will explore how to use CloudWatch to monitor a Lambda function and build a simple monitoring workflow.

1. Understanding the Architecture

The monitoring workflow involves three main components:
  • AWS Lambda: Executes application code in response to an event.
  • Amazon CloudWatch Logs: Stores log messages generated by the function.
  • Amazon CloudWatch Metrics and Alarms: Tracks performance indicators and notifies you when configured thresholds are breached.
When a Lambda function runs, its logs can be sent to CloudWatch Logs. CloudWatch metrics provide information such as invocation count, error count, duration, and throttling. Alarms can evaluate selected metrics and take configured actions.
This gives developers visibility into application behaviour without managing a separate monitoring server.

2. Create a Simple Lambda Function

For this demonstration, we will use Python to create a small function that logs an incoming event and returns a response.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
import json
import logging

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

def lambda_handler(event, context):
logger.info("Received event: %s", json.dumps(event))

try:
name = event.get("name", "AWS Builder")

response = {
"message": f"Hello, {name}!",
"request_id": context.aws_request_id
}

logger.info("Request processed successfully")
return response

except Exception:
logger.exception("Request processing failed")
raise
The function uses Python's logging module to record useful information. It also logs unexpected exceptions before re-raising them, allowing Lambda to record the invocation as a failure.
Avoid logging passwords, access tokens, personal information, or other sensitive data.

3. Configure CloudWatch Logging

Lambda sends logs to CloudWatch Logs when its execution role has the required permissions.
For a standard Lambda logging setup, the role needs appropriate CloudWatch Logs permissions, commonly provided by the AWS-managed AWSLambdaBasicExecutionRole policy.
Follow these steps:
  1. Open the AWS Lambda console.
  2. Select your function.
  3. Open the Configuration tab and select Permissions.
  4. Open the execution role in IAM.
  5. Verify that the role has the required logging permissions.
  6. Return to the function and invoke it using a test event.
For example, use this test event:
1
2
3
{
"name": "Cloud Developer"
}
After a successful invocation, open the function's Monitor tab and select the CloudWatch logs option.
Lambda commonly writes to a log group named:
/aws/lambda/your-function-name
Within the log group, log streams contain the function's output. You should be able to find the messages generated by the logger.
If logs are missing, check the execution role permissions, the selected AWS Region, and whether the function has been invoked.

4. Monitor the Most Important Metrics

CloudWatch provides several useful Lambda metrics.
MetricWhat it tells you
InvocationsHow often the function is called
ErrorsHow many invocations result in function errors
DurationHow long the function takes to execute
ThrottlesHow many invocation attempts are throttled
ConcurrentExecutionsThe number of function executions running concurrently
These metrics help identify different classes of problems.
For example, a sudden increase in Errors may indicate a bug or dependency failure. Increasing Duration may indicate inefficient processing or a slow downstream service. Throttles can point to concurrency limits or capacity constraints.
Not every error has the same cause, so metrics should be combined with logs and application context.

5. Create a CloudWatch Alarm for Lambda Errors

An alarm can help you detect problems before they affect too many users.
To create an error alarm:
  1. Open the CloudWatch console.
  2. Navigate to Alarms and choose Create alarm.
  3. Select the Lambda namespace and the Errors metric for your function.
  4. Configure a threshold appropriate for your workload.
  5. Choose an evaluation period and the number of periods that must breach the threshold.
  6. Configure an action, such as notifying an Amazon SNS topic.
  7. Name the alarm and create it.
For a small demonstration, you might configure an alarm to enter the ALARM state when the Errors metric is greater than or equal to one during a one-minute period.
This is only an example configuration. In a production environment, consider normal traffic, evaluation periods, expected failures, and the consequences of false alarms.
An alarm does not automatically fix a failed Lambda function. It evaluates a metric and performs the actions you configure.

6. Troubleshoot Common Problems

The function runs, but no logs appear

Check that the execution role has the required logging permissions. Confirm that you are looking at the correct Region and log group.

The function returns an error

Open the relevant log stream and look for the exception message and stack trace. Verify the event structure, environment variables, dependencies, and permissions.

The function is taking too long

Inspect the Duration metric and the function's timeout configuration. Investigate slow database queries, network requests, large payloads, and inefficient processing.

The function is being throttled

Review the Throttles metric, concurrency settings, account quotas, and incoming request patterns before deciding whether to adjust concurrency.

The alarm is not notifying anyone

Check the alarm state, configured alarm action, SNS topic permissions, and subscription confirmation status.

7. Monitoring Best Practices

A useful monitoring strategy goes beyond simply collecting logs.
  • Use structured log messages so that important fields can be searched consistently.
  • Set log retention periods instead of retaining every log indefinitely.
  • Create alarms for errors and other metrics that matter to your application.
  • Use CloudWatch dashboards to view important metrics together.
  • Avoid logging sensitive data.
  • Use least-privilege IAM permissions.
  • Test alarms and notification paths before relying on them in production.
  • Review monitoring costs, including log ingestion, storage, and metric usage.
For larger applications, consider adding custom metrics, distributed tracing with AWS X-Ray, and application-specific health indicators where appropriate.

8. Clean Up After Testing

Monitoring resources can continue generating charges even after an experiment ends.
After testing, review the resources you created. Delete demonstration alarms, dashboards, SNS topics, and subscriptions if you no longer need them. Review the Lambda function and its log group before deleting anything.
If the function is part of another project, keep the resources that project still requires.

Conclusion

Effective monitoring is an important part of building reliable serverless applications. AWS Lambda and Amazon CloudWatch work together to provide logs, metrics, and configurable alarms that help developers understand failures and performance issues.
By starting with basic logging, monitoring the right metrics, and configuring meaningful alarms, developers can build a stronger foundation for operating serverless applications.
The key lesson is simple: deploying a function is only one part of building an application. Understanding how it behaves after deployment is equally important.
Discussion: Which Lambda metric would you monitor first in a production application: Errors, Duration, or Throttles? What other signals would you add?
#aws-lambda #amazon-cloudwatch #serverless #monitoring #aws
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article