05 – AWS Serverless Agentic AI: Lambda, Bedrock, and AgentCore

Serverless AI runs agentic workloads without provisioning a single EC2 instance. Lambda, Bedrock, AgentCore, and Step Functions compose into elastic, pay-per-use architectures that scale to zero between requests.

Serverless AI: What You’ll Learn

Serverless AI runs agentic workloads on fully managed, event-driven AWS services instead of provisioned infrastructure: Lambda for orchestration, Bedrock for foundation model access, AgentCore for the agent runtime, Step Functions for workflow coordination, and EventBridge for event routing. You pay only for the milliseconds your code runs and the tokens your model emits. This guide covers the canonical Bedrock invocation from Lambda, the role AgentCore plays, and the event-driven patterns that make multi-step pipelines resilient.

By the end, you will know when to reach for Lambda alone versus AgentCore, how Bedrock pricing and quotas shape architecture decisions, and which observability and cost controls to put in place before a serverless AI pipeline reaches production traffic.

Why Serverless Is a Natural Fit for AI Workloads

AI inference is famously bursty: customer service spikes at lunch, fraud detection spikes on weekends, document summarization lands in batches. Provisioned infrastructure forces you to size for peak and pay for idle. The serverless model inverts that curve: Lambda scales from zero to thousands of concurrent invocations within milliseconds; Bedrock exposes foundation models through a stateless API so you pay per token.

Together they eliminate idle cost entirely. A team of three engineers can ship a working chatbot in a week, compressing time-to-value by an order of magnitude. The pattern also aligns with event-driven architectures: a support ticket in EventBridge triggers a Lambda that calls Bedrock, which publishes a summary to SNS, which fans out to downstream agents.

Serverless also compresses experimentation cycles. Swapping a Bedrock model ID, adjusting temperature, or changing the orchestration a Lambda uses to call it, requires no new capacity to provision. That means the same event-driven support example can move from directly calling Bedrock in a quick prototype, through the AgentCore-managed agent shown later, to a fully audited Step Functions pipeline, without re-architecting the underlying compute.

The AWS Serverless AI Stack

The modern stack has six layers. Lambda handles orchestration. Bedrock exposes Anthropic Claude, Amazon Nova, Meta Llama, and other foundation models through a single API. AgentCore adds memory, sessions, and connectors. SageMaker Serverless Inference deploys custom-trained models behind the same pay-per-use model. Step Functions coordinates multi-step agent pipelines with retries and human approval steps. EventBridge routes events with content-based filtering. Lambda@Edge and IoT Greengrass extend inference to CloudFront POPs and on-premises devices.

SageMaker Serverless Inference is worth calling out separately: it applies the same scale-to-zero, pay-per-invocation economics to a custom or fine-tuned model that Bedrock does not host, at the cost of managing the model artifact and container image yourself. Choosing between Bedrock and SageMaker Serverless Inference usually comes down to one question: does a hosted foundation model already do the job, or does the workload need a model fine-tuned on proprietary data?

Each layer is independently scalable and independently billed. The contracts between layers are intentionally narrow: Lambda talks to Bedrock over a JSON API, Bedrock returns structured completions, AgentCore wraps that flow with session state, and Step Functions coordinates the calls. You can swap one model for another without rewriting the pipeline.

AWS Lambda for AI Orchestration

Lambda is the connective tissue of almost every serverless AI pipeline, running the code that calls Bedrock, formats prompts, parses responses, writes to DynamoDB, and emits downstream events. Lambda warm starts complete in under 100 ms (cold starts can exceed 1 second) and scale to thousands of concurrent invocations automatically, absorbing bursty AI traffic without capacity planning.

The most common pattern is the request-response handler: API Gateway proxies to Lambda, Lambda calls Bedrock synchronously and returns the model output. For long-running generation, switch to async invocation with destinations, where Lambda publishes the result to SQS or EventBridge once the model finishes.

In production, keep deployment packages small, use provisioned concurrency for latency-sensitive endpoints, respect Bedrock quotas (a single Lambda can fan out 1,000 concurrent invocations), and use a token bucket to throttle calls. Lambda allocates CPU proportionally to memory, so a function at 2,560 MB often runs faster than at 512 MB. Use Lambda Layers to share the Bedrock SDK and pin each Lambda to a specific layer version.

IAM design matters as much as code: grant each Lambda a role scoped to bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream on the exact model ARNs it calls, never bedrock:*. Set the Lambda timeout close to the expected Bedrock latency plus headroom — a 29-second API Gateway integration timeout means a Lambda calling Bedrock synchronously should target well under 29 seconds, or move to async invocation with destinations.

Reserved concurrency protects downstream Bedrock quotas from a runaway caller: capping a single function’s concurrency prevents one workload from starving the rest of the account’s model throughput. For VPC-attached Lambdas that need to reach Bedrock privately, use a VPC interface endpoint for bedrock-runtime rather than routing through a NAT gateway, which removes a hop and a cost line.

Amazon Bedrock: Foundation Models as a Service

Amazon Bedrock exposes foundation models from Anthropic, Meta, Mistral, AI21, Cohere, and Amazon as a single, stateless API. You never see a GPU, never tune a container, and pay per input and output token. Invoking Bedrock from Lambda is the canonical pattern:

import json, boto3

bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')

def lambda_handler(event, context):
    response = bedrock.invoke_model(
        modelId='anthropic.claude-3-5-sonnet-20241022-v2:0',
        contentType='application/json',
        accept='application/json',
        body=json.dumps({
            'anthropic_version': 'bedrock-2023-05-31',
            'max_tokens': 1024,
            'messages': [{'role': 'user', 'content': event['prompt']}]
        })
    )
    result = json.loads(response['body'].read())
    return result['content'][0]['text']

For streaming responses, use invoke_model_with_response_stream; for batch workloads, use Bedrock’s model invocation jobs. The full feature set is documented in the Amazon Bedrock User Guide.

Knowledge Bases turn Bedrock into managed RAG; Guardrails add prompt safety and PII masking without changing your Lambda code.

Model selection is a first-class architectural decision, not an afterthought. Bedrock cross-region inference profiles route a single invocation across multiple regions to smooth out capacity spikes without any code change, which matters for serverless AI pipelines that burst unpredictably. For latency-tolerant, high-volume jobs — nightly summarization, bulk classification — Bedrock batch inference processes thousands of prompts asynchronously at a lower per-token cost than real-time invocation.

Throttling is normal at scale, not a bug: wrap invoke_model calls in exponential backoff with jitter, and treat a throttling exception as a retryable error rather than a failure to surface to the caller. Pin a specific model version in production rather than tracking the latest alias, so a provider-side model update cannot silently change your output distribution.

Amazon Bedrock AgentCore: The Agent Runtime

Where Bedrock is a stateless model API, AgentCore adds the runtime services that turn a model into an agent: managed sessions, a memory store for long-term context, a gateway for authentication and rate limiting, and a connector framework for external tools through MCP. Lambda invokes an AgentCore session, which retrieves memory, resolves connectors, calls Bedrock, persists state, and returns the result.

Your Lambda shrinks to a thin client. The memory primitive is key for multi-tenant deployments: a managed AgentCore Memory instance per tenant gives isolated long-term context without you building a vector store. AgentCore also exposes a gateway for multi-agent orchestration.

The AgentCore Gateway converts existing REST APIs and Lambda functions into MCP-compatible tools without rewriting them, so a serverless AI agent can call your existing order-lookup Lambda through the same protocol it uses for any other tool. AgentCore Memory supports both short-term session context and long-term summarized memory, with configurable retention windows.

Indefinite retention of customer conversation history is itself a governance decision, not a default to accept unexamined. The AgentCore code interpreter and browser tool run in isolated, ephemeral sandboxes per session, so a compromised or hallucinated tool call cannot persist state or reach other tenants’ data — a property that matters more in serverless AI than in a traditional long-lived server process.

Event-Driven AI with EventBridge and Step Functions

Event-driven serverless AI reacts to business events instead of waiting for synchronous HTTP. A new support ticket, a payment failure, a file landing in S3, or a sensor threshold can all trigger a pipeline. EventBridge is the event bus that routes these signals; it integrates natively with Lambda, Step Functions, and Bedrock.

The canonical flow: a producer publishes an event to a custom bus, EventBridge matches it against rules and routes it to Lambda or Step Functions, which calls Bedrock, processes the result, and optionally publishes a downstream event. The pipeline scales independently and costs nothing when idle.

Step Functions Express Workflows suit high-volume, short-duration serverless AI pipelines — sub-5-minute executions billed by requests and duration rather than per state transition — while Standard Workflows suit long-running, human-in-the-loop approvals with exactly-once execution semantics and full execution history for auditing.

Attach a dead-letter queue to every EventBridge rule and Lambda destination: a malformed event or a Bedrock call that fails after all retries should land somewhere inspectable, not vanish. Idempotency keys matter once retries enter the picture — deduplicate on a ticket ID or request hash before writing to DynamoDB, since a retry or redrive can replay the same event more than once.

For multi-step workflows, Step Functions models pipelines as state machines with retries, error handling, parallel branches, and human approval steps. Use Retry and Catch blocks with exponential backoff and SQS redrive policies for poisoned messages.

Edge AI with Lambda@Edge and IoT Greengrass

Lambda@Edge runs code at CloudFront points of presence worldwide, letting you personalize content, rewrite URLs, or run lightweight inference close to users. IoT Greengrass extends the pattern to on-premises devices: factory sensors, retail kiosks, and vehicles.

The economic argument is latency and bandwidth: a vision model on a Greengrass camera avoids sending gigabytes of video over cellular. Each Greengrass capability ships as a versioned component that deploys and monitors independently, so you push a new model version to a subset of devices and roll forward or back without a truck roll.

CloudFront Functions and Lambda@Edge solve different problems despite living at the same edge location: CloudFront Functions run sub-millisecond, lightweight JavaScript for header manipulation and simple routing, while Lambda@Edge supports full Node.js or Python runtimes, longer execution times, and network calls — the right choice when an edge function needs to call Bedrock rather than just rewrite a request.

Greengrass deployments group components into a single deployment document, so a device receives a model update, its dependencies, and a configuration change atomically, avoiding the partial-update failures common in device fleets managed by hand.

Security and Governance for Serverless AI

Security is layered because the surface area is broad: Lambda runs your code, Bedrock holds the model, AgentCore persists sessions, and IAM controls every hop. Start with IAM least privilege, granting each Lambda only the specific Bedrock actions and model IDs it needs. Avoid wildcard bedrock:* permissions.

Add Bedrock Guardrails for prompt safety, PII masking, and topic denial. For regulated workloads, pair guardrails with KMS customer-managed keys and VPC endpoints to keep traffic off the public internet. CloudTrail logs every Bedrock API call, Lambda invocation, and AgentCore session for end-to-end auditability.

Bedrock Guardrails enforce denied topics, word filters, and PII redaction at the API layer, before a prompt reaches the model and before a response reaches the caller, so policy lives in one place instead of being reimplemented in every Lambda. Resource-based policies on Bedrock restrict which accounts or VPCs can invoke a given model, which matters for shared multi-tenant deployments.

For workloads that cannot tolerate any traffic on the public internet, a VPC interface endpoint for Bedrock keeps invocation traffic entirely within your VPC and AWS’s private network, satisfying data-residency and network-isolation requirements common in regulated industries.

Observability for Serverless AI Pipelines

Serverless AI fails in ways traditional web services do not: a model returns a malformed response, a prompt exceeds the token limit, an agent loops, a Bedrock call throttles. None show up as CPU spikes. The minimum stack is three layers: structured JSON logs from every Lambda with a correlation ID, prompt length, model ID, latency, and token count; metrics on invocations, errors, throttles, p50/p99 latency, and tokens; and distributed traces through X-Ray.

Track quality metrics too: answer length, refusal rate, hallucination flags. Correlation IDs are non-negotiable: generate one at the EventBridge entry and propagate through every hop. Wire SLOs (p99 latency, verifier pass rate, cost-per-request) into CloudWatch alarms.

Embedded Metric Format lets a Lambda emit structured CloudWatch metrics directly from its logs without a separate API call, which keeps cost down on high-invocation serverless AI pipelines. CloudWatch Logs Insights queries filtering on correlation ID turn a scattered multi-service trace into a single readable timeline.

This matters when a Step Functions execution touches Lambda, Bedrock, and DynamoDB in sequence and something upstream needs to know exactly where a request stalled. X-Ray subsegments around each Bedrock call isolate model latency from your own code’s latency — the difference between blaming a provider and finding a real bug in your own retry logic.

Cost Optimization Patterns for Serverless AI

The pay-per-use model cuts both ways: a poorly tuned pipeline can burn a monthly budget in days. Three levers compound. Model selection is the biggest: Claude Haiku and Amazon Nova Lite handle classification, summarization, and routing at a fraction of Sonnet or Opus cost, often cutting total cost by 60 to 80 percent.

Prompt caching reuses long system prompts or retrieved context, cutting input token cost by another 50 percent on RAG-heavy pipelines. Provisioned throughput gives a fixed discount for committed spend, but is a trap for bursty workloads; model the break-even first. A Step Functions map state batching ten prompts into one Bedrock invocation job cuts per-prompt overhead by an order of magnitude.

Prompt compression — trimming boilerplate instructions, deduplicating retrieved context chunks, summarizing long conversation history before it re-enters the context window — reduces input tokens on every call, and the savings compound across millions of invocations in a way a one-time architecture review will not catch.

Track cost per successful outcome, not cost per invocation: a cheap model that requires three retries to produce a usable answer can cost more than a pricier model that succeeds on the first attempt. Cost allocation tags applied consistently at resource creation, not retrofitted later, make a Cost Explorer breakdown by workload trustworthy months into a serverless AI program.

Serverless AI in Practice: A Worked Example

Consider a customer support pipeline for an online retailer: classify every inbound ticket, draft a response, escalate when confidence is low, and log the outcome. Tickets land in SES, which publishes to EventBridge, routing to a Step Functions state machine. The first step invokes Lambda calling Bedrock to classify the ticket.

For common categories like order status, Lambda calls Bedrock directly. For sensitive categories like refunds, the workflow invokes an AgentCore session with access to customer history through MCP connectors, running a drafter agent then a reviewer agent. If confidence falls below a threshold, Step Functions pauses and publishes a human-review task.

The final response goes via SES, conversation is persisted to DynamoDB, and a summary event flows to EventBridge. When ticket volume drops to zero at night, cost drops with it. When a viral issue spikes tickets tenfold, Lambda and Bedrock scale to absorb it.

The IAM role backing the classification Lambda holds a single, narrow statement: bedrock:InvokeModel scoped to the Claude Haiku model ARN, dynamodb:PutItem and dynamodb:UpdateItem scoped to the ticket table, and nothing else. The Step Functions state machine models the workflow as a Choice state routing on the classification result.

A Task state invokes the AgentCore session for sensitive categories with a Retry block on throttling and service-unavailable errors, and a Wait state pauses for human review that resumes when a reviewer’s decision lands back in EventBridge. DynamoDB stores each ticket with a composite key of ticket ID and timestamp, so the pipeline can answer both single-ticket and time-range queries without a second data store.

Serverless AI: Common Mistakes to Avoid

• Treating Lambda like a long-running container — loading multi-gigabyte model weights inside the handler. Lambda has a 15-minute timeout and a 10 GB memory cap. Keep heavy assets in Bedrock or SageMaker.
• Ignoring Bedrock quotas — fanning out 1,000 concurrent Lambda invocations against a model with a 100 TPS quota. Requests throttle silently and retries compound. Enforce a token bucket upstream.
• Storing agent state in DynamoDB by hand — building your own session table instead of using AgentCore. The bespoke version breaks the moment you need multi-tenant isolation.
• Synchronous calls for everything — chaining synchronous Bedrock calls through Lambda. A single failure loses the whole run. Move multi-step pipelines to Step Functions with retries and durable state.
• Skipping dead-letter queues — letting a failed EventBridge rule or Lambda destination silently drop events instead of routing them somewhere inspectable, which turns a transient Bedrock throttle into permanently lost data.

Serverless AI: Best Practices

• Right-size the model to the task — default to the smallest Bedrock model that meets your quality bar. Claude Haiku or Nova Lite handles classification, summarization, and routing at a fraction of Sonnet or Opus cost.
• Use provisioned concurrency for latency-sensitive paths — cold starts plus first-token latency can push p99 past two seconds. Provisioned concurrency keeps warm Lambda environments ready.
• Persist agent state in AgentCore, not in your code — let the platform own sessions, memory, and connector credentials. Your Lambda should be stateless and idempotent.
• Instrument everything with structured logs and traces — emit a correlation ID at the start of each event, propagate it through every hop, and ship traces to X-Ray.
• Tag every resource for cost attribution — apply Project, Environment, Agent, and Tenant tags to every resource so Cost Explorer can break down spend by workload.
• Design for idempotent retries from day one — every Lambda in a serverless AI pipeline will eventually be invoked more than once for the same event, whether from an EventBridge retry, a Step Functions redrive, or a client resubmission.
• Treat Bedrock quotas as a capacity plan, not a suggestion — request quota increases before a launch, not after the first throttling incident, and monitor quota utilization the same way you would monitor CPU on a provisioned server.

Serverless AI: Frequently Asked Questions

What is the difference between Bedrock and SageMaker Serverless Inference?

Bedrock exposes foundation models through a managed API with no weights to manage. SageMaker Serverless Inference deploys your own custom-trained models behind a serverless endpoint. Use Bedrock for hosted models; use SageMaker Serverless Inference for proprietary models not in Bedrock’s catalog.

How does Bedrock AgentCore relate to serverless AI?

AgentCore is the agent runtime on top of Bedrock, adding managed sessions, memory, a gateway, and MCP connectors so your Lambda stays thin.

Is serverless AI cheaper than provisioned infrastructure?

For bursty, intermittent workloads, yes, because you pay per request and scale to zero. For steady high-throughput workloads saturating capacity 24/7, provisioned endpoints can be cheaper. Most agentic workloads are bursty, so the serverless model wins by default.

Can I use Lambda for long-running model inference?

Lambda has a 15-minute timeout, enough for most Bedrock calls. For longer jobs like batch fine-tuning or video analysis, use Bedrock model invocation jobs or Step Functions with async invocation.

How do I handle cold starts in serverless AI pipelines?

Use provisioned concurrency on latency-sensitive Lambdas, keep deployment packages small, and use Lambda Extensions to preload the Bedrock SDK. Bedrock’s provisioned throughput option eliminates first-token latency on the model side. Serverless agentic AI on AWS scales per-request: Lambda pays per invocation, Bedrock per token, AgentCore per session.

Serverless AI: Key Takeaways

• It is the default for new agentic workloads on AWS because it matches the bursty, event-driven shape of real AI traffic.
• The stack is layered and composable: Lambda orchestrates, Bedrock serves models, AgentCore runs agents, Step Functions coordinates, EventBridge routes.
• Bedrock is the foundation, and invoking it from Lambda is the canonical pattern.
• AgentCore absorbs agent complexity — sessions, memory, connectors — so your Lambda stays stateless.
• Right-size models and provision concurrency to control cost and latency.

Serverless AI on AWS turns Lambda, Bedrock, and AgentCore into a pay-per-use agent stack: no idle infrastructure, no capacity planning, and cost that tracks real usage. Master this serverless pattern before moving to always-on architectures — most agentic workloads are bursty, and serverless is the default for a reason.