Shipping agents
to production

The moment someone says "let's put this in front of real users", questions appear that nobody asked during development. What happens when 200 people hit your agent at the same time? What happens when the model provider has a bad day? If the agent crashes at 3 AM and nobody notices until Monday, what then?

The AI part is rarely what slows teams down. It's the infrastructure: networking, IAM (Identity and Access Management) policies, containers, load balancers. A two-day deployment task becomes a week of troubleshooting because nobody on the team has deployed a containerised application before, and the error messages are hard to decode.

This section closes that gap. It won't turn you into a DevOps engineer, but it gives you enough to get agents running in production. For hardened deployments with custom networking, compliance requirements or multi-region failover, you'll still want to partner with your infrastructure team.

1. What actually changes when you move from development to production, and a readiness checklist
2. The four ways to run agents on AWS and how to choose
3. Deploying on AWS Lambda (serverless, event-driven) and on Amazon ECS with Fargate (always-on containers), with a lab for each
4. Amazon Bedrock AgentCore: its architecture, Runtime, Gateway and Identity, with three labs
5. Enterprise integration patterns for databases, APIs and events, and four industry use cases

The agent worked great for one document at a time. In production, 200 users hit it at once. Model calls started timing out. Temporary files piled up and filled the disk. One malformed PDF crashed the whole process, and there was no recovery: just silence. No logs, no alerts, nothing. They found out it was down when a VP called to complain.

This is a normal trajectory when you skip the production-readiness conversation. Here's what changes:

Teams that rush to deploy often spend twice as long fixing things they should have handled up front. Before you go to production, answer these honestly. If most are missing, that's fine: this section and the next cover them.

AWS gives you four options for running agents in production: AWS Lambda, Amazon Elastic Container Service (ECS), Amazon Elastic Kubernetes Service (EKS) and Amazon Bedrock AgentCore. Each fits a different set of constraints. Picking the wrong one won't end your project, but it can cost you weeks of rework.

Let's explore each path, starting with the simplest.

AWS Lambda lets you attach code directly to an event. You write a handler function, connect it to a trigger (an S3 upload, an API Gateway request, a scheduled event), and Lambda runs it when the trigger fires. Nothing runs, and nothing is billed, in between. That's what serverless means: there are still servers, you just never see or manage them.

Notice where model is created: outside the handler, at module level. Lambda doesn't start a fresh Python process for every request. While traffic is flowing it reuses the same execution environment, and module-level objects survive between calls. The first request pays the setup cost (importing Strands, creating the Bedrock client); every later request on that environment skips straight to the handler. Move that setup inside the handler and you pay it on every single call.

The deployment uses an AWS SAM (Serverless Application Model) template: a YAML file where you define the Lambda function, the API Gateway trigger, the IAM permissions and the container configuration, then deploy it all with one command. SAM turns it into a CloudFormation stack, so everything is created, and later deleted, together.

Timeout: 900 is Lambda's maximum (15 minutes) and MemorySize: 1024 gives the function 1 GB (Lambda also scales CPU with memory). The two parameters let the deploy script choose the CPU architecture and the model without editing the template.

Two pieces are easy to get wrong and hard to debug when you do.

The base image is AWS's official Lambda Python image. CMD ["app.lambda_handler"] tells Lambda which function in which file is the handler. The model ID lives in an environment variable (MODEL_ID), so you can switch models by redeploying with a different parameter, without touching the code.

A user sends a query through API Gateway, which invokes the Lambda function. Inside, your agent sits at the centre. It calls out to the LLM for reasoning and runs tools such as clause extraction or risk scoring. The lab agent has no custom tools at all; the model does the analysis, which keeps the example small.

Each invocation is independent. If the agent asks a clarifying question and the customer replies, that reply is a new invocation, possibly on a different environment, and the agent doesn't remember the first one. Unless you persist the conversation somewhere and restore it, your users will complain the agent has amnesia. A common fix is DynamoDB: store the history keyed by a session ID, load it at the start of each invocation, save it at the end.

Keep an eye on size: a single DynamoDB item can hold at most 400 KB, and long conversations about long contracts can exceed it. Strands' built-in session managers (for example one that stores sessions in S3) are an alternative.

Monday morning, nobody has used the agent since Friday. A customer uploads a contract and waits an extra few seconds (typically 2 to 5, and up to about 15 for a large container image like this lab's) while Lambda starts a fresh environment and loads your dependencies. That's a cold start. It happens on the first invocation and whenever Lambda scales out new environments during a spike. Container images make it slightly slower than zips. Provisioned concurrency keeps a set number of environments pre-warmed, but then you're paying for idle compute, which undercuts one of Lambda's main advantages. Try it in the simulation above.

A month in, a customer uploads a 200-page contract. The agent calls the model many times, cross-references clauses and builds a detailed report. Twelve minutes in, it's still going; at 15 minutes Lambda stops the invocation. Lambda durable functions (announced at re:Invent 2025) use checkpoint-and-replay: the function reruns from the start but skips completed checkpoints, resuming where it left off. That works, but it adds complexity to your design.

Two messages, and the second only makes sense because the agent remembers the first. This isn't a one-off either: staff use the system around the clock, and a conversation might run three, four or five messages before a procedure is booked.

You could build this on Lambda: persist the conversation in DynamoDB, reload it on every invocation, rebuild the agent's context each time. It would work, but you'd be fighting the infrastructure instead of building the feature. A Lambda function wants to wake up, do a thing and go away. This agent needs to be awake, warmed up and ready at all times.

Amazon ECS (Elastic Container Service) gives you that. You put your agent in a Docker container, hand it to ECS and say "keep this running". Run it as an ECS service and it stays up. If the container crashes at 3 AM, the service notices and starts a new one. You don't get paged. You don't write recovery scripts.

The mental shift: on Lambda, your agent is a function that gets called. On ECS, your agent is a web server that's always listening.

Here's the course's scheduling agent. It's a FastAPI web app with a Strands agent inside.

The tools return fixed mock data (three slots, OR-3, booking reference BK-2026-04821). In production each would query the EHR, the calendar system and the booking system. The agent code wouldn't change.

Each request carries request.history: the full conversation so far. The browser keeps track of everything the user and agent have said and sends it all with every new message. The server seeds a fresh agent with that history before processing the latest message. That's how, when the nurse says "the 9 AM slot works", the agent still knows it's about Dr. Arti and a knee replacement.

This is the simplest approach, not the only one. Strands has built-in session management that can persist conversations to the local filesystem or to Amazon S3, and you can write a custom session repository backed by DynamoDB or any database. Those are better for production because the server owns the state, so it survives page refreshes and can be audited. The browser-carries-history pattern suits demos and light deployments where you don't want a persistence layer.

You don't need to be a networking expert to understand the ECS deployment model. Here's what it looks like:

A user opens a URL. That request hits an Application Load Balancer, which routes traffic only to healthy containers. Run two containers and one dies: the load balancer sends everything to the survivor while ECS starts a replacement. Users don't notice.

Behind it, the ECS service keeps your containers running. You tell it "I want two copies of my agent running at all times", and it makes that happen. Crash? Replaced. New version? The service rolls it out gradually, keeping the old version running until the new one passes its health checks.

The lab runs a single task (DESIRED_COUNT=1) to keep costs down, so a crash there means a short outage until ECS replaces it; raise the count to 2 or more when you need failover.

Each container runs from a task definition: a config file that says "use this Docker image, give it this much CPU and memory, send its logs to CloudWatch".

For the compute you have two options. With AWS Fargate you specify CPU and memory and AWS handles the servers: you never see an EC2 instance, never patch an operating system, never think about capacity. With the EC2 launch type you manage the underlying instances yourself, which you'd only do for something Fargate can't provide, like a GPU. Start with Fargate; switch later if you need to.

Productionising adds much more: monitoring, auto-scaling policies, certificates, VPC configuration and a dozen other things that have nothing to do with your agent's actual job. None of it is agent-specific: you'd do exactly the same for a REST API, a batch processor or a website. The infrastructure doesn't know or care that it's running an AI agent.

But agents have problems that generic compute doesn't solve for you:

This is where Amazon Bedrock AgentCore comes in. In Section 1 you met it in the middle layer of the AWS AI stack, the managed solutions alongside Amazon Bedrock, between ready-made applications above and do-it-yourself infrastructure below. In Section 3 you used AgentCore Memory for short- and long-term memory. Those were individual services solving individual problems. Now you'll see how the full set fits together.

AgentCore is a set of composable services, each solving a specific challenge every team hits when moving agents from prototype to production. Use them all together, or pick the ones you need.

The services are composable. Run your agent on ECS but use Gateway for tools. Use Runtime for hosting but manage your own authentication. Use just Memory if that's all you need. Each service has its own API, so you can adopt them independently. Used together they're integrated: Identity flows through to Gateway, Runtime connects to Memory, and Observability captures the full picture without you instrumenting anything.

Inside that dedicated environment the agent can keep state, hold database connections and build up context across many turns. When the session ends, the whole microVM is terminated and its memory sanitised. Nothing is shared between sessions, so nothing can leak between them. In financial services, for example, an agent processing one client's portfolio has zero chance of exposing it to another client's session.

Consider a multi-turn conversation where a user asks the agent to analyse a financial document. The agent extracts data, stores intermediate results and writes temporary files. On Lambda all of that vanishes between invocations. On ECS it lives in a shared container. On AgentCore each user gets their own sandbox, and the agent can behave as if it's running on a dedicated machine.

When a user sends a request, AgentCore creates a session and starts a microVM. The session moves through three states: Active while the agent is processing, Idle while it waits for the next user message, and Terminated when it ends. The default idle timeout is 15 minutes: if the user goes quiet longer than that, the session ends and the microVM is cleaned up. A session can live for up to 8 hours in total; both limits are configurable.

The cost model is what makes this attractive. Runtime bills per second for the CPU and memory your session actually consumes. While the agent is waiting (for the user, for the model's reply, for a tool), CPU usage drops to zero, so in a typical support conversation where the user takes a minute between messages you pay CPU for the 10–20 seconds of real processing per turn, not for the silence. Memory is billed for as long as the session stays open, idle time included, which is why you stop sessions you've finished with (or let the idle timeout do it). Your session state is kept throughout.

If your agent kicks off a long operation, it reports HealthyBusy on its health-check endpoint so AgentCore knows the session is working, not idle. The SDK's app.add_async_task(...) and app.complete_async_task(...) helpers manage that for you.

Only four things change from local development code: import BedrockAgentCoreApp, create the app, decorate your invocation function with @app.entrypoint, and call app.run(). Behind the scenes the app becomes an HTTP service with /invocations for requests and /ping for health checks. The agent logic (tools, system prompt, model) is the same code you've been writing since Section 2.

One subtle point: here the agent is created once, at module level, which on Lambda would mix up different callers' conversations. On Runtime it's exactly right, because every session gets its own microVM and therefore its own agent object. Within a session, follow-up messages reach the same agent, so it remembers the conversation.

Runtime is framework-agnostic. Strands, LangGraph, CrewAI, OpenAI Agents SDK, Google's Agent Development Kit (ADK), the Claude Agent SDK, or something custom: they all deploy the same way. That matters because most organisations end up with agents in several frameworks, through acquisitions, team preferences, or because different frameworks suit different problems.

Say your team builds agents with the Claude Agent SDK and already has a whole programming model: a CLAUDE.md with project context, a skills/ folder of reusable capabilities, MCP servers wired to your tools, maybe sub-agents running jobs in parallel. You can deploy all of that as-is: wrap the entry point with @app.entrypoint and add app.run(). The SDK handles its own tool discovery, skill loading and sub-agent orchestration inside the microVM. Runtime doesn't know or care what's inside; it manages the session, the isolation and the scaling.

The last two rows are usually where the decision is made. Lambda and ECS are general-purpose compute: they'll run your agent, but auth, observability, tool integration and policy enforcement are your responsibility. AgentCore handles those as managed services, which saves weeks of engineering, but you give up fine control over things like network placement, security groups and GPU access. ECS is the escape hatch when you need that control.

Most enterprises don't have MCP servers. They have hundreds of REST APIs described by OpenAPI specs, internal services behind authentication layers, and legacy systems nobody wants to touch. Writing an MCP wrapper for each one, with auth, error handling, retries and rate limiting, is a full-time job. And when the API team changes an endpoint or rotates credentials, you're back in the code.

AgentCore Gateway bridges that gap. Point it at an OpenAPI spec and it generates MCP tools automatically: no server code to write, no wrapper to maintain. Your agent discovers those tools exactly the way it discovered tools from your Section 5 servers, except now they come from your existing API catalogue.

Gateway supports several backend types: an OpenAPI spec for existing REST APIs, a Lambda function for custom logic, or a remote MCP server for tools that already speak the protocol. You can combine them into a single catalogue. The agent doesn't need to know that check inventory hits a Lambda function, send notification goes through an API Gateway endpoint, and update CRM talks to Salesforce. To the agent they're all just tools.

Gateway calls each registered API a target. You register a target by pointing the gateway at an API definition: an OpenAPI spec, a Smithy model, a Lambda function, an API Gateway stage, or a remote MCP server. Gateway reads it, extracts each operation and generates an MCP tool for each, with descriptions, parameter schemas and return types taken straight from the definition.

Here's how the lab creates a gateway and registers a REST API whose spec is stored in S3. First the gateway itself, the front door:

Then register the API as a target. You're telling the gateway: "here's an OpenAPI spec in S3: read it and turn every endpoint into an MCP tool."

targetConfiguration points at the spec. credentialProviderConfigurations tells the gateway how to authenticate to this API: fetch an API key from the credential provider and send it in the X-Api-Key header on every call. The agent never sees that key.

Where this really pays off is composition. Register your customer API, a Lambda function that runs fraud checks and a third-party weather service as targets on the same gateway, and your agent sees one unified tool catalogue on one MCP connection.

On one side, callers must prove who they are before the agent will talk to them, whether the caller is a user, another agent or an automated workflow. On the other side, when the agent calls an external service (a CRM, a calendar API, a code repository) it needs credentials for that service. Without the first, anyone can hit your agent endpoint. Without the second, you end up embedding secrets in environment variables or hard-coding API keys, which is how breaches happen.

Inbound: Identity supports JWT-based authorisation. Your identity provider (Amazon Cognito, Okta, Microsoft Entra ID, or any standard OAuth 2.0 / OIDC provider) issues the token, and Identity validates it before the request reaches your agent.

Outbound: Identity manages the credentials your agent needs for external services, storing OAuth 2.0 tokens and API keys in a secure token vault rather than in your code or configuration. Credentials are encrypted with AWS KMS, bound to specific agent-user combinations, and every access is logged for audit.

In your agent code this shows up as decorators. Put @requires_access_token or @requires_api_key on a function and the SDK fetches, injects and refreshes the credential for you. Identity has built-in credential providers for services like Google, GitHub, Slack, Salesforce and Atlassian, with endpoints and provider-specific settings pre-configured; for anything else you can set up a custom OAuth 2.0 provider.

Because Identity validates the inbound token and manages outbound credentials, it keeps the link between who is calling and what the agent is doing on their behalf. That context, the caller's identity paired with the agent's identity, is what lets the rest of AgentCore enforce per-user, per-action governance.

A FastMCP server like Section 5's, with two production details. It runs over Streamable HTTP instead of stdio, because on AgentCore it's a remote service, not a child process (FastMCP's defaults, port 8000 and path /mcp, are exactly what AgentCore expects). And stateless_http=True makes every request independent, which AgentCore requires: the platform itself manages the MCP session (it adds an Mcp-Session-Id header and routes on it), so the server mustn't keep its own per-connection state.

Everything that differs between your laptop and AgentCore comes from environment variables: where the MCP server is, the agent's public URL, the bearer token for calling the protected MCP server, and the port. Same code, both places.

The MCPClient passes the bearer token as an HTTP header, and it goes straight into tools=[...] next to http_request (from strands_tools), so the agent opens and closes the MCP connection itself.

This is the "give the orchestrator an LLM" extension from Section 5's lab, done properly. Strands' A2AAgent is a client for a remote A2A agent: call it like a local agent and it fetches the card, sends the message and returns the answer. Wrapping it in an @tool lets the orchestrator's model decide when to ask the stock agent. When deployed, an httpx client adds the bearer token to every A2A request.

That's the same message/send you saw on the wire in Section 5; jq digs the answer out of result.artifacts[0].parts[0].text. Change the port to 9001 to talk to the stock agent directly.

You need the starter toolkit CLI (pip install bedrock-agentcore-starter-toolkit; AWS also ships a separate Node.js agentcore CLI with different commands, and this lab uses the Python one) and jq. Follow the request path, then the commands.

A Cognito user pool (the user directory), an app client allowed to log in with username and password, and a user with a permanent password. The discovery URL is where AgentCore finds Cognito's public keys to verify tokens. AUTH_CONFIG tells each runtime: accept only JWTs from this pool, issued to this app client. Note it's sourced, not run, so the exported variables stay in your shell.

--protocol MCP tells Runtime this is an MCP server (port 8000, /mcp). Every runtime is reached at a URL built from its ARN; the ARN contains characters like : and /, so jq '@uri' URL-encodes it.

Why deploy twice? You only learn the agent's public URL after the first deploy, but the agent card must contain that URL (A2A clients send their messages to the URL in the card). The second deploy passes it in as AGENTCORE_RUNTIME_URL.

The Authorization header carries your Cognito token. The session-ID header picks the session (and microVM); two UUIDs glued together comfortably meet the minimum length of 33 characters. The body is the same A2A message as the local test.

The runtimes' CloudWatch log groups (/aws/bedrock-agentcore/runtimes/…) are kept so you can read them later; delete them in the CloudWatch console when you no longer need them.

Databases are often the first integration to break at scale. An agent serving forty concurrent users, each triggering two or three queries, will exhaust a typical Amazon Aurora (AWS's managed relational database) connection pool within minutes. Amazon RDS Proxy sits between your agent and the database and fixes this by multiplexing hundreds of agent requests over a smaller set of real database connections. The agent code doesn't change; the infrastructure absorbs the concurrency.

Three more rules: keep analytical queries (reports, aggregations) off your transactional database and replicate to Redshift or Athena instead; keep conversation state in DynamoDB (as in Section 3); and keep credentials in Secrets Manager with automatic rotation, not in environment variables. Scope the IAM policy to the exact secret ARN the agent needs, and keep database traffic inside a private subnet.

External APIs fail in ways your agent must handle gracefully. Internal services go down during deployments. Third-party providers enforce rate limits and return 429s. Some endpoints just stop responding, with no error at all.

The rules: set a timeout on every call; retry with exponential backoff; and return a structured error the agent can reason about. "I couldn't complete the underwriting check; proceeding with a preliminary assessment" is far better than a raw 500. Circuit breakers stop your agent burning time on timeouts when a service is clearly down. For rate-limited APIs, respect Retry-After headers, and cache responses when the data doesn't change between calls.

Event-driven integration decouples your agent from the systems that feed it. A document lands in Amazon S3; an Amazon EventBridge rule picks up the "object created" event and routes it to the agent (you turn on EventBridge notifications for the bucket first). The upstream system doesn't know the agent exists, and the agent doesn't know about the notification system that alerts users when processing finishes.

When volume spikes, put an SQS queue between EventBridge and the agent to absorb bursts. Messages that fail three times go to a dead-letter queue; a CloudWatch alarm fires, someone investigates, and once the issue is fixed they replay the messages. For scheduled work like weekly reports or batch processing, EventBridge Scheduler starts an ECS RunTask instead of a Service: it spins up, runs the job and terminates.

A bank's fraud system kept catching suspicious crypto transactions, but it flagged legitimate customers so often that "Why can't I buy Bitcoin?" became a daily support ticket. The fraud team was drowning in false positives while real fraudsters slipped through. The fraud model itself, a SageMaker endpoint trained on transaction patterns, was solid. The problem was context: it saw each transaction in isolation and didn't know the customer had been making similar purchases for months.

When a transaction arrives, the agent works sequentially: pull the customer's history from DynamoDB, feed that context to the SageMaker model alongside the current transaction, and escalate only when the risk score warrants it; high-risk transactions trigger a Lambda function that starts the investigation workflow. There's no hard-coded if risk_score > 0.8: call_lambda(): the agent reads the tool descriptions and orchestrates them based on the situation.

Scheduling surgery means coordinating a surgeon, an anaesthesiologist, possibly a specialist, an available operating room, specific equipment that might be in use elsewhere, and a time the patient can actually make. A large hospital system did this manually: coordinators spent hours on the phone, checking calendars and leaving voicemails. By the time they found a slot, the patient had sometimes booked with a competitor.

When a patient requests surgery, the agent checks the Electronic Health Record first: what kind of surgery, which specialists, which equipment. Then it queries multiple calendars in parallel to find a time when everyone is free. Once it finds a slot it books the appointments and sends SMS confirmations. It also checks equipment availability before booking and sends reminders at the right intervals, which it worked out from the tool descriptions and past scheduling patterns. You provide the tools; the model orchestrates them.

A factory had expensive CNC machines with bearings that failed without warning. One day a machine runs fine; the next it's down for three days waiting for parts. Each failure cost roughly $50,000 in lost production. Scheduled maintenance (replace bearings every six months regardless) was wasteful, and bearings still failed in between. Monitoring vibration sensors by hand produced too much data and too many false alarms.

The agent monitors vibration sensors continuously, analyses thermal images for heat patterns, and runs everything through a SageMaker model trained to predict bearing failures. When the risk score crosses a threshold, it checks parts inventory in the warehouse database and creates a maintenance ticket automatically. It also knows to check parts before scheduling maintenance and to schedule during low-production periods, which it learned from the tool descriptions and production schedules, not from hard-coded rules.

An online retailer built one agent to handle all customer support: order tracking, product recommendations and returns. It confused return policies with shipping policies, recommended out-of-stock products, and knew a little about everything without knowing enough about anything.

The fix was three specialised agents (Order Tracking, Product Expert, Returns) wrapped as tools that an orchestrator calls: the agents-as-tools pattern from Section 4. A customer asks about returning an order; the orchestrator calls Order Tracking to check shipment status, then Returns for the policy, and combines both into one reply. Each agent focuses on what it does best, and the orchestrator also uses sentiment analysis to spot frustrated customers who need a human.

You saw what changes in production (reliability, security, scale, cost, debugging) and learned to choose a home for each agent: Lambda for event-driven, quick tasks; ECS for always-on services, continuous workloads and multi-agent teams in one container; AgentCore for managed infrastructure with session isolation, auth, policy and observability built in. You met AgentCore's composable architecture (Runtime, Gateway, Identity, Policy, Memory, Observability and Evaluations), each solving one production problem, together or on its own. You deployed agents three ways, turned a REST API into MCP tools, ran MCP and A2A in the cloud behind OAuth, and learned the patterns for connecting agents to databases, APIs and event-driven systems.

But deployed and production-ready aren't the same thing. Right now, if your agent starts hallucinating, you won't know until a user complains. If a retry loop runs away, you'll find out on the monthly bill. If someone discovers your endpoint, nothing stops them hammering it. That's Section 7.

Ten quick questions. Pick an answer to see why it's right or wrong.