Deploying an agent for real doesn't mean managing servers — it means composing a few real, managed AWS services correctly.
1Three Real Layers, Each With One Job
API Gateway's job is being the stable, managed HTTP front door — validating requests, applying throttling, and integrating authentication before anything reaches your code. Lambda's job is running your actual agent logic on demand, scaling automatically with request volume, and only billing for real execution time. Bedrock's (or another provider's) job is the actual model reasoning your agent calls into. Each layer is replaceable and scalable independently of the others.
2Why Not Skip Straight to a Lambda Function URL
AWS does allow invoking a Lambda function directly via a Function URL, skipping API Gateway entirely — and for a truly minimal internal tool, that can be a reasonable simplification. But it means reimplementing request validation, rate limiting, and auth checks inside your handler code by hand, work API Gateway already provides as a managed feature in front of the function.
3Step-by-Step Breakdown
TriageAgent Leaves Your Browser. Everything so far has run as plain Python functions. Shipping TriageAgent for real means putting it behind a real serverless architecture: API Gateway accepts an HTTPS request, invokes a real Lambda function running your agent code, which can call Bedrock (or another model provider) to reason and your real tools to act — all without you managing a single server.
Why put API Gateway in front of the Lambda function instead of only relying on the function itself to handle incoming HTTP requests?
- →API Gateway provides a managed, stable HTTP interface with built-in request validation, throttling, and authentication/authorization integration in front of the function, rather than reimplementing all of that inside the handler itself.
- →A Lambda function is technically incapable of running unless it's invoked through API Gateway specifically.
The Handler Is the Real Entry Point. Every real request funnels into one function: the Lambda handler. It receives the raw event AWS hands it, has to parse out the actual ticket, run TriageAgent's real logic, and return a response shaped exactly the way API Gateway expects. Next lesson: writing that handler for real.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Return Structured Error Responses From the Gateway Layer
Configure API Gateway to return a consistent, parseable error shape (status code plus a JSON error body) for validation failures, so any client consuming the API — including assistive tooling — can handle failures predictably.
{ "statusCode": 400, "body": "{\"error\": \"missing ticket field\"}" }SEO Implications
- 1
Target 'deploy AI agent on AWS Lambda' and 'API Gateway Lambda Bedrock architecture' separately
Developers deploying their first agent search for the general deployment question and the specific service composition independently.
Best Practices
Keep the Lambda Function Stateless Between Invocations
TASKS and similar in-memory state from earlier lessons cannot safely live inside a Lambda function across invocations — a real deployment needs a real external store (like DynamoDB) for anything that must persist.
Frequent Bugs
Assuming a Lambda function's in-memory state persists reliably between every request.
AWS can reuse a warm execution environment sometimes, but this is not guaranteed — any state that must survive between requests needs a real external data store, not a module-level Python variable.
Real-World Examples
Serverless Support Tooling
A real support-ticket triage endpoint deployed this way scales automatically from zero requests overnight to a burst of hundreds during a support surge, without any manual server provisioning.
// Same handler code, automatic concurrency scaling