AWS guide walks through migrating production AI agents from ECS to Bedrock AgentCore

What the guide covers

AWS has published a migration guide showing how to shift a production agent from self-managed containers to its managed Bedrock AgentCore runtime. According to the dev.to write-up of the guide, the worked example is a healthcare agent that coordinates three foundation models — one classifies symptoms at triage, one generates differential diagnoses, and one drafts care-plan recommendations — with vector search over a medical knowledge base layered on top.

The original deployment ran on Amazon ECS with Fargate. Operators maintained task definitions, container lifecycles, scaling policies and CloudWatch logging. Every model invocation needed hand-written state handling, retry logic and instrumentation, and retrieval meant direct API calls to a vector database such as OpenSearch or Pinecone.

What AgentCore takes over

Under AgentCore, the agent is described declaratively in a JSON or YAML manifest: named model endpoints, their roles, and a knowledge base source with retrieval settings such as top-k and a minimum relevance score. AWS then handles provisioning, execution, conversation and intermediate-output persistence, model routing, and logging — so shipping a change becomes a configuration update rather than a container build and registry push.

The triple-model pattern survives the move. Developers declare dependencies: triage runs first, diagnosis waits on its output, and treatment consumes both results. AgentCore sequences the calls, serialises intermediate outputs and injects them as context downstream. On ECS, the same flow required writing results to DynamoDB or S3, polling or using EventBridge to detect completion, then fetching context before each subsequent invocation.

What you give up

The article frames this as an infrastructure decision rather than a feature pitch, and the concessions are concrete:

• Execution visibility. Container-level metrics such as CPU, memory, network I/O and task duration are replaced by agent-level metrics — invocation counts, latency, error rates and token usage — plus structured CloudWatch logs. Runtime internals stay off-limits, so distributed tracing across model calls has to be inferred from logs.
• State control. Persistence is managed and opaque. Custom retention policies and cross-region replication cannot be configured.
• Retrieval flexibility. The built-in knowledge base connector handles embeddings and search, but the algorithm itself is fixed. Hybrid vector-plus-keyword search, custom reranking or dynamic embedding updates must run outside AgentCore, with results passed in as input.
• Failure handling. Retries are automatic but not customisable — no self-defined circuit breakers or retry policies.
• The security perimeter. On ECS, teams control the VPC, subnets, IAM roles and secrets. AgentCore runs on AWS-managed infrastructure: you set IAM policies for model and knowledge base access, but not the underlying network. Customer-managed KMS keys are supported for encryption at rest and in transit, which the guide positions as the compensating control.

The write-up also includes a comparison table: ECS demands more operational effort but offers full visibility and configurable failure isolation, while AgentCore inverts that trade, with per-invocation pricing replacing per-task pricing.

When migration makes sense

The guide's own criteria for moving: infrastructure work is crowding out agent-logic work, orchestration fits within declarative limits, built-in observability is sufficient for debugging, and faster iteration without container rebuilds matters. Reasons to stay put include custom runtimes or system dependencies, orchestration with complex branching, loops or external service calls, compliance mandates for specific infrastructure configurations, or any need to inspect and modify intermediate state outside the runtime.

Why it matters

Most production agents today are hand-assembled on generic container infrastructure, with teams rebuilding the same state, retry and retrieval plumbing. AWS is now offering a managed alternative and documenting exactly how a realistic multi-model workload moves onto it. For cloud AI adopters, the guide doubles as a due-diligence checklist: the operational savings are clear, but visibility into execution, control over state, retrieval customisation and network-level security all shift to AWS. In regulated domains like the healthcare example, those concessions — not the convenience — will decide whether migration is viable.