AgentCore Runtime Instances Are GA: Design Persistent Agents Without Treating EC2 Like Serverless

An agent starts as a short API exchange, then the workflow changes. It pauses overnight for human approval, coordinates a reviewer and test runner, writes checkpoints to a shared workspace, or needs a graphics processing unit (GPU) for inference or rendering. The eight-hour stateless interaction no longer fits. A team may reach for persistent compute and still describe it as serverless, only to discover that session identifiers, Amazon Elastic Block Store (EBS) volumes, identity roles, network paths, patch-driven restarts, and deletion semantics determine whether the system is secure and recoverable.

Amazon Web Services (AWS) made AgentCore Runtime Instances generally available on August 6, 2026. Instances solve a real compute problem: Amazon Bedrock AgentCore provisions and operates Amazon Elastic Compute Cloud (EC2) managed instances inside the customer account, while providing longer sessions, hardware choice, and multi-agent co-location. The convenience does not transfer ownership of the data, virtual private cloud (VPC), Identity and Access Management (IAM) boundaries, operational evidence, or bill.

This guide treats the feature as a production substrate and produces a compute decision record, trust model, capacity-provider versioning pattern, application-owned session authorization design, lifecycle state machine, cost model, reversible migration plan, and signed operational evidence.

What General Availability Changes in the AgentCore Compute Model

General availability expands the supported operating choice without changing the ownership boundary. Under AWS documentation for Runtime Instances, AgentCore handles provisioning, operating-system and runtime patching, scaling, replacement, and teardown. The EC2 managed instance, network interfaces, EBS data, controls, and charges remain in the customer account. Treat this as delegated operations on customer-account infrastructure, not invisible compute without a resource lifecycle.

Approval still requires allowed VPCs, hardware, encryption, runtime association, managed-resource inventory, and cleanup evidence. For broader lifecycle context, the Refonte Learning guide to building AI agents in production is useful; this playbook narrows the problem to the persistent managed-EC2 substrate.

Responsibility model for a production Runtime Instances platform

Choose MicroVMs or Runtime Instances With a Workload Rubric

Start with the smallest operating surface that satisfies the workload. This architectural rubric is not an AWS benchmark: 5 is favorable and 1 represents a material constraint. Replace the scores with measured startup, compliance, and staffing data.

Scored compute comparison

Keep MicroVMs for Short, Elastic, API-Driven Sessions

Keep the default microVM compute when a request is short, bursty, externally stateful, and tolerant of a fresh execution environment. Typical examples are an interactive assistant, a tool-routing endpoint, or a batch-like unit that can checkpoint to a database or object store and restart from an idempotency key. A long queue does not itself justify an instance; split work into bounded jobs before buying persistent infrastructure.

MicroVMs are the safer default for mutually untrusted tenants because they avoid the deliberate shared-host model. Move only when duration, local reuse, trusted collaboration, architecture, or hardware is a measured blocker.

Use Instances for Persistent, Collaborative, or Specialized Compute

Use Amazon Bedrock AgentCore instances when the business process legitimately spans hours or days, when a large workspace must survive a stop, when trusted agents need the same filesystem, or when a supported GPU or AWS Inferentia2 accelerator is required. Maximum session lifetime is an infrastructure ceiling, not a completion guarantee: approval delays, capacity shortages, restarts, dependency outages, and business deadlines still need explicit handling.

Workload-class default and exception rule

Define the Trust Boundary Before Agents Share an Instance

The security model is intentionally counterintuitive. AWS states that co-resident agents are not isolated from one another: containers and directly deployed processes are not a security boundary on the shared instance, and the filesystem is shared. Any code on that instance may also read credentials available to it. The design review must therefore decide who may share a session before it discusses density or cost.

Treat the Session—not the Container—as the Isolation Unit

For Instances, the isolation unit is the combination of capacity provider and runtime session ID. That pair maps one-to-one to an EC2 managed instance. The same session ID under another capacity provider is a separate session, and separate containers inside one session do not create separate security domains. Use this mapping in threat models, log schemas, incident scopes, and deletion evidence.

A platform must distinguish process failure from trust failure. A crashed agent may restart within the same session. Suspected credential theft, a malicious dependency, or cross-agent data access requires a different response: stop new invocations, revoke runtime credentials, block egress at the controllable network layer, preserve approved evidence, and route new work to a clean provider and session. Restarting the same shared workspace does not restore trust.

Co-Locate Only Agents That Are Mutually Trusted

Mutual trust means more than common ownership. Co-resident agents should have compatible data classifications, change approval, dependency provenance, incident response, and credential sensitivity. A low-risk summarizer must not share an instance with a payment agent simply because both belong to one product team. A test agent with arbitrary code execution must not share with a production agent.

Trust-zone policy

•   Stop condition: an agent requests a broader role, mounts an unapproved volume, adds arbitrary code execution, or changes data classification without a new trust review.

•   Recovery condition: a clean provider/session is created, credentials are rotated, the workspace is rebuilt from trusted artifacts, and cross-agent read/write tests pass.

•   Rollback: remove the co-location route and return each runtime to separate sessions or the previous compute substrate.

Version Capacity Providers as Immutable Infrastructure Products

A capacity provider is the reusable infrastructure definition for operating system, allowed instance types, VPC and subnets, volumes, and the operator role AgentCore assumes. After creation, only its description is editable. Network, storage, key, architecture, and hardware changes require replacement. Treat each provider as a released infrastructure product with an owner, configuration hash, and retirement record.

AWS documentation verified on September 2, 2026 uses two terminal labels for a successfully created provider: the developer guide says ACTIVE, while the CreateCapacityProvider API reference returns READY. This documentation-surface divergence should not be translated by guesswork. Automation must consume values returned by the deployed SDK or API, record unknown values, and avoid hard-coding console terminology.

Replace Rather Than Mutate Network, Storage, and Instance Configuration

Recommended naming and promotion convention

API naming rule: letters, numbers, and underscores; keep full intent in tags.
cp_prod_use1_x86_t2_cpu_ebs_v03

Recommended tags:
Owner=agent-platform
Environment=prod
TrustZone=T2
ConfigurationHash=sha256:<canonical-config-hash>
Supersedes=cp_prod_use1_x86_t2_cpu_ebs_v02
CostCenter=ai-platform

Create separate development, staging, and production providers even when the configuration begins identical. Promotion should rebuild from a canonical configuration, compare hashes, validate IAM and network dependencies, create a disposable session, stop and resume it, and delete it before any production runtime is associated. A provider is not production-ready merely because its status is usable.

Provider dependency graph and deletion prerequisites

capacity provider v03
  -> agent runtime versions
       -> endpoints / aliases
       -> active or stopped sessions
            -> EC2 managed instance while running
            -> network interface
            -> per-session EBS volumes

Delete order: drain and delete sessions -> disassociate every runtime version
-> request provider deletion -> poll asynchronous status -> prove resources absent

The DeleteCapacityProvider API returns asynchronously and fails while runtime or runtime-version references remain. Provider deletion also destroys associated sessions and persistent storage. The change record therefore needs a data-disposition decision, dependency query, idempotent deletion token, and post-delete evidence. Roll back from v03 by routing new sessions to v02, not by editing v03.

Engineer Session Lifetime, Stop, Resume, Delete, and Storage Semantics

A persistent AI agent runtime needs an application state machine, because the business process and AWS resource lifecycle are not the same. On first invocation with a new runtimeSessionId, AgentCore provisions an instance and creates configured EBS volumes. A stopped session can later resume on a newly provisioned instance with those volumes reattached. Deleting the session removes the instance, network interface, and persistent volumes. The application must know which transition is reversible.

Application-owned lifecycle state machine (not an AWS status enum)

NEW -> PROVISIONING -> RUNNING -> IDLE
IDLE -> STOP_REQUESTED -> STOPPED
RUNNING -> MAX_LIFETIME_REACHED -> STOPPED
STOPPED + invoke same session ID -> REPROVISIONING -> RUNNING
ANY ACTIVE STATE -> DELETE_REQUESTED -> CLEANING -> DELETED
CLEANING -> CLEANUP_FAILED -> RETRY / ESCALATE -> DELETED

Before STOP: checkpoint, flush files, close databases, emit recovery marker.
Before DELETE: export required records, approve data disposition, revoke route.
After DELETE: prove instance, ENI, and EBS resources are absent.

AWS documents a 14-day maximum session lifetime for Instances and eight hours for microVMs. Treat either maximum as a forced stop, not a business-process completion guarantee. Because a resumed Instance session may use a newly patched machine image, test restart compatibility before promotion.

Use the documented StopRuntimeSession operation with an idempotency token and bounded retry for intentional stops. Before stopping, write a schema-versioned checkpoint and flush marker, then wait for stop completion. After resumption, verify the mount, checkpoint integrity, runtime version, machine architecture, and external leases before processing. Prove that a newer base image can read the old workspace and that an older artifact safely rejects a newer state schema.

Configured EBS volumes are per session and can be mounted by collaborating runtimes through AgentCore filesystem configurations. Treat them as recoverable working state, not as the authoritative customer record or semantic memory. The distinction is developed further in Refonte Learning’s guide to AI agent memory systems: a workspace surviving a stop does not automatically provide governed long-term memory, lineage, retention, or conflict resolution.

Design VPC, Subnet, Endpoint, Egress, DNS, and Regional Placement

Runtime Instances always use a VPC. AWS’s supported-Regions matrix, verified on September 2, 2026, listed nine Instance Regions: N. Virginia, Ohio, Oregon, Frankfurt, Ireland, Mumbai, Singapore, Sydney, and Tokyo. Broader AgentCore coverage is not evidence of Instances availability. Select a Region only after residency, dependency, hardware-capacity, support, and recovery checks pass.

Network decision record

The AWS AgentCore endpoints reference lists Region-specific control-plane and data-plane endpoints. Verify endpoint names and PrivateLink support at deployment rather than copying a generic diagram. A private subnet with a NAT gateway is not automatically safe from data loss; egress policy, DNS, and runtime credentials determine what the agent can reach.

•   Stop promotion when a required private dependency cannot resolve, a target Region lacks the chosen Instance feature or hardware, or network logs cannot be exported.

• Recover by creating a new provider with corrected subnet or VPC configuration, validating it with a disposable session, and moving only new sessions.

•   Do not mutate around the provider with one-off route or security-group changes that are absent from the versioned network record.

Separate Infrastructure, Instance-Profile, and Runtime Execution Roles

Runtime Instances introduce several identities with different blast radii. The capacity-provider operator or infrastructure role lets AgentCore provision and manage EC2 resources. The instance profile supports system log collection and does not authorize agent code. Each runtime execution role supplies the agent’s AWS permissions. Deployment and human roles should remain outside all three. Apply AWS IAM security best practices with temporary credentials, least privilege, permissions boundaries where appropriate, and explicit conditions for account, Region, VPC, subnet, instance family, and tagged resources.

IAM role matrix

AWS documents that any code on a shared instance can read available vended credentials. A narrow execution role reduces but does not eliminate co-resident risk, so trust-zone policy remains mandatory. Fetch secrets just in time, scope them to task and tenant, exclude them from environment dumps and persistent files, and rotate them after suspected workspace compromise.

Supply-chain controls matter at both deployment and runtime. The Refonte Learning analysis of CI/CD secret leakage from AI coding agents covers the broader pipeline risk; here the runtime-specific rule is stricter: a build role may publish an artifact but must not be baked into the image, copied to EBS, or reused as the agent execution identity. Promotion stops when credential scans, role-diff checks, or denied-action tests fail.

The Runtime Instances cleanup service-linked role exists so AgentCore can release managed resources even if the provider operator role is later changed or deleted. Do not treat that as proof that cleanup occurred. Record the deletion request and independently verify the tagged EC2, EBS, network, and billing inventory.

Bind Every Runtime Session to the Correct User or Tenant

Session authorization is an application responsibility in a shared-principal architecture. AgentCore authorizes an invocation against the runtime resource ARN and validates the runtimeSessionId format; it does not prove that the supplied session belongs to the end user represented by the backend. A client-controlled session ID can therefore become a cross-tenant routing vulnerability even when every request is authenticated.

Generate a cryptographically random, URL-safe session identifier server-side and store the raw value in a protected mapping; expose a separate opaque conversation handle to the client. The API documentation verified on September 2, 2026 is internally inconsistent: request fields allow 33–256 characters, while response headers describe 1–100. Until AWS reconciles the contract, use 33–100 characters and test the value against the deployed SDK and Region. Bind tenant, subject, runtime ARN, capacity-provider ID, data class, artifact version, authorization version, and lifecycle status in one transaction. Start the authoritative lookup from the authenticated subject, never from a client-supplied runtimeSessionId.

Prove Session-to-User Binding With Negative Authorization Tests

Server-side invocation pseudocode

def invoke_agent(auth_header, request):
    principal = verify_identity(auth_header)
    binding = db.lookup_active_binding(
        tenant_id=principal.tenant_id,
        subject_id=principal.subject_id,
        conversation_handle=request.conversation_handle,
    )
    if binding is None:
        return not_found()

    authorize(principal, binding.runtime_arn, request.action)
    assert binding.data_class <= principal.clearance
    assert binding.status in {"RUNNING", "STOPPED", "NEW"}

    return agentcore.invoke_agent_runtime(
        agentRuntimeArn=binding.runtime_arn,
        runtimeSessionId=secrets.read(binding.session_secret_ref),
        payload=canonicalize(request.payload),
    )

The invocation contract accepts the runtime ARN and runtimeSessionId, but the backend must source both from the validated binding. Log only a keyed hash or internal surrogate for the session ID in general application logs. Keep the raw value in a restricted store because possession may help route requests when a shared backend principal has runtime access.

Mandatory negative tests

Prefer distinct IAM principals per tenant or high-security tenant group where feasible; AWS identifies this as the strongest mitigation. Shared-principal systems require the mapping, negative tests, audit correlation, and incident response as production controls. Block promotion if any unauthorized test reaches AWS.

Promote Agent Artifacts and Dependencies Without Configuration Drift

Compute immutability is ineffective if artifacts float. Promote a container by immutable Amazon Elastic Container Registry (ECR) digest, or a direct-code package by versioned object and checksum. Record the runtime version, capacity-provider ARN and hash, execution-role policy hash, filesystem mount schema, model/tool contract, and state schema in a release manifest stored outside the session. Never install unpinned packages from the public internet during session startup.

Release manifest minimum fields

Tool integration should remain an explicit contract. Refonte Learning’s overview of no-code AI agents and MCP addresses the broader connector model; on Runtime Instances, every server, plugin, binary, and credential provider entering the trust zone must be pinned, authorized, observable, and removable. A shared filesystem can turn one compromised dependency into a multi-agent incident.

•   Build once: produce a signed digest and dependency inventory in a controlled pipeline.

•   Promote by reference: create a runtime version and endpoint/alias that points to the approved artifact and provider; do not rebuild per environment.

•   Test restart: stop a canary, resume it on a newly provisioned instance, and prove state compatibility and dependency availability.

•   Rollback: route new sessions to the previous endpoint and keep state schemas backward-compatible; never overwrite the old provider or artifact.

Plan Capacity, GPUs, Startup Behavior, and Scaling Failure

One session maps to one managed EC2 instance, so concurrent sessions drive instance count. Combine AgentCore limits with EC2-family, EBS, network-interface, Auto Scaling, Availability Zone, and first-invocation constraints. The AgentCore quota table verified on September 2, 2026 lists 5,000 active sessions in us-east-1 and us-west-2 and 2,500 in other Regions; 25 new sessions per second; 1,000 non-adjustable capacity providers; and 20 agents per provider session. Verify applied quotas per account and Region because defaults do not reserve capacity.

AWS documentation verified on September 2, 2026 lists NVIDIA g4dn, g5, g6, g6e, gr6, g6f, gr6f, and g7e plus Inferentia2 inf2 as supported accelerator families. An unsupported accelerator causes CreateCapacityProvider to fail with ValidationException. Support does not guarantee availability in every Availability Zone or account. Run a disposable capacity probe with the exact provider, architecture, volume profile, and subnet set before production approval, and repeat it after major demand or Region changes.

Scaling and failure response matrix

Model demand as sessions, not requests. Track new-session rate, active running sessions, stopped sessions retaining EBS, agents per shared session, requested instance family, and subnet/AZ. Warm reuse is valuable only when routing consistently returns to the correct session. A random session ID per request converts every call into a cold capacity event and destroys both state and economics.

required_instance_headroom = peak_concurrent_sessions * (1 + failure_margin)
new_session_tps_headroom = peak_new_sessions_per_second / applied_quota
subnet_ip_headroom = free_private_ips - planned_peak_session_enis
volume_headroom = ebs_gib_quota - existing_gib - planned_session_volumes

Build Observability, Audit Trails, and Session-Level Incident Evidence

Agent success metrics are not infrastructure evidence. AgentCore Observability provides OpenTelemetry-compatible telemetry and CloudWatch dashboards for session count, latency, duration, token usage, and errors. Join that data with application logs, CloudTrail, VPC Flow Logs, DNS logs, EBS/KMS events, deployment records, and managed-EC2 inventory. Correlation must survive stop and resume when the backing instance ID changes.

Required correlation fields

Define separate indicators for cold provisioning, warm invocation, stop, resume, and deletion. Alert on authorization anomalies, provisioning and EBS errors, maximum-lifetime risk, idle hours, old stopped volumes, cleanup failure, and drift. Never merge cold and warm latency into one average.

Session incident evidence bundle

•   Authenticated subject and tenant surrogate; binding record and authorization-policy version.

•   Runtime ARN/version, endpoint, artifact digest, provider configuration hash, execution-role ARN, and trust zone.

•   Trace, CloudTrail invocation/stop events, VPC/DNS flows, tool decisions, checkpoint marker, and relevant KMS/EBS events.

•   Managed instance, ENI, and volume inventory before and after containment; note any replacement at resume.

•   Timeline, customer impact, data disposition, credential rotation, cleanup proof, and rollback decision.

Model Compute, Management, Storage, Network, and Idle Cost

Instance economics differ from microVM consumption pricing. The AgentCore pricing page, verified on September 2, 2026, states that Runtime Instances incur the underlying EC2 charge plus a management fee calculated from the public On-Demand price: 12 percent generally and 7.8 percent for listed G-series GPU families, including gr6. Savings Plans and Reserved Instances may reduce the EC2 portion, not the management fee. Stopped EBS, network transfer, and CloudWatch remain separate charges.

Monthly cost formula

C_total = sum_over_running_sessions[
    running_hours (effective_EC2_rate
    + public_On_Demand_rate management_percentage)
] + C_ebs_capacity + C_ebs_iops_throughput
  + C_snapshot_or_external_backup
  + C_data_transfer + C_nat_or_endpoint_processing
  + C_cloudwatch_logs_metrics_traces
  + C_model_tool_memory_services
  + C_parallel_migration_capacity

C_idle_attributed = idle_running_hours
    (effective_EC2_rate + public_On_Demand_rate management_percentage)

C_gpu_premium = selected_GPU_family_cost - approved_CPU_baseline_cost

Treat idle-running cost and GPU premium as attribution views, not additional line items: the EC2 rate already includes the selected accelerator, and running EC2 plus the management fee already includes idle time. Add snapshot cost only when the recovery design creates snapshots or exports state. AgentCore session deletion removes persistent volumes; it is not a backup.

Cost driver, metric, and control

This complements broader agentic AI cost governance without repeating token-budget guidance. The runtime-specific unit is a session-hour plus retained storage, not a request or token. Reconcile application bindings, AgentCore sessions, managed EC2 resources, EBS volumes, and Cost and Usage Report dimensions daily. Hidden managed resources remain billable, so console visibility is not a cost control.

For human-in-the-loop work, stop after a durable checkpoint instead of running an instance through an approval delay. Resume with the same session ID, test the reattached volume, and enforce a maximum stopped-retention age. The business owner approves deletion when the workspace is the only remaining copy; FinOps does not make that data decision alone.

Migrate With Parallel Runtimes, Canary Sessions, and Reversible Cutover

Compute type cannot change on an existing runtime, so migration requires a parallel runtime. Preserve the application contract, but handle identity and state explicitly: the same session text under different providers identifies different sessions, and microVM local state does not become EBS state automatically.

Reversible migration sequence

1.         Inventory and classify. Measure duration, workspace size, cold sensitivity, tool/network dependencies, execution roles, tenant model, and failure recovery. Exclude workloads with no hard Instance requirement.

2.         Build the target. Create a versioned provider, parallel runtime, release manifest, session-binding namespace, observability, quotas, and cost tags.

3.         Externalize or export state. Define a schema-versioned checkpoint from the source. Never copy an opaque local directory and assume compatibility.

4.         Shadow without side effects. Replay sanitized inputs or duplicate read-only work; compare outputs, latency classes, tool decisions, and cost.

5.         Canary new sessions. Route a small, named cohort only at session creation. Keep each session on one compute type for its lifetime.

6.         Expand by gates. Increase cohorts only after security, lifecycle, restart, capacity, cost, and deletion evidence passes.

7.         Cut over new work. Leave old sessions to finish or export them under a documented deadline; do not strand active approvals.

8.         Retire after rollback window. Delete old resources only after state disposition, incident review, and cost reconciliation.

Canary acceptance and rollback matrix

Rollback routes new sessions to the previous runtime endpoint. Existing Instance sessions finish, become read-only for export, or stop under the incident decision; never create a second active writer for the same business process. Keep state readers compatible with the previous schema until the rollback window closes. Migration deliberately duplicates capacity, so its expiration date belongs in the change plan and cost alert.

Run the Platform With Deletion Proof, Ownership, and a 60-Day Plan

Inventory business owner, tenant model, trust zone, runtime/version, provider, Region/VPC, role, state class, session policy, cost center, support group, and retirement date. This narrows the broader discipline in Refonte Learning’s guide to AI agent sprawl governance to the resources that can retain customer-account compute and storage after an agent stops.

Deletion proof runbook

•   Freeze creation. Disable the route that can create new sessions on the retiring runtime/provider and record the freeze time.

•   Enumerate dependencies. List runtime versions, endpoints, active and stopped session bindings, managed instances, network interfaces, and EBS volumes associated with the provider.

•   Drain and disposition. Complete, checkpoint/export, or formally abandon every business process; obtain data-owner approval for destructive deletion.

•   Stop, then delete sessions. Use idempotent operations and poll; confirm no route can recreate a deleted session from a stale binding.

•   Verify absence. Check managed EC2 inventory, ENIs, EBS volumes, tagged launch/Auto Scaling/EventBridge resources, CloudTrail, and delayed billing data.

•   Disassociate and delete provider. Remove every runtime and runtime-version reference, request asynchronous provider deletion, and poll the API’s returned status.

•   Close with evidence. Attach resource queries, timestamps, approvers, exceptions, support cases, and final cost reconciliation to the retirement record.

The EC2 managed-instances guide identifies these resources through Managed=true, with the provider shown in the console’s Operator field or the CLI’s Principal field. Managed resources may be hidden from ordinary views while remaining operational and billable. Include those fields and capacity-provider tags in reconciliation. An asynchronous API response begins deletion evidence; it does not complete it.

Sixty-day rollout

Signed production-readiness checklist

Use Runtime Instances only when persistence, mutually trusted collaboration, specialized hardware, architecture choice, or account-level controls justify the added lifecycle and cost surface. They are not a universal microVM upgrade: managed operations do not erase EC2, EBS, IAM, networking, or tenant-routing ownership. Default to the least persistent safe compute and require evidence for every added responsibility.

Non-negotiable controls are mutually trusted co-tenants, application-owned session binding, separated roles, versioned providers, pre-stop checkpoints, restart compatibility, idle and volume cost controls, shortage and cleanup drills, parallel migration, and a tested rollback until old sessions and data are retired.

Teams strengthening these foundations can review the Refonte Learning Agentic AI Engineer Program. Its program page lists a three-month period, 12–14 hours per week, project-based practice, LangChain, LangGraph, AutoGen, the Claude API, and competencies in agent architecture, orchestration, retrieval-augmented generation and memory, evaluation, observability, deployment, and safety. It states that successful participants receive a Training Certificate and a Certificate of Internship. The page does not name AgentCore, EC2 capacity providers, EBS, VPC design, or GPU families, so this connection does not imply vendor-specific Runtime Instances training.