AWS published a migration guide showing how to move a production healthcare agent from self-managed ECS containers to Bedrock AgentCore runtime. The pattern preserves triple-model orchestration (specialist models for triage, diagnosis, and treatment planning) and vector-enhanced knowledge retrieval while eliminating container orchestration overhead.
This is not a feature announcement. It is a concrete infrastructure decision: when does managed runtime overhead justify giving up control over execution shape, and when does self-hosted flexibility outweigh operational burden?
The Migration Path
The original architecture ran on Amazon ECS with Fargate. You defined task definitions, managed container lifecycle, handled scaling policies, and wired up CloudWatch logs. The agent coordinated three foundation models:
- Triage model: Initial symptom classification
- Diagnosis model: Differential diagnosis generation
- Treatment model: Care plan recommendations
Each model call required explicit state management, retry logic, and observability instrumentation. Vector retrieval from a knowledge base happened through custom API calls to OpenSearch or Pinecone.
AgentCore runtime abstracts this. You define the agent in a configuration object, specify model endpoints, and let AWS handle execution, state persistence, and logging. The trade-off is opacity: you lose visibility into container-level metrics and cannot customize the execution environment beyond what AgentCore exposes.
What AgentCore Manages for You
When you migrate to AgentCore, AWS takes over:
- Execution runtime: No task definitions, no container images, no scaling policies
- State persistence: Agent conversation history and intermediate outputs stored automatically
- Model routing: Declarative configuration replaces imperative orchestration code
- Observability: CloudWatch integration without custom instrumentation
- Vector retrieval: Built-in knowledge base connector handles embeddings and search
You configure the agent through a JSON or YAML manifest. AgentCore interprets this and provisions the runtime.
agent:
name: healthcare-triage-agent
models:
- id: triage
endpoint: bedrock:anthropic.claude-3-sonnet
role: symptom-classifier
- id: diagnosis
endpoint: bedrock:anthropic.claude-3-opus
role: differential-diagnosis
- id: treatment
endpoint: bedrock:anthropic.claude-3-sonnet
role: care-planning
knowledgeBase:
type: vector
source: s3://medical-guidelines/embeddings
retrievalConfig:
topK: 5
minScore: 0.7
The runtime executes this configuration. You do not write orchestration loops or manage retries. AgentCore handles model invocation order based on dependencies you declare.
Multi-Model Orchestration Under the Hood
The triple-model pattern works because AgentCore supports sequential and parallel execution. You define dependencies:
- Triage model runs first
- Diagnosis model waits for triage output
- Treatment model consumes both triage and diagnosis results
AgentCore serializes intermediate outputs and passes them as context to downstream models. This replaces custom state management code you would write in ECS.
State flow in self-managed ECS:
- Invoke triage model via Bedrock API
- Store result in DynamoDB or S3
- Poll for completion or use EventBridge
- Retrieve triage result
- Invoke diagnosis model with triage context
- Repeat for treatment model
State flow in AgentCore:
- Submit user input to agent endpoint
- AgentCore invokes models in dependency order
- Intermediate results stored in managed state store
- Final output returned to caller
You lose control over where state lives and how long it persists. AgentCore manages this internally. If you need custom state retention policies or cross-region replication, you cannot configure it.
Vector Retrieval Integration
The original ECS implementation called a vector database directly. You managed embeddings, handled search API calls, and merged retrieval results into model context.
AgentCore provides a knowledge base connector. You point it at an S3 bucket with pre-computed embeddings or configure it to generate embeddings on the fly. The runtime handles retrieval and context injection.
Configuration example:
knowledgeBase:
type: vector
source: s3://medical-guidelines/embeddings
embeddingModel: amazon.titan-embed-text-v1
retrievalConfig:
topK: 5
minScore: 0.7
reranking: true
AgentCore queries the knowledge base before each model invocation. Retrieved documents appear in the model's context window. You do not write retrieval code or manage embedding pipelines.
The limitation: you cannot customize the retrieval algorithm. If you need hybrid search (vector + keyword), custom reranking, or dynamic embedding updates, you must handle this outside AgentCore and pass results as input.
Trade-off Matrix
| Dimension | Self-Managed ECS | AgentCore Runtime |
|---|---|---|
| Infrastructure overhead | High (task definitions, scaling, monitoring) | Low (declarative config only) |
| Execution visibility | Full (container logs, metrics, traces) | Limited (CloudWatch logs, high-level metrics) |
| State control | Custom (DynamoDB, S3, Redis) | Managed (opaque persistence) |
| Model orchestration | Imperative (code-based) | Declarative (config-based) |
| Vector retrieval | Custom (direct API calls) | Built-in (knowledge base connector) |
| Deployment speed | Slow (container builds, registry pushes) | Fast (config updates only) |
| Cost predictability | Variable (per-task pricing) | Fixed (per-invocation pricing) |
| Failure isolation | Configurable (retry policies, circuit breakers) | Automatic (built-in retries, no customization) |
When Migration Makes Sense
Move to AgentCore if:
- You spend more time managing infrastructure than improving agent logic
- Your orchestration needs fit within declarative configuration limits
- You do not require custom state retention or cross-region replication
- Built-in observability meets your debugging needs
- You want faster iteration cycles without container rebuilds
Stay on self-managed ECS if:
- You need fine-grained control over execution environment (custom runtimes, libraries, system dependencies)
- Your orchestration logic includes complex branching, loops, or external service calls
- You require custom retry policies, circuit breakers, or failure handling
- You need to inspect or modify intermediate state outside the agent runtime
- Compliance or security policies mandate specific infrastructure configurations
Security Boundary Shifts
In ECS, you control the security perimeter: VPC configuration, IAM roles, secrets management, and network policies. You decide which subnets tasks run in and how they access external services.
AgentCore runs in AWS-managed infrastructure. You configure IAM policies for model access and knowledge base permissions, but you do not control the underlying network or compute environment. If your compliance requirements mandate specific VPC configurations or network isolation, this is a blocker.
AgentCore does support customer-managed KMS keys for encryption at rest and in transit. You can enforce encryption policies through IAM conditions.
Observability Gaps
ECS gives you container-level metrics: CPU, memory, network I/O, task duration. You can export logs to any destination and instrument code with custom traces.
AgentCore provides agent-level metrics: invocation count, latency, error rate, token usage. You get CloudWatch logs for each invocation but cannot access runtime internals. If you need distributed tracing across model calls or custom metrics for business logic, you must infer this from logs.
The runtime does emit structured logs with model invocation details, retrieval results, and error messages. You can parse these for custom dashboards, but you lose the granularity of container-level observability.
Deployment Shape
Self-managed ECS deployments involve:
- Build container image
- Push to ECR
- Update task definition
- Deploy new revision
- Monitor rollout
AgentCore deployments involve:
- Update agent configuration
- Submit to AgentCore API
- Runtime applies changes
No container builds, no registry management, no rollout monitoring. The deployment surface shrinks to configuration changes. This accelerates iteration but removes deployment hooks for custom validation or canary testing.
Likely Failure Modes
In ECS:
- Task fails to start (resource constraints, image pull errors)
- Container crashes (OOM, unhandled exceptions)
- Network timeouts (VPC misconfiguration, security group rules)
- Model API throttling (rate limits, quota exhaustion)
In AgentCore:
- Configuration validation errors (invalid model IDs, missing permissions)
- Model invocation failures (quota limits, service outages)
- Knowledge base retrieval errors (missing embeddings, index corruption)
- State persistence failures (internal service errors, rare)
AgentCore abstracts infrastructure failures but introduces new failure modes around configuration and managed service dependencies. You cannot debug runtime internals or apply custom recovery logic.
Technical Verdict
Use AgentCore runtime when infrastructure management overhead outweighs the value of execution control. If your agent orchestration fits within declarative configuration limits and you do not need custom state management or fine-grained observability, the migration reduces operational burden.
Avoid AgentCore if you require custom execution environments, complex orchestration logic, or specific compliance controls over infrastructure. The managed runtime trades flexibility for simplicity. Know which side of that trade-off your production requirements fall on before migrating.
For teams building healthcare, financial, or manufacturing agents with standard multi-model patterns and vector retrieval, AgentCore eliminates undifferentiated infrastructure work. For teams with custom orchestration needs or strict infrastructure requirements, self-managed ECS remains the better choice.
Top comments (0)