Forwarder Lambda throttled: set reserved concurrency, check subscription filters

Forwarder Lambda throttled or falling behind

What you see: CloudWatch logs stop appearing in Datadog during traffic spikes, then arrive in a burst hours later, or never. The forwarder Lambda shows throttles in CloudWatch metrics.

Why

• No reserved concurrency. The forwarder defaults to unreserved account concurrency, so a burst of log deliveries competes with every other Lambda in the account and gets throttled. The docs recommend at least 10 reserved.
• Subscription filter fan-in. Each log group can only feed so many destinations; if the group already has a subscription (another SIEM, another forwarder), adding Datadog fails or silently wins/loses.
• Oversized batches. Enormous log lines or a flood of tiny events can hit Lambda payload/time limits; the forwarder retries, falls behind, retries.
• Old forwarder version. The docs describe migrating triggers between versions for a reason; ancient forwarders have known throughput bugs.

Fix

1. Set reserved concurrency on the forwarder (10 minimum per the docs, more for big accounts).
2. Check each log group has exactly one Datadog subscription filter and it points at the current forwarder.
3. Upgrade the forwarder to the latest release; migrate a few triggers first as the docs suggest, verify flow, then move the rest.
4. If a single log group is a firehose, consider sampling or routing it through the extension/direct intake instead of the forwarder.

Confirm

Watch the forwarder Lambda concurrent executions and throttle metrics during the next burst, and Live Tail for the log group. Steady flow with no throttles means you are done.

The forwarder docs recommend reserved concurrency for the forwarder Lambda (at least 10, defaults to 0 unreserved) and warn unreserved concurrency can starve other functions; they also document migrating CloudWatch log group subscription filters between forwarder versions. Verified against live docs 2026-09-26.