Serverless Monitoring
Monitoring that watches execution environments with no resident host, such as AWS Lambda, using function invocations as the unit. The Lambda Extension sends metrics, traces, and logs from inside the function, and Cloud Run and Azure apps are viewed in the same frame.
What it does
Targets AWS Lambda, Step Functions, Azure App Service, Azure Container Apps, and Google Cloud Run, collecting metrics, traces, and logs from functions and containers and laying them out on a single screen. For Lambda, the Lambda Extension runs in the same execution environment as the function and emits enhanced metrics such as cold starts at second granularity.
When to use it
Use it to get out of the state of "we have 200 functions, but we cannot tell which ones are slow and which ones are timing out." Typical uses are following a single request that flows from API Gateway through a queue, a function, and a data store as one trace, setting an alert on the number of cold starts, and comparing performance before and after a deployment.
An everyday analogy
It is attendance management not for salaried resident staff (hosts) but for temporary staff who only come when called (functions). The monitoring cost is also counted as "the average number of people who actually showed up for work in that hour," so even if the roster lists 200 people, if only 30 worked, you pay for 30.
Bottom line - in a world without hosts, the unit is "the hourly average of functions that ran"
The unit of monitoring is usually the host. AWS Lambda has no such premise; execution environments appear and vanish with every invocation. So Datadog records, for every hour, "the number of functions that were invoked at least once and were being monitored," and at month end uses the hourly average of that number as the billable function count (as of September 2026, source: Serverless Billing). Functions are counted uniquely by ARN, and Lambda@Edge is a separate function per region. Billing is a monthly price per active function as Workload Monitoring for AWS Lambda, and the unit price differs between annual commitment and on-demand (source: Datadog Pricing). Even if the list has 200 functions, if only 30 run on an hourly average, you pay for 30. That way of counting is the biggest difference from the world of hosts. This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.
Extension and Forwarder, two routes that carry different things
There are two routes for sending from Lambda to Datadog. One is the Datadog Lambda Extension, which runs in the same execution environment as the function and sends custom metrics, traces, and logs asynchronously while the function runs. Logs are taken directly from the Lambda Telemetry API, so they do not pass through CloudWatch (as of September 2026, source: Serverless Monitoring for AWS Lambda). The other is the Datadog Forwarder, which extracts telemetry from logs and sends it. The official documentation positions the Extension as the recommended route. However, the Forwarder is still needed to collect logs from other AWS services such as API Gateway, AppSync, and Lambda@Edge, so the two share the work (source: Deciding to migrate to the Datadog Lambda extension).
| Aspect | Lambda Extension | Forwarder |
|---|---|---|
| Where it runs | Inside the same Lambda execution environment as the function | A separately deployed Lambda function |
| What it carries | The function's custom metrics, enhanced metrics, traces, and logs | Telemetry extracted from logs, plus logs from other AWS services such as API Gateway, AppSync, and Lambda@Edge |
| Passes through CloudWatch Logs | No (sends directly from the Telemetry API) | Yes (CloudWatch Logs and Forwarder function costs are added) |
| When a new function is added | Add the Lambda layer | Configure a subscription filter for each log group |
| Official positioning | Recommended route for collecting function telemetry | Required for collecting logs from other AWS services |
One invocation becomes one traced invocation - how enhanced metrics and APM are counted
Through the Extension, enhanced metrics with the aws.lambda.enhanced prefix arrive at second granularity, and you can set alerts and SLOs on cold starts, estimated AWS cost, timeouts, out-of-memory conditions, and memory usage (as of September 2026, source: Serverless). Tracing is supported by the Python, Node.js, Ruby, Go, Java, and .NET SDKs, and a single request flowing from API Gateway through a function to a data store can be followed as one trace. Billing is the monthly total of Lambda invocations tied to APM ingested spans, and no billable APM hosts arise. The unit price is a monthly price per unit of 1 million traced invocations, where 1 invocation = 1 top-level span (source: Datadog Pricing). Indexed span overages and the differences with Fargate are left to the APM pricing explainer and APM.
Does adding the Extension slow down the function?
There are costs too. One is that cold start initialization time increases slightly because the extension's initialization is added. The other is that the execution time reported by aws.lambda.duration and similar metrics appears to increase. The added portion is the time the Extension spends sending to Datadog, and because it happens after AWS has returned the response to the caller, the function's response does not get slower (as of September 2026, source: Datadog Lambda Extension). If you do not know this, you misread the duration graph rising right after adoption as a performance regression and roll back. By default, sending happens at the end of every invocation, but when the Extension detects a frequency exceeding once per minute, it batches multiple invocations and sends periodically. In regions far from the Datadog site the increase is larger, so you can widen the flush interval to 1 minute with the environment variable DD_SERVERLESS_FLUSH_STRATEGY=periodically,60000 to keep it down.
Can you answer immediately whether it broke right after a deployment?
The first thing you want to know in a serverless incident investigation is "was the most recent deployment the cause?" Deployment Tracking correlates code, configuration, and deployment changes with the function's metrics, traces, and logs, so you can follow how a change affected health and performance (as of September 2026, source: Serverless). When the time the function version went up and the error-rate line appear on the same screen, the decision to "roll back or wait" becomes a comparison rather than a guess. As add-on capabilities, there are Continuous Profiler, which pinpoints the lines that are bottlenecks inside a Lambda function, and App and API Protection, which handles threats to functions (source: Serverless Monitoring for AWS Lambda). Datadog's approach is to start not from a single function but from "the stack that contains that function," and to view the indicators of managed services such as queues, streams, and data stores on the same screen.
How Step Functions, Fargate, and Cloud Run are counted
The targets Datadog lists for serverless monitoring are AWS Lambda, Azure App Service, Azure Container Apps, and Google Cloud Run, and AWS Step Functions is handled on the same screen (as of September 2026, source: Serverless). For Step Functions, execution traces are generated from logs, and you can follow the state machine's execution path, the inputs and outputs of each step, and the time taken. Enhanced metrics are generated on the Datadog side with the aws.states.enhanced prefix. For Cloud Run and Azure Container Apps, in addition to the cloud integration, embedding the serverless Agent in the app lets you collect traces, custom metrics, and logs directly. For application monitoring of Fargate and similar, the billing unit is the average number of active app instances measured at 5-minute intervals.
| Target | Counting unit | Contract forms | Main caveats |
|---|---|---|---|
| Workload Monitoring for AWS Lambda | Active function (hourly average of invoked functions) | Annual commitment / on-demand (annual is lower) | The hourly average of functions that ran, not the number in the list |
| Functions APM for AWS Lambda | 1 million traced invocations (1 invocation = 1 top-level span) | Annual commitment / on-demand | No APM hosts arise |
| Application Monitoring for AWS Fargate and others | Active app instance (average at 5-minute intervals) | Annual commitment / on-demand | Changes in task count feed straight into the average |
| Application APM for AWS Fargate and others | Traced active instance | Annual commitment / on-demand | Only instances with tracing enabled are counted |
Checking the counting rules on a setup where 30 of 200 functions run
Let us set assumptions. There are 200 functions, of which 30 on an hourly average run at least once per hour, and there are 5 million invocations per month, all of them traced. The Workload Monitoring charge is "the number of functions that ran on an hourly average × the per-function price," so the billable count is 30, not 200. The Functions APM charge is "units of 1 million traced invocations × the price per unit," so 5 million invocations are 5 units. If we let the per-function price be p and the price per 1 million invocations be q, the monthly total is 30p + 5q, and in a setup where all 200 functions run every hour, the Workload side alone would be 200p, that is, close to 6.7 times the 30-function case (the unit prices differ between annual commitment and on-demand; source: Datadog Pricing). The way to read this SKU is not to count functions but to estimate along two axes, "the number of functions that ran on an hourly average" and "the number of invocations," and batch functions that stop at night do not inflate the denominator. Indexed span overages and the allowance of 5 custom metrics per billable function included with Pro / Enterprise (source: Serverless Billing) are checked separately. The overall pricing is covered in the pricing guide.
- Assumptions: 200 functions / 30 functions running on an hourly average / 5 million invocations per month (all traced)
- Workload Monitoring: functions that ran on an hourly average × per-function price = 30p (not 200)
- Functions APM: number of 1-million-invocation units × price per unit = 5q
- Total: 30p + 5q (p and q differ between annual commitment and on-demand)
- Comparison: if all 200 functions run every hour, the Workload side alone is 200p
The dividing line is whether invocations or function count grows
What matters in the decision is which axis your setup grows along. In a setup where traffic concentrates on a small number of functions, the Workload Monitoring side is determined by function count, so even a tenfold increase in invocations does not change it, and only the Functions APM side, counted in units of 1 million invocations, grows. Conversely, in a setup that splits functions finely, the hourly average of functions that ran goes straight onto the Workload side. What helps in the latter case is narrowing the monitoring scope. In the AWS integration's Metric Collection, you can limit the Lambda functions to monitor with tags in key:value form, and tags prefixed with ! take precedence as exclusions (as of September 2026, source: Serverless Billing). However, functions instrumented with the Extension or a library are billable even if the AWS integration is disabled, so narrowing is done on both the integration-side tags and the instrumentation. Integrations are covered in Integrations, and the point that the volume of function logs is billed separately is covered in the Log Management explainer.
Things to watch out for
- This article is based on the official documentation as of September 2026. Supported runtimes and collection routes can change, so when adopting, give priority to the installation steps in the official documentation.
- This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.
- Functions instrumented with the Lambda Extension or a library are counted as billable active functions even when the AWS integration is disabled (as of September 2026). When narrowing the monitoring scope, check both the integration-side tag filter and whether instrumentation is present.