Improve serverless visibility by emitting structured logs with a correlation identifier, tracing requests across functions, tracking a few metrics per function, and giving each function its own narrow permissions. Security signals come from the same data: unexpected callers, unusual duration, and denied access calls.
What is different about monitoring functions?
You cannot log into a host. Functions start, run for milliseconds or minutes, and disappear. The platform collects logs and metrics for you, as AWS Lambda's monitoring documentation describes, with invocation counts, duration, errors and throttles available as standard metrics.
That is a start, not coverage. A request that touches a gateway, three functions, a queue and a database leaves fragments in five places. Without a shared identifier, you have five stories, not one.
What should every function log?
Write one structured line per meaningful event, as JSON, with fixed field names. Include the correlation identifier, function name and version, caller identity, outcome and duration. Never log secrets, tokens or full personal data.
Pass the identifier along every hop: in headers for HTTP calls, in message attributes for queues. A single search then returns the whole path of a request.
Set log retention deliberately. Default retention on some platforms is indefinite, which becomes a cost and a privacy problem. Keep long enough for investigation, and no longer than policy allows.
Which metrics and alerts matter?
Per function, watch these:
- Error rate and throttle count.
- Duration at the 50th and 99th percentile, as changes can mean abuse or a regression.
- Concurrent executions against your account limits.
- Cold start frequency, if latency matters.
- Cost per thousand invocations, since a sudden jump can signal abuse or a loop.
For security, add counts of access denied responses, invocations from unexpected sources, calls to unusual external addresses and changes to function configuration or permissions. These come from audit logs of the cloud account rather than the function itself.
What are the main security risks?
The OWASP Serverless Top 10 project maps the risk areas for these applications. In practice the recurring themes are injection through event data, because events come from many sources, not just HTTP; overly broad permissions; weak authentication on triggers; vulnerable dependencies bundled in packages; and insecure handling of secrets.
Event injection deserves attention because teams validate HTTP input yet trust queue messages and storage notifications. Treat every event as untrusted, whatever its source.
A constructed example
An image processing function is triggered when a file lands in a storage bucket. It reads the file name from the event and passes it to a shell command. A user uploads a file with a crafted name. The function has permission to read every bucket in the account, because it shares a role with other functions. Two problems stack: unvalidated event data and an oversized role.
The repair is plain. Validate the file name against an allow pattern, avoid shell calls in favour of a library, and give the function a role that can read one bucket prefix. An alert on access denied calls from that role would also reveal any attempt to wander.
How to check or apply this
- Choose a correlation identifier format and propagate it everywhere.
- Switch logs to structured JSON with agreed field names.
- Turn on distributed tracing across functions, queues and gateways.
- Alert on error rate, p99 duration, throttles and cost spikes.
- Give each function its own role with the narrowest permissions.
- Validate every event source, not only HTTP.
- Scan function dependencies and see which vulnerable packages your code reaches.
- Set log retention and redact sensitive fields.
Safeguard supports SBOM and dependency scanning with reachability analysis, which suits function packages where every bundled library is shipped with the code.
Quick check
Does the cloud provider secure my function code?
No. The provider secures the platform. You remain responsible for your code, dependencies, permissions and configuration.
What is the single most useful logging habit?
A correlation identifier passed through every call, so one search reconstructs an entire request.
Sources
- OWASP Serverless Top 10
- AWS Lambda: Monitoring and observability
- NIST SP 800-218: Secure Software Development Framework
Last reviewed: 18 October 2026.
