AWS Runs Claude Code Remotely: One microVM per Task

A remote coding agent addresses a familiar problem: a local Claude Code session is useful only while the laptop is open, the environment is available, and the task does not require a lengthy test run. AWS proposes moving this process into Amazon Bedrock AgentCore. The developer describes the task, closes the laptop, and later receives a draft pull request containing the changes and validation results.

What matters here is not merely that Claude runs in the cloud. The value lies in the assembled control plane: a separate environment for each task, temporary GitHub access, private connections to AWS services, a restricted IAM role, and mandatory human review. The agent can write code, but it cannot independently merge it into the main branch.

How a Single Task Runs

Consider a small bug: an API returns 500 instead of 404 when a record is not found. The developer submits a description through the Claude Code plugin or web console. The request is signed with AWS credentials, checked by Amazon Bedrock Guardrails, stored in DynamoDB, and placed in an SQS queue.

The dispatcher starts a separate AgentCore Runtime session. Each task gets its own microVM with isolated CPU, memory, and file system. Claude Code CLI, Claude Agent SDK, git, and make are already installed inside. The agent receives a temporary GitHub token, clones the repository, and reviews saved hints from previous runs for that project.

Claude Opus then creates a plan, while Claude Sonnet implements the changes. The agent runs the installation and testing commands declared by the repository itself. Opus then reviews the result and, if necessary, sends the work through another iteration. The system allows up to three attempts. Finally, the agent creates a branch such as agent/<taskId> and opens a pull request listing the validation command, its exit code, and the number of attempts. If the tests fail, the pull request remains a draft.

Where the Security Comes From

The container receives no permanent AWS keys. Model calls go through Amazon Bedrock using temporary IAM credentials from the runtime environment. The GitHub App is installed only in selected repositories, and the token issued to the agent remains valid for up to 8 hours. Permissions are limited to repository contents and pull requests, while commits are signed by the application's account.

The network is restricted as well: the environment operates in private VPC subnets and accesses Bedrock and other AWS services through private endpoints. Internet access is required for GitHub and package registries. In the example, model-provider domains are blocked through DNS Firewall, although AWS explicitly warns that a domain denylist does not control all HTTPS traffic. Production deployments need an allowlist enforced at the AWS Network Firewall level.

Guardrails checks the original task for jailbreak attempts, malicious requests, and secrets. Repository files and command output, however, do not pass through this check. A malicious instruction hidden in a README or build script therefore remains a risk. microVM isolation protects other tasks and the developer's laptop, but it does not make untrusted code safe.

What Teams Should Do

Start with narrowly scoped tasks in a trusted repository: a small feature, a bug fix, or added tests. The project should provide reproducible setup and test commands, and the main branch should require review. Open-ended research and large refactors are a poorer fit: the agent is limited to three attempts and is harder to steer while running than a local session.

There is also a cost. Deployment takes 15–25 minutes, while repository registration takes another 8–12 minutes. NAT Gateway, network endpoints, WAF, Cognito, DNS Firewall, image storage, and logs incur charges even when no tasks are active. A $200 budget merely sends an alert; it does not stop spending.

The practical conclusion is straightforward: this is not simply “Claude Code on a remote server,” but a blueprint for a managed pull-request factory. It will appeal to teams that need parallel background tasks, AWS-based auditing, and isolation from developer laptops. But it should be launched only with branch protection, outbound traffic controls, spending limits, and a strict rule: the agent proposes changes, while a human decides what reaches production.