Deploying an Agent to AWS Lambda

We start from the FastAPI service we deployed to Railway in the previous workshop. We strip out FastAPI and swap it for a custom AWS Lambda runtime. The runtime handles both the static frontend and the streaming agent API. We deploy one container image as a Lambda Function URL with SSE streaming.

A coding agent (Codex) does most of the code-writing, and the exact prompts I used are quoted verbatim.

This was a freestyle session, so it also surfaces a fair amount of meta-discussion. We cover how to work with agents, when to trust them, and when to slow down and read the code.

Links

These materials are related:

• Previous workshop: end-to-end agent deployment

The shift versus the previous workshop

Here's where Lambda fits in the request path:

The agent loop, the search tool, the renderer abstraction, and the frontend are unchanged from the previous workshop.

What changes is the web layer and the deployment pipeline:

• FastAPI is gone. A custom Lambda runtime (backend/lambda_runtime.py) handles routing, static file serving, and SSE streaming directly against the Lambda Runtime API.
• The Dockerfile is rebased on public.ecr.aws/lambda/python:3.14 instead of python:3.14-slim.
• The ./deploy.sh script handles deployment. It builds a container image and pushes it to ECR. Then it deploys a CloudFormation stack that creates the Lambda function and a Function URL with RESPONSE_STREAM invoke mode.
• Railway and the GitHub Actions promotion workflow are gone.

Moving to Lambda changes what you pay for. With Railway or Render you pay for a server that has to be up all the time. With a Lambda Function URL you only pay per invocation, which fits tools and small agents that run occasionally.

Extra material

Additional pages outside the main flow:

• Appendix: isolating the AWS environment - how to spin up an isolated AWS sub-account, mint short-lived credentials, and ship them to the box that runs the agent. This step links to the reproducible scripts in aws-account/.