Claude Agent Scheduling on AWS: Per-Run Budgets and Pause Controls

Confirm the product and account setup

The October 14 Claude Platform release notes add confirmation that scheduled deployments are available on AWS. A deployment uses the Deployments API to start sessions on a schedule, rather than keeping a chat window open. The Managed Agents docs still label the feature Beta and use the managed-agents-2026-04-01 header.

This is Claude Platform on AWS, operated by Anthropic with AWS identity, IAM and Marketplace billing integration. It is separate from Amazon Bedrock and from a Claude Enterprise chat subscription purchased through Marketplace. First confirm the AWS subscription, organization, workspace ID and region; Managed Agents resource requests require anthropic-workspace-id.

Check the role and task inputs in order

First set execution_identity on the agent, with type aws_role and a role_arn in the same AWS account. Each AWS run creates its session as this role. Creating a deployment for an agent without the field returns 400.

Next review the role trust policy: allow aws-external-anthropic.amazonaws.com to call sts:AssumeRole and sts:SetSourceIdentity. The role needs aws-external-anthropic:CreateSession, sts:GetWebIdentityToken and sts:TagGetWebIdentityToken.

Then confirm that the IAM principal assigning the role to the agent has iam:PassRole on that role. The docs explicitly say no managed policy grants this permission. Checking that the role exists, or attaching a managed policy alone, does not complete this step.

Finally supply agent and environment configurations, plus at least one initial user.message or user.define_outcome event describing each new session's work. Choose the execution environment and resources before configuring the schedule; the AWS self-hosted memory-store restriction below affects that choice.

Check the timezone and upcoming runs after writing cron

Schedules use five-field POSIX cron: minute, hour, day of month, month and day of week, with minute-level granularity and an IANA timezone. As a hypothetical example, a team checking a nonsensitive report at 09:00 UTC each day could choose 0 9 * * * with UTC. This illustrates configuration; no deployment or task was run.

After creation, inspect schedule.upcoming_runs_at to confirm the next scheduled times. These reflect the configured triggers, not a promise that sessions start at that exact second. Execution allows jitter of up to 15% of the interval, with the documented five-second minimum and nine-minute maximum. Organizations support up to 1,000 scheduled deployments; contact Anthropic support for more.

Local schedules match wall-clock time: nonexistent spring-forward times are skipped, while repeated fall-back times fire twice. If missed or duplicate executions are unacceptable, follow the docs' advice to avoid the local 01:00–03:00 window or use UTC.

A budget belongs to each run, not the entire schedule

An optional budget is copied onto every session the deployment starts and limits that run's list cost. In a hypothetical three-run day with a $10 budget per run, each run receives its own allowance; $10 is not the daily total. This is a budgeting example, not a quoted price. A session pauses with budget_reached when it reaches its own cap.

Updating the deployment budget affects sessions started afterward. A running session keeps its original cap unless changed through the session itself. AWS platform organization and workspace monthly spend limits are a separate control. The docs say cost accounting can lag by about two hours and overshoot is billed, so a monthly limit is not an immediate substitute for each run's budget.

Apply the two AWS-specific session restrictions

On AWS, a session can run autonomously without user events for up to six hours. It then needs any user-role event to reauthenticate before continuing. This limits an individual autonomous session, not the permitted cron interval, and a scheduled trigger does not establish reauthentication for an already running session. First-party Managed Agents has no autonomous-session runtime limit.

A session on an AWS self-hosted environment cannot attach memory stores; including one causes rejection at creation. Cloud-environment sessions can attach them normally. The generic scheduling docs allow memory stores on first-party self-hosted sessions, but that allowance does not extend to AWS. Choose the environment and resources using the AWS-specific rule.

Inspect run records and decide what pause should stop

Inspect each deployment run's session_id or error.type, then follow the associated session events and result. A session_id establishes successful session creation, not a completed report or an acceptable task outcome. Session-creation rate limiting records session_rate_limited_error without an immediate retry; the schedule tries again at the next occurrence.

Pause prevents future scheduled triggers while existing sessions continue and manual runs remain allowed. Unpause resumes at the next scheduled occurrence without backfilling missed runs. Archive is terminal and prevents further deployment changes. To address work already in progress, inspect that session separately.

Unrecoverable session-creation errors, such as an archived environment or vault, create a failed run and automatically pause the deployment; paused_reason.error.type mirrors the failure. An archived or deleted agent behaves differently: the deployment is automatically archived and no run is recorded. Investigate missing records alongside the agent and deployment state.