AgentCore Runtime Instances have been released!

Introduction

Hello, I'm Kamino from the Consulting Department, currently practicing driving.

On August 7, 2026, Instances, a new compute type for Amazon Bedrock AgentCore Runtime, became generally available!

https://aws.amazon.com/jp/about-aws/whats-new/2026/08/aws-bedrock-agentcore-runtime-instances-generally-available/

This is a compute type that runs agents on EC2 instances within your own AWS account, with AgentCore handling provisioning and patching.
It feels similar to Lambda's Managed Instance feature.

When I first read the announcement, my immediate thought was: when would you actually use this?
AgentCore Runtime originally runs agents in serverless microVMs, and for agents called via API that complete processing within a few minutes, that should be sufficient. Persistent storage and shared file systems are also available with microVMs. With Managed session storage (Preview), you can retain files across stop/resume cycles, and by mounting EFS or S3 Files, multiple agents can share the same data.

https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-filesystem-configurations.html

So, summarizing what's unique to Instances from the documentation:

• Multiple Runtimes can be placed on the same EC2 instance
  • File sharing itself is also possible with microVM + EFS etc. Only Instances allows co-location while directly sharing the same machine's local disk
• Session compute can keep running for up to 14 days (microVM is 8 hours)
  • 14 days is incredible...!!!! Used for long-running processes...???
• GPU instances can be used. Drivers are automatically configured by AgentCore
• Since EC2 and EBS launch within your own AWS account, RIs/SPs can be applied

This time, I'll actually run and verify three things: co-location on the same instance, suspend/resume with in-account EBS, and direct communication (A2A) between co-located agents. These are all items where you might think "can't you do something similar with microVMs?", so I'll verify them while being mindful of what's different.

Prerequisites

The verification environment is as follows.

Supported regions are US East (N. Virginia, Ohio), US West (Oregon), Asia Pacific (Mumbai, Singapore, Sydney, Tokyo), and Europe (Frankfurt, Ireland). The Tokyo region is also supported from the start.

Pricing works on a model where EC2 instances and EBS are billed directly to your account, plus AgentCore management fees on top. Savings Plans, RIs, and ODCRs apply only to the EC2 portion, and management fees are calculated based on public on-demand pricing. Also note that EBS charges continue even while a session is stopped.

https://aws.amazon.com/bedrock/agentcore/pricing/

How Instances Works

The concept is a bit complex, so I've drawn a diagram of the overall verification environment I'll be building.

A Capacity Provider is a reusable template that holds the EC2 infrastructure definition (OS, instance type, VPC, EBS volumes). This is what sits in the center of the diagram, and it can be referenced by multiple Agent Runtimes.

An Agent Runtime is the definition of the agent itself to run. When you attach a Capacity Provider during creation, the compute type becomes Instances. In the diagram, I'm creating two: writer and reviewer.

A Session is the unit per runtimeSessionId specified at invocation time, and on the first call, one EC2 instance per session is provisioned within your account. As shown in steps ①② in the diagram, calling two Runtimes with the same session ID causes both agents to co-locate on the same instance, and as shown in ③④, files can be passed between them via a shared EBS volume.

https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-instances-how-it-works.html

Compared to microVMs, the differences are as follows.

It's interesting that x86_64 is also available. It might not be the reason you choose it — "because x86_64 is available...!" — but I did think it makes sense since it's EC2. Results from actually running it on x86_64 are included in the appendix.

Setup

I'll build the configuration shown in the diagram. The agents are: writer, which composes a haiku using Bedrock and writes it to the shared volume, and reviewer, which reads it and provides a critique. The concept is a minimal pipeline configuration, like code generation and code review, where an artifact file is passed between stages.

Creating IAM Roles

With Instances, in addition to the regular execution role, two additional roles are required.

When creating via the console, default roles are automatically created, but since I'm proceeding with CLI, I created them myself. I hit a snag here. When I created the Capacity Provider with only EC2 permissions and PassRole on the infrastructure role, it resulted in CREATE_FAILED with the following error.

EventBridge managed rule creation failed. User: arn:aws:sts::123456789012:assumed-role/agentcore-cp-operator-role/AgentCore is not authorized to perform: events:PutRule on resource: arn:aws:events:us-east-1:123456789012:rule/agentcore-lifecycle-events-123456789012

It turns out AgentCore creates a managed EventBridge rule to monitor instance lifecycle events, so EventBridge permissions are also required on the infrastructure role. The final role definitions are in the collapsible section below.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "bedrock-agentcore.amazonaws.com"},
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {"aws:SourceAccount": "123456789012"},
      "ArnLike": {"aws:SourceArn": "arn:aws:bedrock-agentcore:us-east-1:123456789012:*"}
    }
  }]
}

aws iam create-role --role-name agentcore-cp-operator-role \
  --assume-role-policy-document file://trust-agentcore.json
aws iam attach-role-policy --role-name agentcore-cp-operator-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2FullAccess
aws iam put-role-policy --role-name agentcore-cp-operator-role \
  --policy-name operator-extra --policy-document file://operator-extra.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["iam:PassRole", "iam:GetInstanceProfile", "iam:CreateServiceLinkedRole"],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "events:PutRule", "events:PutTargets", "events:RemoveTargets",
        "events:DeleteRule", "events:DescribeRule", "events:TagResource",
        "events:ListTargetsByRule"
      ],
      "Resource": "arn:aws:events:us-east-1:123456789012:rule/agentcore-*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "ec2.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}

aws iam create-role --role-name agentcore-cp-instance-role \
  --assume-role-policy-document file://trust-ec2.json
aws iam attach-role-policy --role-name agentcore-cp-instance-role \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
aws iam attach-role-policy --role-name agentcore-cp-instance-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws iam create-instance-profile --instance-profile-name agentcore-cp-instance-profile
aws iam add-role-to-instance-profile \
  --instance-profile-name agentcore-cp-instance-profile \
  --role-name agentcore-cp-instance-role

Implementing and Deploying Agents

The way agents are written is the same as regular AgentCore Runtime — you prepare a handler with @app.entrypoint.

@app.entrypoint
def handler(event, context):
    haiku = compose_haiku(event.get("theme", "cloud"))  # Generate haiku with Bedrock

    # Write to shared volume (read by reviewer in the same session)
    session_dir = SHARED_DIR / context.session_id  # SHARED_DIR = /mnt/shared
    session_dir.mkdir(parents=True, exist_ok=True)
    (session_dir / "haiku.txt").write_text(haiku, encoding="utf-8")

    return {
        "agent": "writer",
        "haiku": haiku,
        "hostname": socket.gethostname(),   # For verifying same instance
        "arch": platform.machine(),          # For verifying CPU architecture
    }

/mnt/shared is the mount path of the persistent EBS volume defined in the Capacity Provider. The reviewer simply reads this file and returns a critique — no inter-agent communication logic is written. For verification purposes, the hostname of which host it ran on and the CPU architecture arch are also returned.

"""Writer agent: generates artifact and writes it to shared volume"""
import platform
import socket
from pathlib import Path

import boto3
from bedrock_agentcore.runtime import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

SHARED_DIR = Path("/mnt/shared")
MODEL_ID = "us.anthropic.claude-haiku-4-5-20251001-v1:0"

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

@app.entrypoint
def handler(event, context):
    theme = event.get("theme", "cloud")
    session_id = context.session_id

    # Generate artifact (haiku) with Bedrock
    response = bedrock.converse(
        modelId=MODEL_ID,
        messages=[
            {
                "role": "user",
                "content": [
                    {"text": f"Please compose one haiku on the theme of \"{theme}\". Output only the haiku."}
                ],
            }
        ],
    )
    haiku = response["output"]["message"]["content"][0]["text"]

    # Write to shared volume (read by reviewer in the same session)
    session_dir = SHARED_DIR / session_id
    session_dir.mkdir(parents=True, exist_ok=True)
    (session_dir / "haiku.txt").write_text(haiku, encoding="utf-8")

    return {
        "agent": "writer",
        "haiku": haiku,
        "hostname": socket.gethostname(),
        "arch": platform.machine(),
        "wrote_to": str(session_dir / "haiku.txt"),
    }

if __name__ == "__main__":
    app.run()

"""Reviewer agent: reads artifact from shared volume and reviews it"""
import platform
import socket
from pathlib import Path

import boto3
from bedrock_agentcore.runtime import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

SHARED_DIR = Path("/mnt/shared")
MODEL_ID = "us.anthropic.claude-haiku-4-5-20251001-v1:0"

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

@app.entrypoint
def handler(event, context):
    session_id = context.session_id
    haiku_path = SHARED_DIR / session_id / "haiku.txt"

    if not haiku_path.exists():
        return {
            "agent": "reviewer",
            "error": f"{haiku_path} not found. Please call writer first.",
            "hostname": socket.gethostname(),
        }

    # Read artifact written by writer from shared volume
    haiku = haiku_path.read_text(encoding="utf-8")

    response = bedrock.converse(
        modelId=MODEL_ID,
        messages=[
            {
                "role": "user",
                "content": [
                    {"text": f"Please critique the following haiku from the perspective of a haiku poet. Within 3 sentences.\n\n{haiku}"}
                ],
            }
        ],
    )
    review = response["output"]["message"]["content"][0]["text"]

    return {
        "agent": "reviewer",
        "haiku_read_from_shared_volume": haiku,
        "review": review,
        "hostname": socket.gethostname(),
        "arch": platform.machine(),
    }

if __name__ == "__main__":
    app.run()

The project is set up with uv. The only two dependencies are bedrock-agentcore and boto3.

uv init agentcore-instances-demo --python 3.13
cd agentcore-instances-demo
uv add bedrock-agentcore boto3

I went with S3 source (zip) for deployment. Since it's an ARM64 instance, I collect aarch64 dependencies with uv, package them, and upload to S3.

uv pip install \
  --python-platform aarch64-manylinux2014 \
  --python-version 3.13 \
  --target build/deps \
  --only-binary=:all: \
  bedrock-agentcore boto3

cd build/deps && zip -qr ../writer.zip . && cd ../..
cd agents/writer && zip -q ../../build/writer.zip main.py && cd ../..

aws s3 cp build/writer.zip s3://bedrock-agentcore-code-123456789012-us-east-1/writer/deployment_package.zip

Creating the Capacity Provider and Agent Runtimes

Create the Capacity Provider.

response = client.create_capacity_provider(
    name="haiku_demo_cp",
    permissionsConfiguration={"capacityProviderOperatorRoleArn": OPERATOR_ROLE_ARN},
    computeConfiguration={
        "ec2Configuration": {
            "launchTemplateSource": {
                "launchParameters": {
                    "operatingSystem": "LINUX_ARM64",
                    "instanceRequirements": {"allowedInstanceTypes": ["m7g.large"]},
                    "instanceProfileArn": INSTANCE_PROFILE_ARN,
                }
            },
            "vpcConfiguration": {"subnets": [SUBNET_ID], "securityGroups": [SG_ID]},
            "volumes": [{"ebsConfiguration": {"name": "shared", "sizeGiB": 10, "volumeType": "gp3"}}],
        }
    },
)

The parameters are configured as follows.

It becomes READY in about 1–2 minutes, and then you create 2 Runtimes referencing it.

for name in ["writer", "reviewer"]:
    client.create_agent_runtime(
        agentRuntimeName=f"haiku_{name}",
        roleArn=EXEC_ROLE_ARN,
        agentRuntimeArtifact={
            "codeConfiguration": {
                "code": {"s3": {"bucket": BUCKET, "prefix": f"{name}/deployment_package.zip"}},
                "runtime": "PYTHON_3_13",
                "entryPoint": ["main.py"],
            }
        },
        capacityProviderConfiguration={"capacityProviderArn": CP_ARN},
        filesystemConfigurations=[
            {"capacityProviderVolume": {"volumeName": "shared", "mountPath": "/mnt/shared"}}
        ],
    )

Passing the ARN in capacityProviderConfiguration sets the compute type to Instances (cannot be changed after creation). The filesystemConfigurations mounts the shared volume at /mnt/shared (mount paths are limited to one level directly under /mnt). It becomes READY in tens of seconds, and the setup is complete.

Verification 1: Multi-Agent Collaboration on the Same Instance

I'll actually run steps ①–④ from the diagram. writer and reviewer are called with the same runtimeSessionId (33 or more characters). Since one EC2 instance corresponds to each session ID, calling with the same ID places both agents on the same instance, while using different IDs splits them onto separate instances where the shared volume contents are not visible to each other.

import json

import boto3

client = boto3.client("bedrock-agentcore", region_name="us-east-1")

# Session ID of 33 or more characters. Reusing the same ID runs on the same EC2 instance
session_id = "haiku-collab-session-2026-08-07-demo-001"

response = client.invoke_agent_runtime(
    agentRuntimeArn=WRITER_ARN,
    runtimeSessionId=session_id,
    payload=json.dumps({"theme": "Summer EC2 instance"}).encode(),
    qualifier="DEFAULT",
)
print(json.loads(response["response"].read()))

response = client.invoke_agent_runtime(
    agentRuntimeArn=REVIEWER_ARN,
    runtimeSessionId=session_id,
    payload=json.dumps({}).encode(),
    qualifier="DEFAULT",
)
print(json.loads(response["response"].read()))

uv run python scripts/03_invoke_agents.py

{
  "agent": "writer",
  "haiku": "クラウド冷え\nワーカー立ちて\n夏涼し",
  "hostname": "ip-172-31-3-249.ec2.internal",
  "arch": "aarch64",
  "wrote_to": "/mnt/shared/haiku-collab-session-2026-08-07-demo-001/haiku.txt"
}

{
  "agent": "reviewer",
  "haiku_read_from_shared_volume": "クラウド冷え\nワーカー立ちて\n夏涼し",
  "review": "This haiku is an ambitious attempt combining the modern words 'cloud' and 'worker' with the seasonal word 'summer cool', but the coined expressions feel abrupt and lack the traditional resonance of haiku. (abbreviated)",
  "hostname": "ip-172-31-3-249.ec2.internal",
  "arch": "aarch64"
}

The results are summarized in these two JSONs. Both hostnames are the same ip-172-31-3-249, confirming that the two agents deployed as separate Runtimes are co-located on the same EC2 instance. The reviewer was able to read the file written by the writer directly via the shared volume. The first writer call took 68 seconds due to EC2 provisioning, while the second reviewer call reused the same instance and completed in 8.5 seconds.

To be clear, file sharing itself can also be achieved with microVM + EFS or S3 Files. The difference with Instances is that the EBS attached to the same instance can be shared as a local filesystem rather than over a network. For pipelines with heavy intermediate artifact read/write operations like builds or data transformation, there could be I/O performance differences (though I didn't measure this time...).

https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-instances-security.html

How the Instance Appears in the EC2 Console

This instance can also be viewed from the EC2 side. However, it's treated as an EC2 managed instance and won't appear in the list by default — an account settings change is required.

aws ec2 modify-managed-resource-visibility --default-visibility visible

|  Id       |  i-0cb7e904f61796067              |
|  Ip       |  172.31.3.249                     |
|  Operator |  bedrock-agentcore.amazonaws.com  |
|  State    |  running                          |
|  Type     |  m7g.large                        |

The Operator field shows it's an AgentCore-managed instance. EBS had a root volume of 16 GiB and a shared volume of 10 GiB attached. Since it's an instance running in your own AWS account, this confirms why the EC2 portion is eligible for Savings Plans.

Verification 2: Suspending and Resuming Sessions

Next, I'll verify whether processing can be paused mid-way to reduce costs and then resumed from the same state later. According to the spec, when all Runtimes in a session stop, the EC2 instance also stops, but the EBS volume is retained, and re-invoking with the same session ID re-attaches it to a new instance.

I stopped the reviewer Runtime with StopRuntimeSession, confirmed that the EC2 instance became stopped, and then called it again with the same session ID.

aws bedrock-agentcore stop-runtime-session \
  --agent-runtime-arn arn:aws:bedrock-agentcore:us-east-1:123456789012:runtime/haiku_reviewer-XAGNbiCcJJ \
  --runtime-session-id haiku-collab-session-2026-08-07-demo-001

response = client.invoke_agent_runtime(
    agentRuntimeArn=REVIEWER_ARN,
    runtimeSessionId="haiku-collab-session-2026-08-07-demo-001",
    payload=json.dumps({}).encode(),
    qualifier="DEFAULT",
)

haiku: クラウド冷え / ワーカー立ちて / 夏涼し
hostname: ip-172-31-15-99.ec2.internal

The data written by the writer during the first run was read successfully. As shown by the hostname changing from the previous ip-172-31-3-249, a new instance started up and the EBS was re-attached. Recovery takes about 107 seconds, so using this to hold multi-day batches or approval-waiting workflows without paying compute costs during the wait seems practical.

Retaining files across suspend/resume is also possible with microVM's Managed session storage (Preview), but that resets if there's no invocation for 14 days, and also gets cleared on Runtime version updates. The difference is that Instances' EBS remains under your own management until the session is deleted.

Verification 3: Direct Communication Between Agents and A2A

Finally, I'll investigate whether, if agents can co-locate, A2A-style inter-agent communication can also be completed within a single machine.

Direct Socket Connection Is Not Possible

I prepared an agent (pingserver) that starts an HTTP server on port 9000 in the background, and another agent (pingclient) that co-locates with it using the same session ID and tries to connect to it. The invocation method is the same format as Verification 1.

session_id = "a2a-demo-session-2026-08-07-test-00001"
for arn in [PINGSERVER_ARN, PINGCLIENT_ARN]:
    response = client.invoke_agent_runtime(
        agentRuntimeArn=arn,
        runtimeSessionId=session_id,
        payload=json.dumps({}).encode(),
        qualifier="DEFAULT",
    )
    print(json.loads(response["response"].read()))

Here are the results.

{
  "agent": "pingclient",
  "hostname": "ip-172-31-5-39.ec2.internal",
  "listening_ports_visible": [8080],
  "via_localhost": {"ok": false, "error": "URLError: <urlopen error [Errno 111] Connection refused>"},
  "via_private_ip": {"ok": false, "error": "URLError: <urlopen error [Errno 111] Connection refused>"}
}

The server side also returns the same hostname, confirming co-location, but both localhost and private IP returned Connection refused. The server itself succeeded in self-connecting, and the only LISTEN port visible from the client was its own 8080.

In other words, in this verification environment, even though they're co-located, each agent's network namespace appears to be isolated, and direct socket connections are not possible. The documentation's statement about "no boundary between co-located agents" seems to refer to file systems and credentials, not networking — the networking appears to be designed so they can't see each other.

Invoking as an A2A Protocol Runtime

Meanwhile, AgentCore Runtime's serverProtocol includes A2A, which can also be specified in Instances. I deployed and invoked an A2A agent that composes haiku based on a given theme (implemented to receive JSON-RPC 2.0 at 0.0.0.0:9000).

client.create_agent_runtime(
    agentRuntimeName="a2a_haiku_poet",
    protocolConfiguration={"serverProtocol": "A2A"},
    capacityProviderConfiguration={"capacityProviderArn": CP_ARN},
    ...
)

Since InvokeAgentRuntime passes the A2A payload through transparently, you assemble a JSON-RPC 2.0 message and pass it directly.

payload = {
    "jsonrpc": "2.0",
    "id": "req-001",
    "method": "message/send",
    "params": {
        "message": {
            "role": "user",
            "parts": [{"kind": "text", "text": "秋のデータセンター"}],
            "messageId": "msg-001",
        }
    },
}
response = client.invoke_agent_runtime(
    agentRuntimeArn=POET_ARN,
    runtimeSessionId="a2a-jsonrpc-session-2026-08-07-poc-0002",
    payload=json.dumps(payload).encode(),
    qualifier="DEFAULT",
)

{
  "jsonrpc": "2.0",
  "id": "req-001",
  "result": {
    "artifacts": [
      {
        "name": "haiku",
        "parts": [{"kind": "text", "text": "秋風吹く　サーバー室より　熱気立つ"}]
      }
    ]
  }
}

Execution is performed by specifying the ARN directly.

Calling an Agent from Another Agent via A2A

I tested a configuration where a client agent makes an A2A call to the haiku agent using the same session ID as itself. The execution role on the client side has bedrock-agentcore:InvokeAgentRuntime added, scoped to the destination Runtime.

@app.entrypoint
def handler(event, context):
    payload = {
        "jsonrpc": "2.0",
        "id": str(uuid.uuid4()),
        "method": "message/send",
        "params": {"message": {"role": "user",
                               "parts": [{"kind": "text", "text": event.get("theme")}],
                               "messageId": str(uuid.uuid4())}},
    }
    response = agentcore.invoke_agent_runtime(
        agentRuntimeArn=POET_ARN,
        runtimeSessionId=context.session_id,  # Same session ID as self → co-located on the same instance
        payload=json.dumps(payload).encode(),
        qualifier="DEFAULT",
    )
    ...

{
  "agent": "a2aclient",
  "client_hostname": "ip-172-31-3-93.ec2.internal",
  "poet_hostname": "ip-172-31-3-93.ec2.internal",
  "haiku": "夜更けまで　データ流れて　朝を待つ"
}

A2A communication was successfully established between two agents co-located on the same instance...!

However, this does not mean packets are contained entirely within a single machine — the route actually goes through the AgentCore endpoint and back. This makes sense if you consider it a design that centrally routes SigV4 authentication and session management through the service side, but since A2A communication also passes through the AgentCore data plane, I don't think co-locating agents alone reduces communication latency.

Cleanup

Once verification is complete, delete the session, Runtime, and Capacity Provider in that order to prevent ongoing EC2 and EBS charges.

# 1. Delete session (releases EC2, ENI, and EBS together)
data.delete_capacity_provider_session(capacityProviderId=CP_ID, sessionId=SESSION_ID)

# 2. Delete Runtime
for rid in RUNTIME_IDS:
    control.delete_agent_runtime(agentRuntimeId=rid)

# 3. Delete Capacity Provider after waiting for Runtime deletion to complete
control.delete_capacity_provider(capacityProviderId=CP_ID)

A Capacity Provider cannot be deleted while it is referenced by a Runtime, resulting in a ValidationException. Also, deleting a Capacity Provider will delete all sessions and persistent storage beneath it, so be careful if there is data you want to keep.

Supplement: Running on LINUX_X86_64 as Well

As noted in the comparison table, unlike microVMs, Instances also supports x86_64. Curious whether it would actually work, I also ran the writer agent on a Capacity Provider with operatingSystem set to LINUX_X86_64 and instance type m7i.large.

The only difference from the ARM64 version built during setup is just two lines in the Capacity Provider. Creating the Agent Runtime is the same except for swapping the referenced zip to the x86_64 version.

 response = client.create_capacity_provider(
-    name="haiku_demo_cp",
+    name="x86_demo_cp",
     permissionsConfiguration={"capacityProviderOperatorRoleArn": OPERATOR_ROLE_ARN},
     computeConfiguration={
         "ec2Configuration": {
             "launchTemplateSource": {
                 "launchParameters": {
-                    "operatingSystem": "LINUX_ARM64",
-                    "instanceRequirements": {"allowedInstanceTypes": ["m7g.large"]},
+                    "operatingSystem": "LINUX_X86_64",
+                    "instanceRequirements": {"allowedInstanceTypes": ["m7i.large"]},
                     "instanceProfileArn": INSTANCE_PROFILE_ARN,
                 }
             },
             "vpcConfiguration": {"subnets": [SUBNET_ID], "securityGroups": [SG_ID]},
             "volumes": [{"ebsConfiguration": {"name": "shared", "sizeGiB": 10, "volumeType": "gp3"}}],
         }
     },
 )

The libraries included in the zip also need to be rebuilt for x86_64. The agent code remains unchanged.

uv pip install \
  --python-platform x86_64-manylinux2014 \
  --python-version 3.13 \
  --target build/deps-x86 \
  --only-binary=:all: \
  bedrock-agentcore boto3

{
  "agent": "writer",
  "haiku": "電算機\nシリコン奏でし\nビット舞う",
  "hostname": "ip-172-31-15-215.ec2.internal",
  "arch": "x86_64"
}

The arch shows x86_64, confirming that the same code ran as-is. This could be a viable option when you need to use native dependency libraries that don't provide arm64 binaries, or when you want to bundle binaries that assume x86_64.

Supplement: Do More Session IDs Mean More Instances?

Since sessions and EC2 instances are 1:1, a new instance is launched every time you invoke with a new session ID. During verification, when I called the same Runtime with a different session ID, a second instance was provisioned while the existing one remained running, and each returned a different hostname. If you design your system to assign a session ID per end user, you'll end up with as many instances and EBS volumes as you have concurrent users.

Sessions left unattended don't keep running indefinitely — there is an auto-stop mechanism.

• Runtimes with no incoming calls are automatically stopped after the idle timeout in the lifecycle settings (default 15 minutes). During verification, the writer agent that was left alone had already idle-stopped before I called StopRuntimeSession.
• When all Runtimes on a session stop, the EC2 instance also stops (as seen in Verification 2, there was a lag of about 10 minutes before it stopped).
• Sessions that reach the 14-day limit are also automatically stopped.

EBS is also per session. Checking CloudTrail, the lifecycle movements were recorded exactly as they happened.

11:46:15  CreateAutoScalingGroup   AgentCore   ← At Capacity Provider creation (backend managed by ASG)
11:47:13  RunInstances             AgentCore   ← EC2 launched on first call to session
11:47:30  CreateVolume             AgentCore   ← Shared volume also newly created per session
11:47:36  AttachVolume             AgentCore
(In Verification 2, Runtime stopped → instance moved to stopped state)
12:22:52  RunInstances             AgentCore   ← Re-invoked with same session ID, new instance launched
12:24:06  TerminateInstances       AutoScaling ← Old instance terminated
12:24:10  AttachVolume             AgentCore   ← EBS re-attached to new instance
12:25:12  TerminateInstances       AgentCore   ← Session deleted
12:25:18  DeleteVolume             AgentCore   ← EBS is first deleted at this point

On the other hand, there is no mechanism for automatically deleting sessions. Only the EC2 (compute) stops automatically — EBS is retained in preparation for resumption. EBS for abandoned sessions continues to incur charges until you call DeleteCapacityProviderSession yourself or delete the entire Capacity Provider, and they accumulate for every session ID. The reason DeleteVolume is recorded in the CloudTrail log above is also not automatic — it's the timing when I executed the session deletion after verification. Since instances are treated as managed instances, you cannot delete instances or volumes directly from the EC2 console; the only entry points for deletion are these two AgentCore-side APIs.

Cost is roughly "number of sessions × (EC2 running time + management fee + EBS)", so it's worth planning ahead for operations that delete unnecessary sessions.

Thinking About Which Workloads Are a Good Fit

Looking at the characteristics that emerged through verification, the defining trait of Instances is that session startup is heavy and maintenance is long. The first invocation with a new session ID always takes 44–107 seconds, and each session spins up one EC2 instance and one EBS set. EBS charges continue until the session itself is deleted (via DeleteCapacityProviderSession or by deleting the Capacity Provider entirely).

So it felt a bit different from use cases like chat apps that create large numbers of sessions per user in a short time. On top of the first response taking a minute, costs scale proportionally with the number of concurrent users. For those "high-volume, short-lived, lightweight" sessions, microVMs with per-request pay-as-you-go pricing and no startup wait seem like the better fit.

Instances seem suited for the opposite: a "small number, long-lived, heavyweight" impression — cases like batch jobs or simulations running for several days, GPU inference, or development pipelines where multiple agents share a working directory, where you want to give each agent a dedicated work machine.

Closing Thoughts

Persistent storage and shared file systems are also available with microVMs, so that alone doesn't seem like a reason to choose Instances...!

The advantages unique to Instances, I felt, are: the ability to place multiple Runtimes on the same EC2 instance, compute that can keep running for up to 14 days, the ability to choose EC2 instance types including those with GPUs, and the fact that EC2 and EBS reside within your own account so existing EC2 pricing commitments and account governance apply as-is. In that sense, I personally haven't yet found use cases beyond what's described in the documentation...

As I wrote in the use case section above, I found it a bit hard to use casually...!
If I have a concrete use case in the future, I'd like to give it a try!

I hope this article was helpful in some way. Thank you for reading to the end!