Forwarder Lambda throttled: set reserved concurrency, check subscription filters

TL;DR

Set reserved concurrency on the forwarder (10 minimum per the docs, more for big accounts). Check each log group has exactly one Datadog subscription filter and it points at the current forwarder. Upgrade the forwarder to the latest release; migrate a few triggers first as the docs suggest, verify flow, then move the rest.

When to use

You are seeing this: What you see: CloudWatch logs stop appearing in Datadog during traffic spikes, then arrive in a burst hours later, or never. Use this skill when you run into "Forwarder Lambda throttled: set reserved concurrency, check subscription filters".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

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.