Bedrock and Lambda share the same infrastructure philosophy: pay per use, zero servers to patch. But combining them well means solving concrete problems around timeouts, streaming, and concurrency.
A typical serverless generative AI architecture on AWS connects a client (web, mobile, B2B integration) through API Gateway to a Lambda function that orchestrates business logic and ends up invoking Bedrock -- whether `Converse`, `InvokeModel`, an Agent, or a Flow. Lambda fits naturally because it shares the same per-invocation billing model as Bedrock: there's no idle infrastructure to pay for when there's no traffic, and both scale automatically with demand with no manual intervention.
The minimal viable pattern is straightforward: API Gateway receives the HTTP request, invokes the Lambda synchronously, the Lambda builds the prompt and calls `bedrock-runtime`, and returns the response to the client within the same request-response cycle.
API Gateway REST has a 29-second timeout limit per synchronous request -- insufficient for long responses from extended-reasoning models. The fix isn't raising the timeout (you can't, on REST API), but changing the delivery pattern: use API Gateway WebSocket or a Lambda Function URL with response streaming, delivering tokens to the client as the model generates them via `ConverseStream` or `InvokeModelWithResponseStream`.
With Lambda Function URLs and `InvokeMode: RESPONSE_STREAM`, you can achieve direct HTTP streaming without managing WebSocket connections, simplifying the architecture for clients that support fetch with streaming.
The cold start of a Lambda with the boto3 SDK and necessary dependencies usually adds a few hundred milliseconds to the first invocation after a period of inactivity -- marginal compared to the model's generation latency, but relevant in flows where every millisecond counts (for example, intent classification before showing an interface). To mitigate it, use Provisioned Concurrency on the Lambda function if traffic justifies it economically, or keep the deployment package minimal (avoid importing the full AWS SDK if you only need `bedrock-runtime`).
The Lambda execution role must be strictly limited to the actions and models it actually needs -- never use `bedrock:*` on `Resource: "*"` in production. A well-scoped policy specifies both the action and the exact ARN of the model or resource (Agent, Knowledge Base, Flow) the function can invoke.
Additionally, consider restricting via VPC endpoint policy if the function runs inside a VPC with access to Bedrock via PrivateLink, keeping inference traffic off the public internet even if the IAM policy were compromised.
Bedrock invocations can fail due to throttling (`ThrottlingException`, especially relevant under high load on accounts without Provisioned Throughput), content validation blocked by a guardrail, or transient service errors. Implement exponential-backoff retries specifically for `ThrottlingException` and `ServiceUnavailableException`, but don't automatically retry on a guardrail block -- that's a content decision, not a transient failure, and retrying with the same prompt will produce the same block.
A complete production pattern combines API Gateway (authentication via a Lambda authorizer or Cognito), a Lambda function that retrieves session context from DynamoDB, invokes Bedrock with that context, persists the response back to DynamoDB to maintain conversation history, and returns the result to the client. This pattern, with Provisioned Concurrency tuned to expected traffic and CloudWatch alarms on latency and error rate, is the backbone of most enterprise conversational assistants running today on AWS without a single server to manage.
Carlos Montiel is an enterprise AI solutions architect. He implements LLMs, Agents, RAG, and orchestrators for companies across Guatemala and Latin America. Reach out for a consultation.
Contact Carlos Montiel