AWS Lambda Extensions: Flush Telemetry After Response

The Problem: Telemetry Flushing Slows Lambda Responses

Lead Bank has discovered a powerful pattern for reducing AWS Lambda response times on critical payment endpoints — using Lambda Extensions to defer telemetry flushing until after the response is sent. The approach addresses a common pain point for teams running observability pipelines inside serverless functions.

Lead Bank runs its entire API infrastructure on AWS Lambda behind API Gateway. These functions power mission-critical financial operations, and every millisecond of latency matters.

Why Telemetry Flush Latency Matters in Fintech

The bank's Lambda functions handle endpoints for wire transfers, checks, ACH payments, balance inquiries, account creation, and card management. Because these APIs are user-facing and operationally critical, response time is a non-negotiable metric.

For incident response and debugging, Lead Bank relies heavily on observability. Their stack uses the AWS Distro for OpenTelemetry (ADOT) layer, which runs a local OpenTelemetry Collector inside each Lambda invocation. The flow works like this:

• Application code sends telemetry spans and metrics to the local ADOT collector
• The collector forwards data to Honeycomb for querying and analysis
• The flush operation — waiting for the collector to ship data — adds latency to the response

This architecture choice was deliberate. Lead Bank chose ADOT over Lambda Powertools or native CloudWatch for 3 key reasons:

• Vendor neutrality through OpenTelemetry-standard instrumentation
• Flexible signal routing to best-of-breed backends like Honeycomb
• Rich query capabilities that CloudWatch alone cannot match

The Core Issue: Flush Happens Before Response Returns

In a typical Lambda execution, the telemetry flush must complete before the function returns its response to the caller. This means the user waits not only for business logic to execute but also for the observability pipeline to finish shipping data to an external sink.

The problem is not unique to ADOT. Any telemetry export mechanism — whether it uses a sidecar collector, an HTTP-based exporter, or a third-party agent — faces the same flush delay penalty. If you are using Lambda Powertools with a custom exporter or even a direct CloudWatch PUT, the same principle applies.

The Solution: Lambda Extensions for Post-Response Processing

Lambda Extensions provide a lifecycle hook that continues executing after the main function handler returns its response. This is the key insight Lead Bank leverages.

Instead of flushing telemetry synchronously during the invocation phase, the extension takes over and completes the flush in the post-invoke phase. The user gets their response immediately, and the telemetry ships afterward — within the same Lambda execution environment but outside the critical response path.

The practical benefits include:

• Lower perceived latency on every API call
• No data loss — telemetry still ships reliably before the environment freezes
• No infrastructure changes — the pattern works within the existing Lambda execution model
• Collector-agnostic — works with ADOT, custom OTel collectors, or any async flush mechanism

Implementation Considerations

Lambda Extensions run as separate processes in the execution environment. They receive lifecycle events from the Lambda Runtime API, including INVOKE and SHUTDOWN signals. The post-invoke window gives extensions time to complete background tasks like flushing buffers.

Teams adopting this pattern should be aware of a few caveats. The extension must handle the case where the execution environment is frozen between invocations — any in-flight flush needs to be resumable. Additionally, the SHUTDOWN phase has a limited timeout (up to 2 seconds by default), so final flushes at environment teardown must be fast.

Key Takeaway for Serverless Teams

This pattern is broadly applicable beyond fintech. Any team running OpenTelemetry or similar observability tooling inside Lambda functions can benefit from deferring flush operations to the post-response phase via Extensions.

The approach cleanly separates 'what the user waits for' from 'what the system needs to do.' For organizations where API latency directly impacts revenue or user experience, this architectural pattern is worth evaluating immediately.