Serverless Workers on Amazon Bedrock AgentCore Runtime
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.
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
An AgentCore Runtime session is the compute that runs a Worker, not a durable place to store Workflow state. AgentCore can resume a session on new compute after the previous compute ends, and a later Task can run on another Worker. Keep state that a Workflow needs in the Workflow or another durable store.
Unlike an AWS Lambda Worker, an AgentCore Worker does not have a fixed Lambda invocation deadline. Your Runtime handler starts the Worker as background work. The Worker polls until it drains or AgentCore ends its compute.
AgentCore has two lifecycle settings:
- Idle Runtime session timeout: Ends a Runtime session after it has not received an AgentCore Runtime invocation for the configured duration. The default is 15 minutes. This is not a Temporal Worker idle timer: polling the Temporal Service does not reset it.
- Maximum lifetime: Ends the compute running a Runtime session after the configured duration. The default and maximum is 8 hours. AgentCore can resume the session on new compute after that.
Implement a separate idle policy in the Worker to release capacity before either AgentCore limit. The AgentCore Runtime sample starts a Worker on invocation, then waits for 60 seconds with no Activity starting or completing. It stops polling, allows up to two minutes for in-flight Activities to complete, and then returns from the Runtime handler. Choose values that fit your workload, and keep them within the AgentCore maximum lifetime.
Configure Activity timeouts and, for long-running Activities, Activity Heartbeats so a retry can recover if AgentCore ends the compute before an Activity completes.
For the lifecycle setting ranges and defaults, see Configure Amazon Bedrock AgentCore lifecycle settings.