Verdict
If you are AWS-committed and your agents spend most of their wall-clock waiting on LLM responses, AgentCore is cheaper than its sticker rate suggests and is now the only forward path AWS offers — Bedrock Agents Classic is in maintenance mode and closes to new customers on July 30, 2026. Self-host on E2B or Modal when you need lower raw compute rates, multi-cloud portability, sessions longer than AgentCore's 8-hour cap, or full control of the sandbox image. Do the math on your actual CPU-active fraction, not on headline per-hour rates.
The headline rates partly favor self-hosting: AgentCore Runtime bills $0.0895 per vCPU-hour plus $0.00945 per GB-hour (aws.amazon.com/bedrock/agentcore/pricing), while E2B's published rates work out to ~$0.0504 per vCPU-hour plus ~$0.0162 per GiB-hour ($0.000014/vCPU-s and $0.0000045/GiB-s per e2b.dev/pricing) — about 44% cheaper per active vCPU-hour than AWS — though Modal's sandbox compute lists higher, at $0.00003942/core-second (~$0.14/core-hour) per agenticwire.news's cost comparison, offset by $30/month of free credits on its Starter plan. But the billing model flips the comparison for real agents: AWS's pricing page states AgentCore bills per-second on actual CPU consumption and that I/O wait and idle time are free when no background process runs — and agents typically spend the large majority of a session blocked on model inference. A 1 vCPU / 2GB agent-hour that is CPU-active only 15% of the time costs roughly $0.032 on AgentCore versus ~$0.083 on an E2B sandbox that bills wall-clock for the sandbox's lifetime. Layered on top is the strategic forcing function: AWS has placed Bedrock Agents Classic in maintenance mode, closing it to new customers from July 30, 2026, with AgentCore as the recommended migration target (per AWS's maintenance-mode notice as covered by AgentCore migration guides such as ecorpit.com's) — no migration deadline, but no new investment either.
Decision Table
| Criterion | Edge | Explanation |
|---|---|---|
| Raw compute rates per vCPU-hour | Self-hosted agent runtime (E2B, Modal, or your own sandbox fleet) Best edge | E2B wins on list price: it charges $0.000014 per vCPU-second (~$0.0504/vCPU-hour) and $0.0000045 per GiB-second (~$0.0162/GiB-hour) per e2b.dev/pricing, making AgentCore's $0.0895/vCPU-hour and $0.00945/GB-hour (aws.amazon.com/bedrock/agentcore/pricing) roughly 78% more expensive per active vCPU-hour. Note the trap in the other direction: Modal's sandbox compute is listed at $0.00003942/core-second (~$0.14/core-hour) per agenticwire.news — pricier per core-hour than AgentCore, mitigated by $30/month free credits on Starter. If your agent workloads are CPU-saturated — data processing, heavy tool execution — pick the self-host vendor by its actual rate sheet, and E2B's raw-rate gap is real money. |
| Billing model for idle-heavy agent sessions | AWS Bedrock AgentCore (managed agent runtime) Best edge | AWS's pricing page states AgentCore bills in per-second increments for actual CPU consumption only, with I/O wait and idle time free when no background process is running — and LLM-blocked waiting is most of a typical agent session's wall-clock. A 1 vCPU + 2GB session that is CPU-active 15% of the hour costs about $0.032 on AgentCore (0.15 × $0.0895 + 1.0 × 2 × $0.00945, since memory is charged through the session) versus ~$0.083/hour on E2B, which bills the sandbox's full running lifetime. For chat-style and long-polling agents, the effective AgentCore price undercuts the nominally cheaper sandboxes. |
| Session isolation and security model | AWS Bedrock AgentCore (managed agent runtime) Best edge | AgentCore provisions isolated sessions on ephemeral compute — AWS launch materials describe dedicated microVMs per session (docs.aws.amazon.com runtime-sessions guide) — with AgentCore Identity included at no extra charge when used through Runtime or Gateway, and $0.010 per 1,000 requests against non-AWS resources per the official pricing page. Reproducing per-session microVM isolation, credential brokering, and session-scoped storage on a self-hosted fleet is weeks of platform engineering that E2B/Modal only partially provide out of the box. |
| Session duration and runtime limits | Self-hosted agent runtime (E2B, Modal, or your own sandbox fleet) Best edge | AgentCore caps sessions at 8 hours maximum with a 15-minute default idle timeout (docs.aws.amazon.com AgentCore quotas and lifecycle-settings pages). Long-horizon agents — multi-day research runs, resumable batch jobs — must checkpoint and re-establish sessions around that ceiling. Self-hosted runtimes have no such cap: your sandbox or container lives as long as you pay for it, which is architecturally simpler for genuinely long-running work. |
| Vendor lock-in and portability | Self-hosted agent runtime (E2B, Modal, or your own sandbox fleet) Best edge | The Bedrock Agents Classic story is the cautionary tale playing out in real time: launched, then renamed 'Classic,' placed in maintenance mode, and closing to new customers on July 30, 2026 per AWS's maintenance-mode notice — with customers pointed at an Import-Agent migration path to AgentCore. Teams that built on the managed abstraction are migrating on AWS's schedule, not their own. A self-hosted runtime on E2B, Modal, or plain containers keeps the agent loop portable across clouds and immune to a single vendor's product strategy. |
| Operational burden and time to production | AWS Bedrock AgentCore (managed agent runtime) Best edge | AgentCore is consumption-billed with no minimums, no cluster to size, built-in session lifecycle, and IAM-native auth — an agent goes from code to isolated production sessions without a platform team. Self-hosting means owning autoscaling, sandbox pooling and warm-up, patching, egress controls, and observability. E2B's Pro plan alone is $150/month (per beam.cloud's and usagepricing.com's 2026 pricing breakdowns) before compute, and your own fleet costs engineer-hours that dwarf either bill at small scale. |
| Ecosystem integration for AWS-committed teams | AWS Bedrock AgentCore (managed agent runtime) Best edge | AgentCore's Gateway, Memory, Browser, and Code Interpreter tools bill on the same consumption meter (Browser and Code Interpreter at the same $0.0895/vCPU-hr + $0.00945/GB-hr rates per the official pricing page) and wire directly into IAM, CloudWatch, VPCs, and Bedrock model invocation. If your data plane, compliance posture, and model access already live in AWS, the integration surface you do not have to build is the dominant term in total cost. |
Choose AWS Bedrock AgentCore (managed agent runtime) if...
- AWS-committed teams mid-migration off Bedrock Agents Classic who want the shortest path to a supported managed runtime.
- Chat-style and tool-calling agents that idle on LLM responses most of the session — the CPU-consumption billing model prices exactly this shape of workload.
- Security-sensitive deployments that need per-session microVM isolation and IAM-native identity without building a sandbox platform.
- Small teams without platform engineers who need production-grade session lifecycle, observability, and scaling as a service.
Choose Self-hosted agent runtime (E2B, Modal, or your own sandbox fleet) if...
- CPU-saturated agent workloads (heavy data processing, compilation, large tool execution) where E2B's ~$0.0504 per vCPU-hour undercuts AWS's $0.0895 by roughly 44%.
- Long-horizon agents that need sessions beyond AgentCore's 8-hour cap without checkpoint/restore gymnastics.
- Multi-cloud or cloud-neutral products that cannot couple their execution layer to one vendor's roadmap — especially after the Agents Classic freeze.
- Teams needing custom sandbox images, GPUs in the loop, or kernel-level control that a managed runtime does not expose.
Decision Rules
- Measure your agents' CPU-active fraction first: below roughly 50% CPU-active, AgentCore's idle-free per-second billing beats E2B/Modal's lower list rates for the same session (at 15% active, ~$0.032 vs ~$0.083 per 1 vCPU/2GB agent-hour); above it, self-hosting's cheaper vCPU-hours win.
- If you are on Bedrock Agents Classic, plan the AgentCore migration now even though AWS states there is no deadline — the service closes to new customers on July 30, 2026, and maintenance mode means no new capabilities will land there.
- If any single agent session must run longer than 8 hours without checkpointing, AgentCore's hard session cap rules it out — self-host that workload.
- If multi-cloud portability is a requirement (or vendor-freeze risk is unacceptable after the Agents Classic precedent), keep the agent loop in portable containers and treat managed runtimes as swappable execution backends.
- If you have no platform team, take the managed runtime: reproducing per-session microVM isolation and credential brokering on your own fleet costs more in engineer-time than the rate difference saves at small scale.
Migration Notes
- Migrating off Bedrock Agents Classic: AWS documents an Import-Agent path into AgentCore (Node.js + AgentCore CLI or Python + boto3) — but treat it as a re-platform, not an in-place upgrade; action groups and orchestration logic map to AgentCore primitives, they do not transfer automatically.
- Moving from AgentCore to self-hosted: the 15-minute default idle timeout and 8-hour session cap are the behaviors your code has silently adapted to — audit for session-resume logic before assuming a long-lived container simplifies anything.
- Whichever direction you move, keep the agent loop (planning, tool dispatch, memory) in your own code and treat the runtime as an execution backend — that is what makes the next forced migration a config change instead of a rewrite.