AWS Lambda Ate the Durable Execution Market. Here's What Inngest Still Does Better.

The durable execution category exploded in 2025. Cloudflare shipped Workflows GA. Vercel launched its Workflow DevKit. Temporal raised at a $5 billion valuation. And then, at re:Invent 2025, AWS did what AWS always does: it absorbed the entire category into its own platform. Lambda Durable Functions brought checkpoint-and-replay workflows natively into the Lambda programming model, no Step Functions, no external state stores, no third-party orchestrators required.

That single announcement fundamentally changed the competitive landscape for platforms like Inngest. The question is no longer whether you need durable execution. The question is whether you need a separate platform for it.

I spent the past few weeks digging into both architectures at the systems level, comparing execution models, pricing at scale, AI agent orchestration patterns, and the developer experience gap that still exists between the two. What follows is my analysis of where each platform wins, where they converge, and what I think most teams should actually choose.

Key Takeaways

• Lambda Durable Functions (re:Invent 2025) brought checkpoint-and-replay directly into the Lambda runtime, eliminating the need for Step Functions or external orchestrators for most workflow patterns, with async invocations spanning up to one year at zero compute cost during waits.
• Inngest retains a genuine edge in three areas: declarative per-tenant flow control primitives (concurrency, throttling, rate limiting, debouncing, prioritization), cross-platform deployment portability, and local development experience via its Dev Server with visual execution traces.
• Cost depends on actual step operations, retries, compute duration, stored state, hosting and plan terms. A step count alone is not a like-for-like monthly cost comparison.
• For multi-agent AI orchestration, the Lambda ecosystem (Durable Functions + Step Functions + Bedrock Agents/AgentCore) covers more production concerns than Inngest's AgentKit, but AgentKit's code-first DX is better for prototyping.
• The hybrid approach (Inngest orchestrating on top of Lambda compute) deserves serious consideration for teams that want Inngest's flow control without leaving the AWS ecosystem.

---

At a Glance

---

Two Execution Models, One Convergent Idea

Lambda's classic model is conceptually simple. A request arrives, Lambda provisions an execution environment (a Firecracker microVM), runs your handler, and tears it down. State exists nowhere between invocations. Every function call is born fresh. The execution environment may be reused (warm starts), but the platform makes no guarantee. Your code must treat each invocation as independent. The 15-minute hard timeout cannot be increased. Memory ranges from 128 MB to 10 GB, with CPU allocated proportionally up to 6 vCPUs.

Lambda Durable Functions change the programming model. You write multi-step workflows as regular Lambda code with steps, waits, and conditional logic. The runtime automatically checkpoints state after each step, persists it to a managed backend, and resumes execution from the last checkpoint on retry or after a wait. Async invocations can span up to one year, and there are no compute charges during wait periods. This is not a wrapper around Step Functions. It is a native Lambda capability.

Cold starts remain a reality for classic Lambda. Their latency depends on the runtime, package, initialisation work, networking and configuration. Without a reproducible workload, a single p95 number is not a useful comparison with an orchestration service. Provisioned concurrency and supported SnapStart configurations address different parts of that problem.

Inngest takes a different architectural path. When an event arrives at Inngest's Event API, it flows through an internal event stream to the Runner, which schedules function runs and manages lifecycle. The Executor then invokes your function via HTTP (in serve mode) or WebSocket (in the newer connect mode, shipped June 2025). Inngest uses a step-based memoization model: a completed step.run() result is persisted, and on subsequent invocations the SDK skips completed steps by injecting their stored results. Your function code looks like normal TypeScript or Python. No custom runtime, no modified execution environment, no proprietary DSL.

This means an Inngest function can "run" for months. A step.sleep("wait-30-days", "30d") suspends the function at zero compute cost. A step.waitForEvent("approval", { event: "user/approved", timeout: "7d" }) pauses until a matching event arrives or the timeout elapses.

Here is the key difference. Lambda Durable Functions achieve similar durability but within the AWS-managed runtime, with automatic infrastructure management, deeper service integrations, and the full weight of AWS's operational maturity behind them. Inngest achieves durability through an application-layer SDK that rides on top of your existing compute, whether that is Lambda, Vercel, Cloudflare Workers, or a container.

In its December 10, 2025 checkpointing announcement, Inngest reported a 50% reduction in its own workflow-duration measurements. That is a vendor-reported result, not a universal speedup. This addresses the primary performance criticism of memoization-based systems: the overhead of replaying completed steps on each invocation. Lambda Durable Functions also use checkpoint and replay; neither design makes all orchestration or replay overhead disappear.

---

Background Jobs: Lambda Ecosystem vs. Inngest Primitives

Building a reliable background job system on classic Lambda requires assembling multiple AWS services. The canonical pattern is Lambda + SQS: messages land in a queue, an event source mapping triggers Lambda, and you configure visibility timeouts (at least 6x your function timeout), dead-letter queues with maxReceiveCount redrive policies, and partial batch failure reporting via ReportBatchItemFailures. Add EventBridge for scheduled jobs, SNS for fan-out, and DynamoDB for idempotency tracking.

Lambda Durable Functions dramatically simplify this. A multi-step background job that previously required Lambda + SQS + DynamoDB + EventBridge can now be a single Durable Function with steps and waits. State persists automatically. Retries happen per-step with configurable policies. Wait periods for human approval, external webhooks, or scheduled delays incur zero compute cost. The pricing is $8 per million durable operations, $0.25 per GB written, and $0.15 per GB-month retained. That is often cheaper than the combined cost of SQS + DynamoDB + EventBridge for the same workflow.

Inngest collapses background jobs into a similar single programming model:

export default inngest.createFunction(
  { id: "process-upload", retries: 4 },
  { event: "file/uploaded" },
  async ({ event, step }) => {
    const parsed = await step.run("parse", () => parseCSV(event.data.url));
    const validated = await step.run("validate", () => validate(parsed));
    await step.sleep("rate-limit-pause", "2s");
    const result = await step.run("write-db", () => writeToDB(validated));
    await step.sendEvent("notify", { name: "pipeline/complete", data: result });
    return result;
  }
);

Each step.run() is independently retried on failure. If "write-db" throws, only that step retries. "parse" and "validate" do not re-execute because their results are memoized. Inngest provides a Replay feature for bulk re-running failed function runs after bug fixes, while external side effects still need idempotency protection. A request can succeed before its result is checkpointed, causing a retry to repeat it.

Where Inngest still differentiates: its flow control primitives (concurrency, throttling, rate limiting, debouncing, prioritization, singletons) are declarative and per-function with support for dynamic keys. Lambda Durable Functions do not yet ship equivalent flow control. You would still need API Gateway throttling or custom rate-limiting infrastructure for those patterns.

Where the Lambda ecosystem retains clear advantages: SQS FIFO supports ordered delivery within message groups and producer-side deduplication, but consumers must still handle retries and duplicate processing. AWS documents that distinction. Batch sizes, scaling controls and retry behaviour depend on the event source and queue type. The ecosystem of 200+ AWS service integrations means Lambda can react to events from virtually any AWS resource. For teams already invested in AWS, the familiarity, battle-tested reliability at massive scale, and operational maturity are not things to dismiss lightly.

---

Multi-Agent Orchestration: Three Tiers of Capability

Orchestrating multiple AI agents, routing between models, managing tool calls, handling human approval loops, maintaining conversation state. This is where the architectural differences create the most divergent developer experiences.

The Lambda ecosystem now offers three orchestration tiers for AI workflows:

Tier 1: Lambda Durable Functions provide code-first, durable multi-step workflows natively within Lambda. For AI agent pipelines, this means you can write agent routing logic, LLM calls, tool invocations, and human approval waits as regular code with automatic checkpointing. Wait periods for LLM responses, human approvals, or external webhooks incur zero compute cost. This is the simplest path for teams already on AWS who want durable execution without learning a new orchestration platform.

Tier 2: Step Functions provides more formal orchestration with Amazon States Language (ASL), a JSON-based DSL defining state machines. Standard Workflows support executions up to one year with exactly-once semantics. Step Functions can invoke Bedrock foundation models directly without Lambda intermediaries, and the March 26, 2026 announcement added 28 service integrations, including Bedrock AgentCore and S3 Vectors. The trade-off is the separation between orchestration logic (JSON state machines) and business logic (Lambda code), which adds cognitive overhead for complex agent interactions.

Tier 3: Bedrock Agents and AgentCore combine a foundation model with instructions, action groups (Lambda-backed tools), knowledge bases, and guardrails. The AgentCore runtime provides managed microVMs per agent session with async processing up to 8 hours. For teams building on AWS's AI stack, this is the most integrated path to production agent systems.

Inngest's AgentKit keeps orchestration and agent logic in the same codebase. This is a schematic illustration rather than a tested example for every SDK version:

const navigator = createAgent({
  name: "Navigator",
  system: "You search the web for relevant information...",
  tools: [searchWebTool],
});

const analyst = createAgent({
  name: "Analyst",
  model: anthropic("claude-3-5-sonnet"),
  system: "You analyze data and provide insights...",
});

const network = createNetwork({
  agents: [navigator, analyst],
  defaultModel: openai({ model: "gpt-4o" }),
});

export default inngest.createFunction(
  { id: "research-pipeline" },
  { event: "research/requested" },
  async ({ event, step }) => {
    const result = await network.run(event.data.query, ({ network }) => {
      return defaultRoutingAgent;
    });
    return result;
  }
);

AgentKit provides Agents (LLM calls + prompts + tools + MCP support), Networks (multi-agent collaboration with shared state), Routers (deterministic or LLM-based orchestration), and built-in tracing. The step.ai.infer() primitive offloads LLM inference to Inngest's infrastructure, meaning your serverless function does not execute or pay for compute while waiting for the model provider's response.

AgentKit's developer experience is strong for prototyping and small-to-mid scale agent systems. But the Lambda ecosystem's breadth matters at production scale. Bedrock's native guardrails, knowledge base integrations, and AgentCore's managed runtime provide production-grade infrastructure that AgentKit does not replicate. Teams building serious AI agent systems on AWS will find that Lambda Durable Functions + Bedrock Agents + Step Functions cover more production concerns (security, compliance, monitoring, scaling) than any single third-party SDK.

---

Local Development: This Is Where Inngest Wins

I want to be direct about this one. Inngest's local development experience is meaningfully better than Lambda's.

Lambda's local development story has improved but remains fragmented. SAM CLI provides sam local invoke and sam local start-api (requiring Docker), with step-through debugging support for VS Code and JetBrains. CDK projects require running cdk synth first to generate CloudFormation templates before SAM can use them. SST offers a Live Lambda Development feature that tunnels real cloud events to your local machine. Third-party tools like Lambda Live Debugger support remote debugging with real traffic across multiple functions simultaneously.

The pain points are real. Local emulators do not perfectly replicate cloud behavior, especially for service integrations like SQS, EventBridge, and DynamoDB. CloudWatch Logs scatter debugging information across log groups. Every code-deploy-test cycle involves waiting for CloudFormation updates. IAM permission management across multiple functions and services adds operational friction.

Inngest's local development experience is built around its Dev Server, started with npx inngest-cli@latest dev. It runs at localhost:8288 with auto-discovery of your serve endpoints, providing a full browser UI for managing functions, sending test events, and viewing execution traces. The dev server runs the same execution engine as Inngest Cloud, giving you production parity for local testing. In October 2025, the dev server gained a built-in Model Context Protocol server, giving AI coding assistants direct access to event management and function invocation.

Faster iteration cycles, visual execution traces, production-parity testing without Docker or CloudFormation. For teams that prioritize developer velocity above all else, this advantage is real and significant.

That said, the Lambda ecosystem's tooling gap is narrowing. SST's Live Lambda Dev, AWS's remote debugging, and the growing ecosystem of third-party tools are closing the distance. And the production observability story (CloudWatch + X-Ray + third-party integrations like Datadog) remains more mature and battle-tested than Inngest's built-in dashboard.

---

State Management: Two Models, Converging

Lambda's classic statelessness is both its greatest strength and its most persistent limitation. Each invocation runs in isolation. Maintaining state between invocations requires external stores: DynamoDB, ElastiCache, S3, EFS, or RDS with RDS Proxy.

Lambda Durable Functions manage workflow checkpoints. Step results are persisted to a managed backend, with configurable execution-history retention after completion. This removes the need to build the checkpoint store, while replay behaviour, idempotency and payload design remain application concerns. This is architecturally similar to Inngest's step memoization, but implemented at the runtime level rather than the application layer.

Step Functions pass state between steps as JSON with a 256 KB per-state output limit. Larger payloads must be stored in S3 with references passed through the state machine.

Inngest also persists step results. Check the applicable SDK and service limits before passing large payloads through a workflow; use external storage and references when appropriate. The original unsourced per-step, total-state and step-count figures do not establish a reliable capacity comparison.

For long-running workflows, both Lambda Durable Functions and Inngest now offer comparable durability. A workflow that needs to wait for payment confirmation, then shipping, then delivery feedback can be expressed as a single function with wait primitives in either platform. The Lambda version benefits from deeper integration with AWS services (DynamoDB Streams, S3 events, EventBridge). The Inngest version benefits from cross-platform portability.

---

Concurrency and Flow Control: Inngest's Strongest Card

Lambda combines account-level concurrency quotas with per-function controls. The quota documentation lists the standard account quota and separate scaling limits; new accounts can have lower starting quotas. Reserved concurrency carves out capacity for critical functions. Provisioned concurrency pre-initializes environments for zero cold starts. But Lambda provides no built-in mechanism for per-function throttling, per-tenant rate limiting, or priority queuing. Those patterns must be implemented with external services.

Inngest documents flow control primitives as first-class configuration: concurrency, throttling, rate limiting, debouncing, prioritization, and singleton enforcement. All are declarative and per-function with support for dynamic keys via CEL expressions that create virtual per-entity queues.

inngest.createFunction({
  id: "process-request",
  concurrency: { limit: 5, key: "event.data.tenant_id", scope: "fn" },
  throttle: { limit: 100, period: "1m", key: "event.data.tenant_id" },
}, ...);

This is the strongest differentiator Inngest holds over the Lambda ecosystem. Per-tenant concurrency, throttling, and priority queuing with a few lines of configuration versus custom infrastructure on Lambda. For multi-tenant SaaS applications with strict fairness requirements, Inngest's flow control is genuinely superior.

The relevant capacity depends on approved account quotas, the Inngest plan, tenant fairness requirements and the workload. Compare the concurrency of executing steps separately from the number of waiting workflow runs; they are different units. Load testing the intended workflow is more useful than comparing unrelated headline limits.

---

Pricing: Compare the Whole Workflow

Pricing below is a framework for comparing costs, not a current quote or a reconstructed April 2026 invoice. Start with the AWS Lambda pricing page and Inngest pricing, then use the same region, traffic pattern and retry assumptions for both.

For Lambda, count requests and resumed invocations, compute duration and memory, billable durable operations, written and retained state, and any supporting services. A workflow step is not automatically equivalent to one billable durable operation. As unit arithmetic, 2.5 million billable operations at an $8-per-million rate would cost $20 for that component alone. It says nothing about total workflow cost.

For Inngest, count billable execution units under the applicable plan, plus the hosting cost of the application code, retained traces and any additional features. Runs, steps and durable operations are different billing units. Free-tier eligibility and included allowances also need to be checked rather than assumed.

The original version's $175-versus-under-$100 comparison omitted enough workload assumptions that it was not reproducible. My architectural preference for an AWS-heavy stack does not establish that Lambda is cheaper for every workload. Benchmark a representative run, include retries and failures, and price its actual usage.

---

Portability and Lock-In

Lambda's vendor lock-in is real but nuanced. The function code itself is reasonably portable if you follow hexagonal architecture. The coupling comes from the ecosystem: SQS, DynamoDB, EventBridge, API Gateway, Step Functions ASL, IAM policies, and now Durable Functions' proprietary checkpoint mechanism. But this coupling comes with genuine benefits: deep service integrations, unified billing, consistent IAM model, and a single operational plane.

Inngest's cloud-agnostic design is a deliberate architectural choice. The same SDK code runs on Vercel, AWS Lambda, Cloudflare Workers, containers, or bare metal. Self-hosting is available as a single binary (inngest start) with bundled SQLite, or with Postgres and external Redis for production workloads. The server repository documents SSPL terms with an Apache 2.0 Future License; check the release and its applicable terms. Source-available, but not OSI-approved open source.

For teams with a multi-cloud strategy or those building products that must deploy into customer environments, Inngest's portability is a genuine advantage. For teams committed to AWS (which, given AWS's market share, is the majority of enterprise engineering organizations), Lambda's ecosystem integration is the stronger value proposition.

---

When to Reach for Each

Choose the Lambda ecosystem for most production workloads. Lambda provides the broadest language support, the deepest service integrations, the most mature operational tooling, and (with Durable Functions) native durable execution without third-party dependencies. The combination of Lambda Durable Functions for code-first workflows, Step Functions for formal orchestration, and Bedrock Agents for AI systems covers nearly every workflow pattern. Lambda's scaling characteristics are battle-tested at a level no startup platform can claim. For teams building on AWS, the ecosystem's maturity, reliability, and integrated billing make it the safer and more capable choice. Lambda Managed Instances (re:Invent 2025) further strengthen the cost story for predictable, high-volume workloads with EC2-based pricing and a 15% management fee.

Choose Inngest when you need its specific strengths: declarative per-tenant flow control primitives that do not exist in the Lambda ecosystem, cross-platform deployment portability for multi-cloud or edge-first architectures, or the fastest possible local development iteration cycle. Inngest's Dev Server and visual execution traces remain meaningfully better than Lambda's local tooling. AgentKit is a strong choice for teams prototyping multi-agent AI systems outside the AWS ecosystem. And for small teams on Vercel or Next.js who want durable workflows without learning AWS infrastructure, Inngest's onboarding experience is genuinely excellent.

Consider the hybrid approach. Inngest can serve functions directly from Lambda, giving you Lambda as the compute layer with Inngest providing orchestration and flow control on top. This is a pragmatic path for teams that want Inngest's developer experience and flow control primitives while retaining Lambda's scaling, networking, and ecosystem integration.

---

So What?

The launch of Lambda Durable Functions was a pivotal moment for this space. AWS did not just validate the durable execution model. It absorbed the core value proposition of platforms like Inngest and Temporal into its own compute primitive. The gap between Lambda and Inngest has narrowed dramatically. Where Inngest once offered durable execution as its primary differentiator, Lambda now provides the same capability with deeper infrastructure integration, broader language support, and the operational maturity of the world's largest cloud provider.

Inngest retains real advantages in developer experience, flow control primitives, and deployment portability. These matter. For certain teams and architectures, they are decisive. But for the majority of engineering teams building production systems in 2026, AWS Lambda with Durable Functions, Step Functions, and the Bedrock AI stack represents the more complete, more scalable, and more future-proof platform. Every re:Invent closes more gaps, and the trajectory strongly favors AWS closing the remaining developer experience delta.

The question for engineering teams is not which platform is technically superior in isolation. It is where your production workloads live, what your team already knows, and whether the operational benefits of a fully managed, deeply integrated platform outweigh the developer experience advantages of a purpose-built orchestration layer. For most teams, the answer is Lambda.

Source notes

This remains an April 2026 architectural opinion, with October editorial corrections. Capabilities, quotas and prices can change. The linked vendor documentation is authoritative for deployment decisions; a source link does not make the original cost comparison a measured benchmark.

• Lambda durable execution and idempotency: replay reuses completed results, but a failed or interrupted step may execute again.
• Inngest retries: make side effects idempotent across retry attempts.