Skip to main content

Serverless Workers on Amazon Bedrock AgentCore Runtime

View Markdown

This page covers how Serverless Workers run on Amazon Bedrock AgentCore Runtime, including Worker Versioning and the Runtime session lifecycle.

On AgentCore Runtime, a Serverless Worker is a standard long-running Temporal Worker that runs inside an AgentCore Runtime session. When the Worker Controller Instance (WCI) needs capacity, it invokes an AgentCore Runtime endpoint. The Runtime starts a Worker, which connects to the Temporal Service and polls its Task Queue.

AgentCore Runtime uses the same event-driven autoscaling model as AWS Lambda. The WCI invokes individual Runtime sessions when it needs more capacity; it does not manage a target-sized pool of Runtime sessions.

Worker Versioning​

Serverless Workers require Worker Versioning. Associate each Worker Deployment Version with a named AgentCore Runtime endpoint that points to one AgentCore Runtime version.

AgentCore creates an immutable Runtime version when you create or update a Runtime. A named endpoint has a stable ARN and points to a chosen Runtime version. Configure the endpoint ARN as the compute provider for the corresponding Worker Deployment Version:

temporal worker deployment create-version \
    --deployment-name my-worker \
    --build-id v1 \
    --aws-agentcore-endpoint-arn <AGENTCORE_RUNTIME_ENDPOINT_ARN> \
    --aws-agentcore-assume-role-arn <INVOKE_ROLE_ARN> \
    --aws-agentcore-assume-role-external-id <EXTERNAL_ID>

Use one named endpoint for each Worker Deployment Version. For example, point an endpoint named temporal-v1 at AgentCore Runtime version 1 and use its ARN for Temporal Worker Deployment Version my-worker/v1.

When you deploy new Worker code, AgentCore creates a new Runtime version. Create another endpoint that points to that new Runtime version and configure it on a new Worker Deployment Version. Keep the older endpoint while Pinned Workflows can still need the older Worker code.

caution

Do not configure a live Worker Deployment Version with AgentCore's DEFAULT endpoint. That endpoint moves to the latest Runtime version whenever you update the Runtime. Updating code behind a Worker Deployment Version can cause non-determinism errors for in-flight Workflows, including Pinned Workflows.

For details about AgentCore Runtime versions and endpoints, see AgentCore Runtime versioning and endpoints.

Lifecycle​

The Runtime session provides the compute that hosts a Worker. It is not the durable identity of a Workflow, and Temporal can route a later Workflow or Activity Task to another Worker.

Unlike an AWS Lambda Worker, an AgentCore Worker does not run within a fixed Lambda invocation deadline. Your Runtime handler starts the Worker as background work, and the Worker continues polling until it drains or AgentCore terminates the Runtime session.

AgentCore applies lifecycle settings to each microVM Runtime session:

  • Idle Runtime session timeout: Ends an idle session. The default is 15 minutes.
  • Maximum lifetime: Ends a microVM session after a fixed lifetime. The default and maximum is 8 hours.

Set the Worker’s own idle and graceful-shutdown policy so it stops polling and drains in-flight Tasks before its Runtime session is no longer needed. The AgentCore maximum lifetime remains a hard termination boundary. Configure Activity timeouts and, for long-running Activities, Activity Heartbeats so a retry can recover after a Worker is interrupted.

For the lifecycle setting ranges and defaults, see Configure Amazon Bedrock AgentCore lifecycle settings.