AWS Lambda insights

Lambda extensions (monitoring, security tools) run alongside functions and share CPU, memory, and execution time. Extensions consuming significant resources increase function duration, memory usage, and costs—especially if extensions perform heavy initialization or processing.

Functions without provisioned concurrency experience cold starts during scale-up or after idle periods. The Init phase (environment setup, runtime bootstrap, function initialization) adds latency before invocation, degrading user experience especially for latency-sensitive applications.

ProvisionedConcurrencySpilloverInvocations shows requests exceeding pre-warmed capacity, causing unexpected cold starts and latency. This indicates provisioned concurrency is undersized for actual load patterns.

High init_time during cold starts adds significant latency to first invocations. Functions without provisioned concurrency or SnapStart experience unpredictable startup delays affecting user-facing requests.

PostRuntimeExtensionsDuration adds latency after function execution completes, increasing billed duration and costs. Extensions consuming significant time can impact function SLAs despite handler completing quickly.

Event Source Mapping Starvation

Lambda event source mappings for SQS show high FailedInvokeEventCount or DroppedEventCount, indicating Lambda cannot process messages due to throttling, errors, or configuration issues.

Event Source Mapping Metric Blind Spots Without Opt-In

Kinesis event source mappings for Lambda provide detailed metrics (PolledEventCount, FilteredOutEventCount, FailedInvokeEventCount, etc.) only when explicitly enabled via EventSourceMappingMetricsConfig, leaving operators blind to processing failures and filtering effectiveness by default.

High-Value Transaction Timeout Pattern

Enterprise transactions exceeding $10,000 experience significantly higher latency due to enhanced fraud detection, causing timeouts and abandoned purchases. Standard monitoring shows healthy services while high-value orders fail.

Events sent to Dead Letter Queues represent persistent failures that couldn't be processed after all retries. Rising DLQ errors signal systematic problems with function logic, downstream dependencies, or configuration that require immediate investigation to prevent data loss.

Hidden Throttling from Insufficient CloudWatch Visibility

Throttled requests may occur without obvious logging, especially when layers of abstraction hide SDK-level exceptions. Operators lack visibility into why requests fail despite adequate provisioned capacity.

Lambda Stream Processing Lag from DynamoDB Streams

DynamoDB Streams event source mapping to Lambda experiences high IteratorAge or failed invocations, causing delayed event processing and potential data inconsistency in downstream systems.

Lambda Poison Message Creates Duplicate Processing

Lambda processes Kinesis records in batches and checkpoints only on success. A single poison message that causes processing failure triggers retry of the entire batch, creating duplicates for successfully processed records before the failure point.

AsyncEventAge increases over time when Lambda retries asynchronous invocations due to throttling or function errors. This signals processing delays and potential SLA violations before events are dropped.

AsyncEventsDropped Without Corresponding Received Events

AsyncEventsDropped metric shows events being discarded, but AsyncEventsReceived is lower than expected. This indicates events never reached Lambda's internal queue due to upstream failures or network issues.