Lambda durable functions can now export their step-by-step execution history to thirteen destinations, with an MCP server so an AI agent can query it in natural language. It is a genuinely useful observability addition, and the sentence to read twice is the one listing what gets exported.
“The new Telemetry Exporter sends data such as execution status, operation timing, step input and output, and errors to 13 built-in destinations.”
Executive summary
“AWS Lambda announces the Durable Execution Telemetry Exporter plugin for Lambda durable functions. This new observability plugin captures the step-by-step history of your durable executions and sends them to one or more destinations of your choice.”
Durable functions are long-lived by design — they “can execute for up to one year” — which is exactly why their history is worth exporting, and exactly why what travels with it matters.
What changed
Three things arrived together. The exporter itself, with “13 built-in destinations” including “Amazon CloudWatch Logs, Amazon S3 for Amazon Athena, Amazon DynamoDB, Amazon Aurora, and Amazon OpenSearch Service”. Two controls: “You can redact sensitive fields before export and set a sampling rate to control data volume.” And a query layer: “a companion Model Context Protocol (MCP) server that lets AI agents such as Kiro query your exported telemetry data using natural language.”
Available for “TypeScript, Python, Java, and Go”, and “at no additional charge in all AWS Regions that support Lambda durable functions”.
Architecture
A durable execution is a sequence of checkpointed operations: “which uses checkpoints to track progress and automatically recover from failures through replay, re-executing from the beginning while skipping completed work”. The building blocks are two kinds: “steps execute business logic with built-in retries and progress tracking, while waits suspend execution without incurring compute charges”.
So the history the exporter captures is the record of what each step received and produced. For an order workflow that is the order; for a loan approval it is the application.
The controls are described as things you can do
“You can redact sensitive fields before export and set a sampling rate to control data volume.”
The announcement does not say what either does when you leave it alone, and I have not been able to verify the defaults — the exporter's own reference lives in the Durable Execution SDK guide, which is a client-rendered site I could not read. So treat the defaults as unknown rather than assuming either direction, and settle the question before enabling the exporter anywhere holding regulated data. The useful framing is that redaction is a configuration step with an owner, not a property of the feature.
The second MCP example describes the data precisely
“an on-call engineer can ask an AI agent to list recent failed executions and find the cause of a failure, and a business analyst can find all transactions for a specific customer.”
The first example is observability. The second is a customer data lookup, and it is only possible because customer-identifying data is in the exported history. AWS is being straightforward about what this contains — that example is the clearest statement in the announcement of what the exporter actually carries.
Business value
Two real wins. Retention: “keep history beyond the standard retention period”, which matters for workflows that can run a year and may need to be explained later. And analysis: once the history is in Athena, DynamoDB or OpenSearch it is queryable with the tools you already have, rather than through whatever the service's own console offers.
The MCP server is the part that will get demonstrated in meetings, and the genuine value in it is the on-call case — asking why an execution failed without first learning a query language.
Security considerations
This is the section that matters for this announcement, and none of it is a criticism of the feature.
The export changes where your payload lives. Step input and output leaving the execution into S3 or OpenSearch means that data inherits the access model of the destination, not of Lambda. A bucket policy now governs what a step received.
The MCP server is a new access surface. Natural-language querying of step input and output is a different thing from reading a log file — it lowers the effort of asking a broad question about customer data to a sentence. Who can reach that agent is worth deciding deliberately rather than inheriting from whoever already had console access.
Redaction is per-field and therefore needs a list. Somebody has to know which fields are sensitive, which is a data-classification exercise rather than a configuration one.
Cost considerations
“at no additional charge” covers the exporter. The destinations bill normally: CloudWatch Logs ingestion, S3 storage, DynamoDB writes, Aurora capacity and OpenSearch nodes are all charged the way they always are.
The thing to size against is steps, not executions. A workflow with many steps running for months produces a row per step, and that is what the sampling rate exists to control.
Operational considerations
Installation is three steps: “install the exporter, register the plugin in your function handler, then add the MCP server to your agent” — and the third is separable. You can export telemetry without standing up the MCP server at all, which is the sensible first move if the agent access question is unsettled.
Note also that it is a plugin registered in your handler, so enabling it is a code change and a deployment rather than a console setting. That is good for review and means it rolls out at your deployment cadence.
Tradeoffs
| Choice | What you gain | What it costs |
|---|---|---|
| Enabling the exporter | History beyond the standard retention, queryable in familiar tools | Step input and output now live in a second place with its own access model |
| Adding the MCP server | On-call can ask why something failed in plain language | A new access surface over the same payload data |
| Sampling below 100 percent | Volume and destination cost under control | The execution you most want to inspect may not have been sampled |
| Aggressive redaction | Less sensitive data in the destination | Less context for the failure you are trying to understand |
Implementation guidance
- Decide the redaction list before the first export, not after. It is a data-classification question and it needs the people who know which fields are regulated.
- Choose the destination as a data-classification decision. The exported history inherits that destination's access model, so pick the one whose controls you would be comfortable defending for the payload.
- Export first, add the MCP server later. The two are separable and the agent access question deserves its own conversation.
- Size against steps. The unit of exported data is the step, not the execution, and a year-long workflow has a lot of them.
- Verify the redaction and sampling defaults in the SDK guide before enabling it anywhere sensitive. The announcement describes both as optional and does not state what happens if you configure neither.
Best practices
- Treat the exported history as a copy of the payload, and govern it like one.
- Keep the redaction list in the same review process as the schema it redacts.
- Decide who may query the MCP server explicitly, rather than letting it follow existing console access.
- Revisit the sampling rate after an incident where the execution you wanted was not captured.
Who should adopt this and when
Now, for durable workflows you already struggle to explain after the fact. Long-running executions are exactly the case where retention beyond the default earns its keep.
After a redaction review, for anything carrying regulated data. The capability is fine; the question is which fields travel.
The MCP server separately, once you have decided who should be able to ask questions of that data in natural language.
Key takeaways
- Exports step-by-step durable execution history to 13 built-in destinations, free, in all Regions that support durable functions.
- What is exported includes “step input and output” — the payload, not just metadata about it.
- Redaction and sampling are both described as things you can configure; the defaults are not stated in the announcement.
- The MCP server lets an agent answer “find all transactions for a specific customer”, which tells you what the data contains.
- The exporter is free; the destinations bill normally, and the unit is the step.
Official AWS references
- AWS Lambda durable functions now exports live telemetry for execution insights — the exporter and what it captures, the 13 destinations and the named examples, redaction and sampling, the MCP server and its two use cases, the four languages, the three installation steps, and pricing and Region availability (10 claims)
- Lambda durable functions — the one-year execution ceiling, checkpoints and replay semantics, and the distinction between steps and waits including the compute-charge behaviour of waits (4 claims)
- Durable Execution SDK — Telemetry Exporter reference; this is where the redaction and sampling defaults are documented. It is a client-rendered site that I could not read with the tooling used for this post, so no claims here are drawn from it
Comments