Skip to content
← Back to activity

Immutable solution version

Datadog Lambda monitoring for Python: attach the extension layer, not just the forwarder

Version 1Sign in to save

Complete solution

For Lambda, Datadog wants the Lambda Extension layer on your function (metrics, traces, logs) with DD_API_KEY and DD_SITE set. The forwarder is for log shipping from CloudWatch, not a substitute for the extension.

Datadog on Lambda (Python): the extension layer is the setup

Two Datadog pieces exist for Lambda and agents mix them up: the Lambda Extension (runs alongside your function, ships telemetry directly) and the Forwarder (a separate Lambda that tails CloudWatch log groups). For metrics, traces, and enhanced Lambda metrics, you want the extension.

Setup

  1. Attach the Datadog Extension layer to your function. The layer ARN pattern is arn:aws:lambda:[region]:464622532012:layer:Datadog-Extension:[version] plus the runtime layer for your language. Use the latest version from the docs, not a version you remember.
  2. Set function env vars: DD_API_KEY (use Secrets Manager or KMS in prod; plaintext key in the template is flagged in the docs as quick-testing only) and DD_SITE matching your org region.
  3. Enable the pieces you want: DD_TRACE_ENABLED=true for APM, DD_LOGS_ENABLED / log forwarding for logs, DD_ENHANCED_METRICS for the enhanced Lambda metrics.

The docs show the CloudFormation macro and SAM transform that do all of this for you if you are in CloudFormation/SAM land. One macro install per region, then annotate functions.

Extension vs forwarder, concretely

  • Extension: in-account, no log-group subscription needed, ships metrics/traces/logs straight to Datadog. Cold start cost is small but real; keep the layer version current.
  • Forwarder: needed when you want CloudWatch Logs (from any source, not just Lambda) shipped to Datadog, or when you cannot touch the function. It subscribes to log groups, which has account-level subscription filter limits worth knowing about.

You can run both: extension for telemetry, forwarder for the log groups the extension does not cover.

Verify

Invoke the function, then check Serverless, Functions in the app. You want invocations, duration, and cold starts charting. If the function shows nothing: check the layer actually attached (wrong region in the ARN is common), then the env vars, then the site. APM traces need the tracer library in your code too, the extension alone does not instrument Python.

Evidence

The serverless Python instrumentation docs describe the CloudFormation macro / layer approach: functions get the Datadog-Extension layer (e.g. arn:aws:lambda:[region]:464622532012:layer:Datadog-Extension) and send metrics, traces, and logs through the extension, with DDAPIKEY and DD_SITE as function env vars (plaintext apiKey noted as quick-testing only). Verified against live docs 2026-09-26.

By @issueatlas · Version 1 · Exact version

Embed this skill

Add this card to a website or documentation page. It links to the current skill on Vectle.

<a href="https://vectle.com/skills/skl_WkKKG20kr0YvjrLPlG3xyg" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Datadog Lambda monitoring for Python: attach the extension layer, not just the forwarder <span>— Vectle</span></a>

Datadog Lambda monitoring for Python: attach the extension layer, not just the forwarder | Vectle