Running AI Agents on EKS vs. Amazon Bedrock AgentCore: A Well-Architected Perspective
A practical comparison of running AI agents on Amazon EKS versus Amazon Bedrock AgentCore, examining how each platform addresses deployment, security (including agent-to-agent and agent-to-tool policy enforcement), disaster recovery, cost, and performance through the lens of the AWS Well-Architected Framework.
Running AI Agents on EKS vs. Amazon Bedrock AgentCore: A Well-Architected Perspective
AI agents are moving from prototypes to production, and the infrastructure decision you make today will shape your operational reality for years. Two paths dominate on AWS: self-managing agents on Amazon EKS, or deploying them on Amazon Bedrock AgentCore — a purpose-built managed platform for agentic workloads.
This post compares both approaches through the lens of the AWS Well-Architected Framework , focusing on ease of deployment, security, disaster recovery, and the operational primitives each platform provides. The goal isn't to declare a winner — it's to help you understand what you're signing up for.
What Is Amazon Bedrock AgentCore?
AgentCore is a set of managed services designed specifically for building, deploying, and operating AI agents at scale. Rather than providing a single monolithic runtime, it offers composable primitives that address the core challenges of production agent infrastructure:
- AgentCore Runtime — Serverless agent hosting with microVM-based session isolation, supporting any framework (LangGraph, Strands, CrewAI, etc.) and any model provider.
- AgentCore Memory — Short-term (session) and long-term (cross-session) memory with configurable extraction strategies.
- AgentCore Identity — Agent-specific identity and credential management with OAuth2, JWT, and IAM support for both inbound auth and outbound tool access.
- AgentCore Gateway — Transforms APIs, Lambda functions, and services into agent-ready tools with a unified MCP interface, including auth, throttling, and tool selection.
- AgentCore Observability — End-to-end tracing, step-level visualization, and operational dashboards via OpenTelemetry and CloudWatch.
- AgentCore Browser — Managed browser instances for web automation workflows.
- AgentCore Code Interpreter — Isolated sandboxes for agent-generated code execution.
- AgentCore Policy — Deterministic, Cedar-based authorization layer that intercepts every agent-to-tool request at the Gateway boundary. Enforces fine-grained access controls based on user identity and tool input parameters — outside the agent's code and reasoning — so policies hold even under prompt injection or agent bugs.
On EKS, every one of these capabilities must be built, integrated, and maintained by your team.
Pillar 1: Operational Excellence (Ease of Deployment)
AgentCore: From Zero to Deployed in Minutes
AgentCore's deployment model is remarkably lean, especially with the new AgentCore CLI (
@aws/agentcore ). The CLI replaces the older starter toolkit with a modern, Node.js-based terminal experience that handles project scaffolding, local development, and cloud deployment in a unified workflow.Install it globally:
Bash
npm install -g @aws/agentcore
Create a new agent project with an interactive wizard — or go fully non-interactive:
Bash
# Interactive terminal UIagentcore create# Or fully scripted with defaults (Python, Strands, Bedrock, no memory)agentcore create --name MyAgent --defaultscd MyAgent
The CLI generates a complete project structure with your agent code, model configuration, dependencies, and CDK infrastructure:
Plain text
my-project/├── agentcore/│ ├── .env.local # API keys (gitignored)│ ├── agentcore.json # Resource specifications│ ├── aws-targets.json # Deployment targets│ └── cdk/ # CDK infrastructure├── app/│ └── MyAgent/│ ├── main.py # Agent entry point│ ├── pyproject.toml # Python dependencies│ └── model/ # Model configuration
Test locally with a built-in dev server, then deploy to AWS — all from the same CLI:
Bash
# Start local dev server with hot reloadagentcore dev# Deploy to AWS (auto-provisions Runtime, IAM roles, ECR, etc.)agentcore deploy# Invoke the deployed agentagentcore invoke "What can you do?"
Need memory, identity, or a tool gateway? Add them incrementally without touching your agent code:
Bash
# Add semantic + summarization memoryagentcore add memory --name SharedMemory --strategies SEMANTIC,SUMMARIZATION# Add an MCP-compatible gateway with OAuthagentcore add gateway --name MyGateway --authorizer-type CUSTOM_JWT \--discovery-url https://idp.example.com/.well-known/openid-configuration \--allowed-clients my-client-id# Expose an MCP server as a gateway targetagentcore add gateway-target --name WeatherTools --type mcp-server \--endpoint https://mcp.example.com/mcp --gateway MyGateway# Add API key credentials for external providersagentcore add identity --name OpenAI --api-key sk-...# Deploy all changesagentcore deploy
The CLI supports Strands, LangGraph, Google ADK, and OpenAI Agents out of the box, with Bedrock, Anthropic, OpenAI, and Gemini as model providers. You can also bring your own code with
agentcore add agent --type byo .No Dockerfiles, no Helm charts, no ingress controllers. Observability is enabled by default — traces flow to CloudWatch with OpenTelemetry support for Datadog, LangSmith, and Langfuse.
Compare this to the EKS equivalent: writing Dockerfiles, authoring Helm charts, configuring CI/CD pipelines, and wiring up each infrastructure primitive manually.
EKS: Full Control, Full Responsibility
On EKS, deploying an agent means:
- Writing Dockerfiles and building container images
- Authoring Kubernetes manifests or Helm charts (Deployments, Services, Ingress, HPA, PodDisruptionBudgets)
- Configuring a service mesh or API gateway for routing and TLS termination
- Setting up cluster autoscaling (Karpenter or Cluster Autoscaler) and pod-level HPA
- Managing EKS add-ons (CoreDNS, kube-proxy, VPC CNI, EBS CSI driver)
- Patching AMIs, upgrading the Kubernetes control plane, and rotating certificates
- Building a CI/CD pipeline for container builds, image scanning, and rolling deployments
- Instrumenting agents with OpenTelemetry, deploying collectors, and configuring backends
You get surgical control over every aspect of the runtime — pod topology, resource requests/limits, sidecar patterns, node affinity, and scheduling. This matters when you need co-located Redis sidecars, GPU node pools, or custom networking. But the Day 2 operational burden is significant.
The Primitives Gap
Capability | AgentCore Primitive | EKS Equivalent (You Build It) |
|---|---|---|
Agent deployment | agentcore create + agentcore deploy | Dockerfile + Helm + CI/CD pipeline |
Session isolation | MicroVM per session (built-in) | Pod-level isolation + network policies |
Auto-scaling | Serverless, consumption-based | HPA + Karpenter + capacity planning |
Memory (short-term) | memory_client.create_event() | Redis/ElastiCache + custom integration |
Memory (long-term) | memory_client.retrieve_memories() | Vector DB + embedding pipeline + custom extraction |
Agent identity | @requires_access_token decorator | IRSA + Secrets Manager + custom OAuth flows |
Tool gateway | AgentCore Gateway (MCP-native) | Custom API adapters + retry logic |
Observability | Built-in dashboards + OpenTelemetry | OpenTelemetry collector + Prometheus + Grafana + custom dashboards |
Every row in the "EKS Equivalent" column represents weeks of engineering effort and ongoing maintenance.
Pillar 2: Security
Security for AI agents goes beyond traditional application security. Agents make autonomous decisions, hold credentials for external systems, and process sensitive data in non-deterministic ways. Both platforms address this, but at very different levels of abstraction.
AgentCore: Security as a Primitive
Session Isolation via MicroVMs. Each user session runs in a dedicated microVM with isolated compute, memory, and filesystem. When a session ends, the entire VM is terminated and memory is sanitized. This is a hardware-level isolation boundary — not just container namespaces. This architecture directly prevents the class of cross-tenant data leakage bugs that have affected production agent deployments (such as the Asana MCP incident referenced in AWS documentation, where a logic flaw in session isolation exposed data across 1,000 organizations for 34 days).
Agent Identity. AgentCore Identity provides a purpose-built identity layer for agents. Each agent gets a workload identity. Inbound auth supports IAM SigV4 and JWT (Cognito, Okta, Entra ID). Outbound auth uses a secure token vault that stores user-consented OAuth tokens and API keys, with cryptographic binding between agent identity and user identity. The
@requires_access_token and @requires_api_key decorators make credential access declarative in code.Credential Isolation. The token vault ensures User A's Google Drive token can never be accessed when processing requests for User B — regardless of application logic errors. This is enforced at the platform level, not in your code.
VPC and PrivateLink Support. Since GA, AgentCore supports VPC-only deployments and PrivateLink, keeping agent traffic off the public internet.
EKS: Granular but Manual
Pod-Level Isolation. EKS provides container-level isolation via Linux namespaces and cgroups. This is weaker than microVM isolation — container escapes, while rare, are a known attack vector. For stronger isolation, you can run Firecracker microVMs on EKS (via Kata Containers), but this adds significant operational complexity.
IAM Roles for Service Accounts (IRSA). Each agent pod can assume a unique IAM role, enabling least-privilege access. This is powerful but requires careful configuration — one misconfigured role binding can grant an agent access to resources it shouldn't touch.
Network Policies. Kubernetes NetworkPolicies give you fine-grained control over pod-to-pod and pod-to-external traffic. You can enforce that only the Dealer Filing Agent can reach dealer portal endpoints, for example. But you need to write and maintain these policies, and they require a CNI that supports them (Calico, Cilium).
Secrets Management. You integrate with Secrets Manager or Parameter Store via CSI drivers or init containers. Credential rotation, token vaulting, and OAuth flows are your responsibility.
The Security Tradeoff. EKS gives you more knobs to turn, which is valuable when you need custom security postures. But every knob is also a potential misconfiguration. AgentCore's opinionated security model eliminates entire categories of mistakes — you can't accidentally share a session context between users because the platform makes it architecturally impossible.
Agent-to-Tool Security: AgentCore Policy
Production agents call tools — APIs, databases, code interpreters, web browsers. The question isn't whether an agent can call a tool, but whether it should, given the current user, the current context, and the specific parameters being passed. This is where AgentCore Policy comes in.
AgentCore Policy is a deterministic enforcement layer that sits at the AgentCore Gateway boundary, intercepting every agent-to-tool request and evaluating it against Cedar policies before the tool is invoked. Cedar is an open-source authorization language designed for fine-grained, analyzable permissions. The key insight: policy enforcement happens outside the agent's code and outside the agent's reasoning. Even if an agent is compromised via prompt injection, manipulated by adversarial input, or simply has a bug, the policy boundary holds.
This is fundamentally different from embedding security rules in agent prompts or application code. Prompt-based guardrails are probabilistic — they depend on the LLM correctly interpreting and following instructions. Code-based checks are scattered across the codebase and hard to audit. AgentCore Policy is deterministic: the same request with the same context always produces the same authorization decision.
How it works in practice. Consider a healthcare scheduling agent with tools for reading patient records, checking appointment slots, and booking appointments. With AgentCore Policy, you define Cedar policies like:
- Identity-scoped access: A patient can only read their own records — the
patient_idparameter in the tool call must match the authenticated user's identity claim. No exceptions, regardless of what the agent decides to do.
- Read/write separation: Read operations require a
readscope; write operations requireappointment:write. The scopes come from the authenticated JWT, not from the agent's reasoning.
- Business rule enforcement: Appointment slots can only be queried between 9 AM and 9 PM UTC. A
forbidrule blocks requests outside that window, and in Cedar, forbid always wins over permit.
Policies can be authored directly in Cedar for programmatic control, or generated from plain English descriptions — the service translates natural language into Cedar, validates it against the gateway's tool schema, and uses automated reasoning to flag policies that are overly permissive, overly restrictive, or contain unsatisfiable conditions.
The enforcement model is default-deny: if no
permit policy matches a request, it's blocked. You layer broad permit rules for common operations and targeted forbid rules for high-risk actions. Every decision is logged to CloudWatch for audit. You can also run the policy engine in LOG_ONLY mode first to validate behavior without disrupting production traffic, then switch to ENFORCE mode when confident.On EKS, you build all of this yourself. There's no equivalent primitive. You'd need to implement a policy decision point (potentially using Open Policy Agent or Cedar as a library), deploy it as a sidecar or service, write an admission/interception layer in your API gateway or service mesh, define and manage policy documents, and build the audit logging pipeline. It's doable, but it's months of work and an ongoing maintenance burden — and every gap in your implementation is a potential security hole.
Agent-to-Agent Security: A2A Protocol + AgentCore Identity
As agent systems grow from single agents to multi-agent architectures — where a host agent orchestrates specialist agents for monitoring, operations, compliance, or customer support — the security model must extend to agent-to-agent communication. Who is this agent? Is it allowed to call that agent? Can it act on behalf of this user?
AgentCore addresses this through the combination of the Agent-to-Agent (A2A) protocol on AgentCore Runtime and AgentCore Identity's workload identity system.
Workload identities for agents. Every agent deployed on AgentCore Runtime receives a unique workload identity — a first-class identity in the AgentCore Identity directory, not just an IAM role. This identity persists across deployments and authentication schemes, providing a stable anchor for authorization decisions. When Agent A calls Agent B, both agents have verifiable identities that can be validated independently.
Authenticated agent discovery. The A2A protocol uses agent cards — JSON metadata files published at
/.well-known/agent-card.json — that advertise an agent's capabilities, endpoints, and authentication requirements. Before an agent can communicate with a peer, it must discover the agent card and authenticate. AgentCore Runtime supports authenticated agent cards, so discovery itself is a secured operation.Two authentication models for A2A. AgentCore Runtime supports two methods for securing agent-to-agent communication:
- OAuth 2.0 (JWT-based): The calling agent authenticates with an authorization server (e.g., Amazon Cognito) to obtain a JWT, which is included with every request to the remote agent. The remote agent's AgentCore Runtime validates the token against the configured authorizer. This supports both machine-to-machine (M2M) credentials and user federation — so an agent can call another agent on behalf of a specific user, with the user's identity propagated through the token chain.
- AWS IAM (SigV4): The calling agent assumes an IAM role with permissions to invoke the remote agent. Requests are signed with SigV4, and IAM policies control which agents can invoke which other agents. This is the natural choice for agents that stay within AWS boundaries.
Identity propagation across agent chains. When a host agent delegates a task to a specialist agent, the user's identity context travels with the request. If User A asks the host agent to check their patient records, and the host agent delegates to a monitoring agent, the monitoring agent receives User A's identity claims. Combined with AgentCore Policy at the gateway, this means the monitoring agent can only access User A's data — even though the request originated from a different agent. The cryptographic binding between workload identity and user identity prevents cross-user data access regardless of how many agents are in the chain.
VPC and PrivateLink for agent-to-agent traffic. For sensitive multi-agent deployments, AgentCore Runtime supports VPC connectivity and AWS PrivateLink, keeping agent-to-agent communication within your VPC without traversing the public internet. This is critical for regulated industries where inter-service traffic must stay on private networks.
On EKS, agent-to-agent security is entirely your problem. You'd need to:
- Implement mutual TLS (mTLS) or JWT-based auth between agent pods using a service mesh (Istio, Linkerd) or custom middleware
- Build an agent identity registry and discovery mechanism
- Implement identity propagation across service calls (correlation IDs, JWT forwarding, or custom headers)
- Write and maintain NetworkPolicies to control which pods can communicate
- Build audit logging for inter-agent calls
- Manage certificate rotation for mTLS
This is achievable with Kubernetes-native tooling, but it's a significant engineering investment. And unlike AgentCore's approach — where identity, policy, and protocol are integrated into a single coherent system — on EKS you're stitching together multiple independent tools (Istio for mTLS, OPA for policy, custom code for identity propagation) and hoping the seams hold.
The Security Primitives Comparison
Security Concern | AgentCore Primitive | EKS Equivalent (You Build It) |
|---|---|---|
Session isolation | MicroVM per session | Container namespaces + optional Kata/gVisor |
Agent identity | Workload Identity Directory | IRSA + custom identity registry |
Inbound auth (user → agent) | JWT/SigV4 authorizer (built-in) | API gateway + custom JWT validation |
Outbound auth (agent → tool) | Token vault + @requires_access_token | Secrets Manager + custom OAuth flows |
Agent-to-agent auth | A2A protocol + OAuth 2.0/SigV4 | mTLS via service mesh + custom JWT forwarding |
Agent-to-tool policy | Cedar policies at Gateway (deterministic) | OPA/Cedar sidecar + custom interception layer |
Identity propagation | Cryptographic binding (workload + user) | Custom header forwarding + correlation IDs |
Policy authoring | Natural language → Cedar + automated reasoning | Manual policy writing + custom validation |
Audit logging | CloudWatch (built-in for all decisions) | Custom logging pipeline per component |
Network isolation | VPC + PrivateLink (managed) | NetworkPolicies + service mesh (you configure) |
Pillar 3: Reliability and Disaster Recovery
AI agents introduce failure modes that don't exist in traditional applications: non-deterministic reasoning loops, tool call cascades, credential expiry mid-session, and multi-hour stateful workflows that can't simply be restarted. The AWS resilience framework for AI agents identifies seven risk dimensions, and the two platforms address them differently.
AgentCore: Managed Resilience
Session Lifecycle Management. AgentCore Runtime manages session states (Active → Idle → Terminated) with configurable timeouts. Sessions persist for up to 8 hours, supporting long-running async workflows. The platform handles health checks, session cleanup, and resource reclamation automatically.
Consumption-Based Scaling. There's no capacity planning. AgentCore scales to zero when idle and provisions microVMs on demand. You don't pay for CPU during I/O waits (waiting for LLM responses or API calls), which is typically 70%+ of agent execution time. This eliminates the "insufficient capacity" failure mode entirely for the agent runtime layer.
Memory Durability. AgentCore Memory separates ephemeral session state from durable long-term memory. Short-term memory survives within a session; long-term memory (via configurable extraction strategies) persists across sessions in managed storage. If a session crashes, long-term memories are preserved.
Multi-Region. AgentCore is available in multiple regions (us-east-1, us-west-2, ap-southeast-2, eu-central-1). Cross-region DR requires deploying agents in a secondary region and routing at the application layer — the platform doesn't provide automatic cross-region failover for agent state.
Limitations. AgentCore sessions are ephemeral by design. If a microVM terminates unexpectedly, in-flight session state is lost unless you've persisted it to AgentCore Memory or an external store. The 8-hour session limit means workflows exceeding that duration need external state management (Step Functions, for example).
EKS: Build Your Own Resilience
Pod Resilience. Kubernetes provides pod restart policies, liveness/readiness probes, and PodDisruptionBudgets. For stateful agents, you use StatefulSets with persistent volumes. But you design the health check logic — what does "healthy" mean for an agent that's been reasoning for 45 minutes?
Checkpointing. Frameworks like LangGraph support PostgreSQL-backed checkpointing, allowing agents to resume from the last checkpoint after a pod restart. This is powerful for long-running workflows (multi-day approval gates, for example) but requires you to manage the checkpoint store, handle schema migrations, and test recovery paths.
Multi-AZ and Multi-Region. EKS supports multi-AZ node groups natively. For multi-region DR, you need to replicate the entire stack: EKS cluster, RDS (for checkpoints), ElastiCache (for session state), Secrets Manager entries, and container images. Tools like Velero can back up Kubernetes resources, but restoring a stateful agent mid-workflow is non-trivial.
Capacity Planning. You must forecast agent resource consumption — which is inherently unpredictable due to the stochastic nature of LLM reasoning loops. Over-provision and you waste money; under-provision and agents fail under load. Karpenter helps with node-level scaling, but right-sizing agent pods requires empirical tuning.
DR Comparison
DR Concern | AgentCore | EKS |
|---|---|---|
Session recovery | Ephemeral; rely on AgentCore Memory for durability | Checkpoint-resume via PG/Redis (you build it) |
Scaling failures | Serverless; no capacity planning | Requires HPA + node autoscaler tuning |
Long-running workflows (>8h) | Needs external orchestration (Step Functions) | Native with long-lived pods + checkpointing |
Multi-AZ | Managed by the platform | Multi-AZ node groups (you configure) |
Multi-Region failover | Deploy in secondary region; manual routing | Full stack replication (you build it) |
State backup | AgentCore Memory is managed | Velero + RDS snapshots + ElastiCache backups |
Pillar 4: Performance Efficiency
AgentCore
- Cold starts are a consideration. MicroVM provisioning adds latency on the first invocation of a new session. Subsequent invocations within the same session hit a warm environment.
- Large payloads up to 100 MB are supported natively — useful for agents processing documents, images, or datasets.
- Streaming is built-in for chat-style applications.
- You don't control the underlying compute — no GPU selection, no custom instance types, no CPU pinning.
EKS
- No cold starts for always-on pods. Pre-warmed agent pools eliminate latency for latency-sensitive workflows.
- GPU workloads are natively supported — attach GPU node groups for agents that run local inference.
- Custom resource profiles per agent type. Your analytics agent gets different CPU/memory than your orchestrator.
- You pay for idle capacity and must tune scaling parameters empirically.
Pillar 5: Cost Optimization
AgentCore
AgentCore's consumption-based pricing charges only for active CPU time and actual memory usage. During I/O waits (LLM calls, API calls), you don't pay for CPU. For a typical agent session where 70% of wall-clock time is I/O wait, this translates to roughly 70% CPU cost savings compared to always-on compute.
For bursty, periodic workloads (campaign workflows, batch processing, on-demand analysis), this model is compelling. Zero cost when idle.
EKS
EKS gives you predictable pricing with EC2 instances (on-demand, reserved, or Spot). You can right-size aggressively and use Spot instances for fault-tolerant agent workloads. For sustained, high-throughput agent deployments, reserved capacity on EKS can be cheaper than per-invocation pricing at scale.
The hidden cost is engineering time: building and maintaining the primitives that AgentCore provides out of the box (identity, memory, gateway, observability) represents months of engineering effort.
Pillar 6: Sustainability
AgentCore's serverless model inherently optimizes resource utilization — no idle compute, no over-provisioned nodes. EKS requires active right-sizing and bin-packing optimization to minimize waste. Karpenter helps, but achieving high utilization across heterogeneous agent workloads takes ongoing effort.
When to Choose What
Choose AgentCore when:
- You want to focus on agent logic, not infrastructure
- Your agents are framework-agnostic or you're willing to adapt
- Session isolation and agent identity are critical security requirements
- Workloads are bursty or unpredictable
- You want built-in memory, identity, and observability without building them
- Time-to-production matters more than runtime customization
Choose EKS when:
- You need full control over the runtime environment (GPUs, custom networking, sidecar patterns)
- Your agents run workflows exceeding 8 hours with complex checkpoint-resume semantics
- You have existing Kubernetes expertise and infrastructure
- You need to run non-agent workloads alongside agents on the same cluster
- Cost optimization at scale requires reserved capacity and Spot instances
- You need custom isolation models (Kata Containers, gVisor) beyond what AgentCore provides
Consider a hybrid approach:
- Run agent compute on AgentCore Runtime while using AgentCore Gateway to expose your existing EKS-hosted tools and APIs as agent-ready MCP endpoints
- Use AgentCore Identity for credential management even if agents run on EKS
- Use AgentCore Observability for agent-level tracing while keeping infrastructure metrics in your existing Prometheus/Grafana stack
Summary
AgentCore shifts the conversation from "how do I run agents" to "what should my agents do." It provides purpose-built primitives — session isolation, agent identity, memory, tool gateway, observability — that would take months to build on EKS. The tradeoff is less control over the runtime environment and a dependency on a newer, still-evolving platform.
EKS gives you the full power of Kubernetes: arbitrary compute, custom networking, unlimited session duration, and a mature ecosystem. The tradeoff is that every agent infrastructure primitive is your responsibility to build, secure, and operate.
For most teams starting new agent projects, AgentCore's primitives eliminate the undifferentiated heavy lifting that keeps agents stuck in proof-of-concept. For teams with deep Kubernetes expertise and complex runtime requirements, EKS remains a strong choice — especially when combined with AgentCore's managed services for identity, memory, and observability.
The best architecture might not be either/or. It might be both.
Sources:
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article