Services or capabilities described in AWS documentation might vary by Region. To see the differences applicable to the AWS European Sovereign Cloud Region, see the AWS European Sovereign Cloud User Guide.

Using CloudWatch metrics with Lambda Web Functions

AWS Lambda publishes Web Function metrics to Amazon CloudWatch in two namespaces:

Lambda publishes request, usage, and throttling metrics only when a request produces a value for them. Execution environment metrics are different: Lambda publishes them every minute for each active execution environment. Some metrics are sparse: Lambda does not publish a data point of 0 for a period in which the event did not occur. For example, if no request returns a 5xx response in a period, HTTPResponseStatusClass5XX has no data point for that period. The following tables describe when Lambda emits each metric. When you create alarms on sparse metrics, configure how the alarm treats missing data. For more information, see Configuring how CloudWatch alarms treat missing data in the Amazon CloudWatch User Guide.

Request metrics

Request metrics are published in the AWS/Lambda/Web namespace with the FunctionName and EndpointName dimensions. They use the Count unit. Use the Sum statistic.

The status-class metrics count the status code that the caller received. They do not distinguish responses written by your application from responses returned by Lambda. If your application has already sent the response status and headers, a later failure, such as an interrupted stream or a request timeout, is counted under the original status code. To identify the source of an error, use the lambda-web-error-type response header and your logs. To count application errors separately, publish your own metrics. For more information, see Publishing custom metrics with the embedded metric format.

To estimate a server error rate, divide HTTPResponseStatusClass5XX by ExecutedRequests over the same period with CloudWatch metric math. For example, use FILL(m5xx, 0) / m_executed, where m5xx and m_executed are the IDs of the two metrics. Because HTTPResponseStatusClass5XX is sparse, use FILL so that periods without errors evaluate to 0 instead of having no value. HTTPResponseStatusClass5XX also counts 5xx responses that Lambda returned before a request reached an execution environment. ExecutedRequests does not count these responses, so the ratio can overstate the rate during a service disruption.

Request metrics in the home Region aggregate traffic from every Region that the endpoint serves, so one alarm in the home Region covers the whole endpoint. Build alarms and dashboards on the home Region values. Don't rely on these metrics in other Regions; see Telemetry in each Region.

Lambda emits request metrics when a request completes. For a long-running request, the data point can appear up to the request timeout after the request started, so errors from long requests can reach your alarms late. For the request timeout, see Request timeout.

Execution environment metrics

Execution environment metrics describe the resources that the execution environments serving your Web Function use. Lambda publishes them in the AWS/Lambda/Web namespace with the FunctionName dimension, and centralizes them into the Web Function's home Region.

Lambda emits these metrics once per minute for each active execution environment, so they could be sparse if there are no active execution environments. A value can be 0. An execution environment can publish more than one data point in a minute, for example when it initializes and when it shuts down, so don't use the SampleCount statistic to count active environments. To count them for an endpoint, use EndpointActiveEnvironments.

Execution environment metrics don't include the EndpointName dimension. They cover all endpoints of the Web Function.

Regional usage and throttling metrics

Usage and throttling metrics show how close your account and endpoints are to their Regional limits, and which limit throttled a request. The account request-rate quota and the account Arm64 vCPU quota apply separately in each AWS Region, so Lambda publishes these metrics in each Region and does not centralize them. To see usage for a Region, view the metrics in that Region. For the quotas, see Lambda Web Functions.

These metrics are published in the AWS/Lambda/Web/Usage namespace with the FunctionName, EndpointName, and ExecutionRegion dimensions. They use the Count unit.

Lambda attributes each throttled request to one limit, so a throttled request increments at most one throttle metric. Requests that Lambda throttles because too many execution environments are initializing at the same time return HTTP 429 with the Platform.EndpointConcurrentInitThrottle error type but do not increment any throttle metric. Throttled requests also count toward HTTPResponseStatusClass4XX in the AWS/Lambda/Web namespace.

To monitor a MultiRegion or PerRegion endpoint, view or alarm on usage metrics in each Region, or combine them in a CloudWatch cross-Region dashboard.

Using metrics with other CloudWatch features

Because AWS/Lambda/Web metrics are centralized into the home Region, you can use them with the standard CloudWatch features in that Region, including:

Setting an alarm on 5xx responses

Create CloudWatch alarms to detect issues such as elevated error rates or throttling.

The following command creates an alarm that triggers when callers receive more than five 5xx responses from the endpoint in a five-minute period.

aws cloudwatch put-metric-alarm \
    --alarm-name my-web-app-prod-5xx \
    --namespace AWS/Lambda/Web \
    --metric-name HTTPResponseStatusClass5XX \
    --statistic Sum \
    --period 300 \
    --threshold 5 \
    --comparison-operator GreaterThanThreshold \
    --evaluation-periods 1 \
    --treat-missing-data notBreaching \
    --dimensions Name=FunctionName,Value=my-web-app Name=EndpointName,Value=prod \
    --alarm-actions arn:aws:sns:us-east-1:111122223333:my-alerts

Replace the following values:

--treat-missing-data notBreaching is important here. HTTPResponseStatusClass5XX is a sparse metric, so periods with no 5xx responses produce no data points. Without this setting, the alarm would enter the INSUFFICIENT_DATA state during those periods.