Serverless and AI on AWS in 2026: Lambda Gets Hands, S3 Gets Memory

Classic serverless rested on three assumptions: your code is stateless, short-lived, and trusted. A Lambda function kept no state between invocations, ran for at most fifteen minutes, and executed code you wrote and reviewed yourself. AI agents break all three. An agent holds a running session, it thinks and waits for minutes or hours, and it increasingly runs code it generated on the fly. Between re:Invent 2025 and mid-2026, AWS rebuilt the serverless stack around those new requirements.

This is the first of two posts touring what changed, service by service. Every one of them fixes a broken assumption or answers a concrete question you face as an architect. Here we cover compute and knowledge: how Lambda became the hands of an agent, and how S3 became its memory. Part two covers governance, the frameworks, and the strange new economy of agents paying to read your content.

Compute: Lambda Becomes the Hands of AI

Lambda MicroVMs: where does AI-generated code run safely?

The old isolation trilemma forced you to pick two of three: strong isolation, fast startup, or state retention. Lambda MicroVMs, launched June 2026, give you all three by exposing Firecracker directly as a serverless primitive.

Each session gets VM-level isolation with no shared kernel. Launch and resume are near-instant because they come from a pre-initialized snapshot. State survives up to 8 hours, and when a session goes idle you suspend it: compute charges stop while the snapshot storage remains. The workflow is familiar if you already build containers. You bundle a Dockerfile plus a zip artifact in S3, AWS turns that into a MicroVM Image (a pre-initialized Firecracker snapshot), and you launch instances on demand and talk to them over HTTPS. HTTP/2, gRPC, and WebSockets all work, so a long-lived server inside the VM is fine. The constraints today: ARM64 only, up to 16 vCPUs, 32 GB memory, and 32 GB disk, in us-east-1, us-east-2, us-west-2, eu-west-1, and ap-northeast-1.

The killer use case is sandboxing AI-generated code. If an agent runs the code it just wrote inside its own runtime, that code can reach the agent’s credentials and memory. A MicroVM gives every session a hardware-isolated boundary instead. AWS ships integration guidance for Claude-managed agents and a skill for the Agent Toolkit, so this is a paved path, not a research project.

Now the part most recap posts skip. This isolation is not cheap. A minimum setup of 1 vCPU and 2 GB runs roughly $3 per day just to exist, about 9x the cost of Fargate Spot. The premium buys you the isolation plus stateful suspend and resume. Whether it pays off depends entirely on your idle-to-active ratio, so model that before you commit. If your sessions are mostly idle and you diligently suspend them, the math looks very different than if you keep hundreds warm.

If you already build container image Lambda functions, the packaging story here will feel familiar. Here is how the compute options line up:

Option	Model	Isolation	State	Best for
Lambda Functions	event-driven request/response	shared-tenant	none between invokes	short tasks, APIs, glue
Lambda MicroVMs	stateful isolated session	VM-level (Firecracker)	up to 8h, suspend/resume	sandboxing untrusted or AI code, interactive sessions
AgentCore Runtime	opinionated agent hosting	isolated session	up to 8h, no suspend/resume	packaged agents on AWS
Fargate or DIY Firecracker	long-running container	task or VM level	you manage it	custom control, non-agent workloads

Lambda Durable Functions: how do workflows survive hours instead of fifteen minutes?

The fifteen-minute ceiling was the other wall agents kept hitting. Lambda Durable Functions removes it. You write a multi-step, long-running workflow in your preferred language (Python and TypeScript are GA, the Java SDK is in preview) with built-in checkpointing and error recovery. The model is checkpoint-replay: each completed step is persisted, so a crash resumes from the last checkpoint rather than the start. You get branching, parallelism, timeouts, and the ability to wait for an external signal, all without standing up a separate orchestrator, and you pay only for active compute time.

This overlaps heavily with Step Functions, so the obvious question is which to pick.

	Lambda Durable Functions	Step Functions
Definition	code in Python or TypeScript (Java preview)	ASL state machine (JSON)
Ergonomics	your language, your tests, your versioning	visual console, express workflows
Integrations	you call the SDKs yourself	direct integrations with many AWS services
Audit trail	your logs and traces	visual execution history for non-engineers
Best when	logic-heavy flows, agent loops, teams that live in code	service-to-service glue, visual review needs

My recommendation: reach for Durable Functions when the workflow is mostly your own branching logic and you want to unit-test it in the same language as the rest of your code. Reach for Step Functions when the workflow is mostly gluing AWS services together, or when someone outside engineering needs to read the execution history in a console. The agentic loop of plan, act, wait, retry maps cleanly onto durable functions, which is why this primitive matters for AI work specifically.

Tenant Isolation Mode and the Lambda MCP Server: how do my existing functions become agent tools?

Two smaller additions round out the compute story. Tenant Isolation Mode gives you per-tenant isolation inside Lambda without running separate stacks per tenant. That fills the middle of an isolation spectrum: standard functions, then tenant isolation, then full MicroVMs. You pick the boundary that fits your threat model instead of paying for the strongest one everywhere. I build multi-tenant Atlassian Marketplace apps, and being able to raise the isolation boundary for one sensitive tenant without operating a second deployment is genuinely useful.

The Lambda MCP Server is the other one. It turns existing Lambda functions into tools that any MCP-capable agent (Claude, Kiro, Cursor) can call. The point is that you do not rebuild anything. Your existing serverless estate becomes agent-ready in place.

Knowledge: S3 Becomes the Memory of AI

The most important AI database of 2026 is, oddly, S3.

S3 Vectors: where do my embeddings live without a vector-database tax?

S3 Vectors is now GA: up to 2 billion vectors per index, around 100ms query latency, and up to 90% cheaper than a specialized vector database. There is no cluster to keep warm, so you get the usual S3 economics of paying for what you use. For serverless work this quietly removes a recurring bill. RAG side projects and mid-size production workloads no longer need to carry an OpenSearch Serverless minimum-capacity charge just to store embeddings.

It is not a universal replacement. If you need strict low latency, complex metadata filtering, or hybrid search that blends keyword and vector scoring, you still want OpenSearch or pgvector. S3 Vectors is the right default for storage-bound workloads where 100ms is fine and the query shape is simple.

S3 Annotations: how does an agent understand the data it finds?

S3 Annotations let you attach up to 1 GB of rich, mutable, queryable context directly to an S3 object. This is purpose-built for agents and autonomous workflows. Compare it to the old workarounds: the 2 KB object-metadata limit, sidecar JSON files that drift out of sync, or an external DynamoDB table indexing what each object is. With Annotations, an agent that finds a file can ask the file what it is, and update that answer as it learns more.

Bedrock Managed Knowledge Base: how do I get RAG without running a pipeline?

Announced at AWS Summit New York in June 2026, the Bedrock Managed Knowledge Base is fully managed enterprise RAG with native data connectors, Smart Parsing for multi-format ingestion, and an Agentic Retriever that handles complex multi-step queries. It integrates with AgentCore Gateway.

To see what it actually removes, look at the DIY path. This walkthrough on building related posts with a Bedrock Knowledge Base and S3 Vectors shows the real work: manual knowledge base setup, chunking-strategy decisions, sync monitoring, and iterative quality tuning until retrieval stops returning junk. The Managed Knowledge Base automates exactly that operational friction. Notably, the metadata-filtering pattern in that post, where object metadata narrows the retrieval set, is precisely the pattern S3 Annotations upgrades from a 2 KB constraint into a first-class queryable surface.

The honest caveat: managed convenience costs you control. You give up direct say over the chunking strategy, the embedding model choice, and some cost transparency. If retrieval quality is your product, you may still want the DIY path where you can tune every knob.

AWS Context: how does an agent know how my organization hangs together?

AWS Context, also from Summit NY 2026, is a new knowledge-graph service. The distinction from Knowledge Bases is worth holding onto. A Knowledge Base answers “what do my documents say?” Context answers “how do these entities relate, where do I find what, and what is the right next step?” It is new, public detail is still thin, and real-world experience is scarce, so I will not pretend to know more than that. One to watch. I will do a proper deep dive once I have tested it.

Where this leaves us

By mid-2026 the two oldest serverless assumptions, stateless and short-lived, have been answered directly. MicroVMs and Durable Functions give agents hands that can hold state and work for hours. S3 Vectors, Annotations, and the managed Knowledge Base give them a memory that does not require a warm cluster. The third assumption, trusted code, is really a governance problem, and that is where part two picks up: keeping agents under control in production, the frameworks you actually write them in, and the edge turning into a cash register for the agent economy.