Datadog Lambda Extension
You set up the datadog lambda extension by adding its layer to your function. This small agent runs beside your code and sends logs, traces, and metrics out. Most teams attach a cloud role and pass an API key to start sending data. If that role has broad permissions, your function can read secrets it should not touch. A basic setup gets data flowing fast, but it also widens your security risk. How the datadog lambda extension works in AWS In the past, teams used a separate log forwarder funct
Lambda Execution Roles + Datadog Security Monitoring: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up the datadog lambda extension by adding its layer to your function. This small agent runs beside your code and sends logs, traces, and metrics out. Most teams attach a cloud role and pass an API key to start sending data. If that role has broad permissions, your function can read secrets it should not touch. A basic setup gets data flowing fast, but it also widens your security risk.
How the datadog lambda extension works in AWS
In the past, teams used a separate log forwarder function to move cloud logs. That old pattern needed extra cloud triggers, log groups, and storage steps to run. The datadog lambda extension changes this flow by running inside the same execution box. It acts as a local agent that shares life cycle events with your handler. When AWS spins up your function, it also starts the extension process right beside it.
Your app code writes custom metrics and trace spans to a local port. The extension listens on that local port, batches the data, and sends it out. It uses the AWS Extensions API and Telemetry API to collect platform logs direct. Because it flushes data in the background, your main function finishes its work faster. You do not pay for extra forwarder functions to read from cloud log storage.
To make this work, you configure two layers on your serverless function in AWS. One layer holds the language library that instruments your app code and database calls. The second layer holds the datadog lambda extension binary that forwards the collected data. You also set variables to tell the agent which site and key to use. For production workloads, teams store that key inside a secret manager instead of plain text.
What the native setup solves and what it misses
This native setup solves the cost and delay of old log forwarding pipelines. Teams get real-time traces and metrics without managing extra cloud queues or shipper functions. When you tie the API key to a secret store, the extension fetches it at startup. Your cloud role grants the function permission to read that specific secret and start running.
Still, cloud roles and secret rules only check who can start the function. Once the runtime starts, your code and third-party layers share the same role permissions. If a developer logs a full database row, personal data goes straight into your logs. A stolen key or a bad code change can also abuse those broad runtime permissions. Native IAM checks who logs in at startup, not what individual commands do in flight.
Lambda Execution Roles + Datadog Security Monitoring: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing sensitive data and runtime permissions
Serverless functions often talk to databases, internal APIs, and cloud storage during a run. When you debug an issue, traces and logs capture parts of those live requests. If a database query returns emails, phone numbers, or card numbers, traces might capture them. You can set scrubbing rules in the agent to rewrite matched fields in log results. Still, managing scrubbing rules across hundreds of tiny functions takes constant review from your team.
Engineers also need direct access to those same cloud databases and services to fix bugs. When teams share static database passwords across functions and developer laptops, audit trails break down. You can see that a query ran in a trace, but not who ran a manual fix. Keeping function roles tight and inspecting live database traffic closes this big operational gap.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Does the datadog lambda extension increase cold start times?
Yes, adding any layer adds a small delay during the initial function startup phase. The runtime must download the layer code and start the agent process before running handlers. Warm runs stay fast because the agent buffers and sends data in the background.
When should I use a log forwarder instead of the extension?
Most teams use the extension for standard functions because it reduces cloud log storage costs. You still need a separate forwarder for cloud services that cannot run layers, like API gateways. Some teams also pick the forwarder for tiny functions with very low memory limits.
How does the extension authenticate without plain text keys?
You can store your API key inside AWS Secrets Manager or Systems Manager Parameter Store. You then give your function role permission to read that single secret item at startup. The extension reads the secret once and keeps the key in memory for future sends.