Deep Dive Architectural Design of a Multi-Tenant Serverless OpenClaw Agent Platform Using Amazon Bedrock AgentCore, Lambda MicroVMs, and LiteLLM Budget Gates
Discover how to build a highly secure, 100% serverless multi-tenant AI agent platform. This technical deep dive explores per-user isolation with Lambda MicroVMs, strict budget controls via LiteLLM and Aurora Serverless v2, and real-time visual Dashboard for OpenClaw.
Series: AWS OpenClaw (4 articles)
- 1Deep Dive Architectural Design of a Multi-Tenant Serverless OpenClaw Agent Platform Using Amazon Bedrock AgentCore, Lambda MicroVMs, and LiteLLM Budget Gates This article
The Paradigm Shift in Multi-Tenant Agent Host Environments
The deployment of autonomous AI agents, particularly community-driven tools such as OpenClaw, has traditionally relied on static single-tenant virtual machines or local physical servers1. In these legacy configurations, the agent engine runs as a single process on platforms like VPS instances or self-managed hardware1. While this approach is simple to implement for individual use cases, it introduces significant operational bottlenecks, security risks, and financial inefficiencies when scaled to support multiple concurrent users or enterprise teams1.
Because OpenClaw is currently under heavy update and active open-source development, its APIs, architectural components, and tooling interfaces evolve rapidly5. Deploying such a dynamic, evolving framework in multi-user settings demands highly resilient security boundaries and rigorous resource controls3.
In a single-process deployment, multiple users share the same underlying operating system process, memory space, and local directory structure5. Because the agent runtime executes arbitrary tools, modifies files, and manages API credentials on behalf of users, this lack of isolation can lead to directory traversal, unauthorized credential access, and data leaks between tenants1.
Additionally, provisioned execution models require instances to remain active continuously6. Because conversational AI agents spend a large portion of their lifecycle in input/output (I/O) wait states—waiting for Large Language Model (LLM) responses, third-party API payloads, or human inputs—this model results in low resource utilization and high idle costs6.
To address these limitations, modern architectures leverage serverless micro-virtualization through Amazon Bedrock AgentCore Runtime3. This platform shifts the hosting model from persistent, shared compute blocks to ephemeral, per-user serverless Lambda MicroVMs2.
In this design, every user session is allocated its own dedicated, kernel-isolated Lambda MicroVM with dedicated CPU, memory, and filesystem allocations2. This environment prevents cross-tenant data access, sandboxes arbitrary tool executions, and ensures that the compute environment is active only during active processing1. When a session times out or finishes executing a task, the runtime terminates the Lambda MicroVM and cleans its memory, eliminating the costs associated with idle servers2.
The table below contrasts the technical differences between traditional provisioned hosting and serverless micro-virtualized agent execution.
| Operational Dimension | Monolithic Provisioned (e.g., VPS) | Serverless MicroVM (Amazon Bedrock AgentCore Runtime) |
|---|---|---|
| Isolation Architecture | Shared OS process; files isolated via standard directory paths1. | Per-session kernel-level virtualization via Lambda MicroVMs5. |
| Scaling Characteristics | Vertical scaling constrained by a single machine's physical limits12. | Horizontal scaling with automated session provisioning2. |
| Resource Billing Model | Continuous flat-rate billing based on provisioned uptime3. | Pay-per-use, billing only active compute time4. |
| Uptime State Persistence | Local disk storage; requires manual backup procedures2. | Ephemeral microVM with S3 sync or native storage5. |
| Idle Capacity Overhead | High; billing continues during API and LLM wait states11. | Low; microVM terminates when the user session becomes idle7. |
| Tool Execution Safety | Host system vulnerable to malicious shell or script execution3. | Sandboxed inside microVM; network and IAM strictly scoped2. |
From a financial perspective, the cost comparison of serverless microVM execution versus provisioned virtual environments can be expressed mathematically. Let C provisioned
represent the flat cost of a provisioned instance over a billing period T, and let C serverless represent the cost of running N distinct user sessions.
In these equations, R instance represents the hourly rate of a continuously active instance, T active,i is the active duration of session i (including boot, processing, and idle timeouts before termination), R compute is the consumption-based microVM rate, S storage is the size of the persistent state, and R storage is the storage replication rate6. Because conversational agents frequently experience long idle intervals, the inequality C serverless << C provisioned holds true for systems with highly distributed or intermittent usage patterns.
Technical Architecture of the Serverless Stack
The core architecture of this serverless agent hosting stack integrates three primary GitHub repositories to form a production-ready serverless environment:
- Core Runtime Foundation (wongcyrus/sample-host-openclaw-on-amazon-bedrock-agentcore): An enhanced fork of the official AWS sample aws-samples/sample-host-openclaw-on-amazon-bedrock-agentcore5. It deploys the foundational multi-tenant AgentCore runtime carrying the OpenClaw agent container3. This fork introduces environment-aware deployment templates (from Pull Request #84) to simplify multi-region operations, automated region mappings, and patched configurations16.
- Serverless Cost Gate (wongcyrus/litellm-aws-lambda-microvm-serverless): Runs LiteLLM within an AWS Lambda environment utilizing the AWS Lambda MicroVMs primitive17. It acts as an isolated, serverless API gateway that validates user identity, evaluates spend caps, logs granular token usage, and routes queries dynamically6.
- Visual Dashboard & Bridge (wongcyrus/openclaw-character-dashboard on the feat/agentcore-dashboard-bridge branch): An interactive visual frontend where OpenClaw agents "live" on a pixel-art map20. The specialized agentcore-dashboard-bridge branch connects this visual environment directly to the active serverless AgentCore Runtime15.
The diagram below details the structural data flow, routing mechanics, and execution paths of this serverless platform.
AgentCore Runtime Session Management & Workspace Sync
When hosting stateful agent applications like OpenClaw in a serverless environment, maintaining session continuity across multiple independent conversational turns is a core challenge5. The Bedrock AgentCore Runtime manages this lifecycle natively, which wongcyrus/sample-host-openclaw-on-amazon-bedrock-agentcore optimizes with enhanced environment-aware deployment parameters.
Dynamic Session-Affinity Routing
To prevent cold-start latencies on every chat message, Bedrock AgentCore implements session-affinity routing.
- MicroVM Stickiness: When a client sends an initial webhook payload, AgentCore provisions a new Lambda MicroVM, generates a unique session header, and passes it back to the Router Lambda10. The Router Lambda caches this session ID mapping.
- Active and Idle States: As long as subsequent user inputs carry this session ID, AgentCore routes the requests to the same warm Lambda MicroVM, preserving conversational memory and local execution history in-memory.
- Lifecycle Demarcation: If the session remains idle (default session_idle_timeout is 15 minutes), the session transitions to Terminated. At this point, AgentCore terminates the Lambda MicroVM and purges its memory state to ensure zero continuous idle costs8. Active sessions are hard-capped at an 8-hour maximum runtime to prevent infinite loops4.
Session Workspace Persistence
Because Lambda MicroVMs are ephemeral and systematically terminated after idle timeouts, saving user profiles, agent-installed skills, and memory logs requires external persistence. OpenClaw maintains its operational state under a localized directory path.
Your deployment orchestrates a dual-method persistence design to preserve this workspace seamlessly:
Your deployment orchestrates a dual-method persistence design to preserve this workspace seamlessly:
- S3-Backed Sync (Fallback Mode): When a Lambda MicroVM initializes, a container-level contract server executes a pre-initialization sync. Using temporary, scope-restricted IAM credentials supplied via AWS STS, it downloads the corresponding user's compressed workspace archive from S3:
The daemon extracts this directory to restore full context12. During runtime, a background sync script pushes modified workspace states back to S3 every 5 minutes and runs a final sweep on container teardown12.
- Managed Session Storage (Native Mode): Utilizing the public preview storage feature in AgentCore, the container can skip manual S3 extraction scripts entirely14. It configures filesystemConfigurations directly on the AgentCore Runtime to mount persistent durable folders at a designated path6. Any changes written by OpenClaw are transparently replicated by the AgentCore platform6. If a session is stopped and later resumed with the same session ID, a newly launched Lambda MicroVM mounts the exact same storage directory, saving source codes and configuration files6.
The table below contrasts the S3-backed sync script and native managed session storage persistence methods.
| Feature Area | S3-Backed Synchronization Script | Managed Session Storage |
|---|---|---|
| Implementation Location | Application-level initialization wrapper script inside container23. | Native platform integration via AWS infrastructure11. |
| Dynamic Mount Type | File extraction over active network calls at runtime9. | Direct Linux directory mount path configurations11. |
| Boot and Setup Delay | Introduces delay to download and extract workspace files23. | Minimal delay; mounts storage blocks dynamically on boot11. |
| Sync Interval | 5-minute background intervals and final shutdown triggers9. | Continuous write replication11. |
| Storage Constraint | Bounded only by S3 storage class capacities23. | Hard limit of 1 GB per session workspace11. |
| Data Retention | Indefinite, unless cleaned up by lifecycle policies6. | 14 days of idle time before automatic purge11. |
Secure Dual-Sandbox Compute with AWS Lambda MicroVMs
The wongcyrus/litellm-aws-lambda-microvm-serverless repository implements a budget control gate that introduces a double-microVM isolation architecture.
Instead of hosting the LiteLLM proxy on a standard API Gateway or persistent compute layer, it is deployed natively inside AWS Lambda MicroVMs. This serverless compute primitive utilizes Firecracker virtualization to provide VM-level hardware isolation, up to 8 hours of execution time, and stateful suspend-and-resume capabilities.
This setup separates the architecture into two distinct, sandboxed tiers:
- The Execution Sandbox: The Bedrock AgentCore Lambda MicroVM isolates untrusted tool runs, user code execution, and messaging channel gateways8.
- The Control Sandbox: The AWS Lambda MicroVM isolates the LiteLLM routing proxy, database keys, and financial budget rules completely away from the agent's reach. Even if a prompt injection attack compromises the agent's workspace shell inside AgentCore, the agent cannot access the model access credentials or manipulate its spending limits.
The Spend Control Pipeline and Strict Budgeting Gates
Why Alerts Are Not Enough: The Need for Strict Hard Limits
Giving an autonomous agent direct, unmetered access to AWS Bedrock models is highly risky. This risk is compounded by the fact that OpenClaw is under heavy development and rapid feature updates3. Because autonomous agents are designed with loop execution capabilities—such as recursive tool calls, self-correction, or continuous cron triggers26—they can easily enter infinite execution loops if they hit unhandled exceptions or recursive logical deadlocks26.
In these scenarios, standard budget alerts are fundamentally insufficient. By the time an administrator receives, reads, and manually acts on an email or SMS notification, a runaway agent can execute thousands of high-context, expensive queries2. This can result in massive, unexpected financial spending on Bedrock or third-party APIs in a matter of minutes.
Therefore, enforcing a hard spending limit—rather than a passive alert—is the absolute key security control for hosting autonomous agents in production3. The LiteLLM Serverless Cost Gate is specifically built to address this vulnerability by checking budgets synchronously on every single query19.
The Gate Enforcement Routine
The LiteLLM Lambda MicroVM proxy evaluates the transaction cost of every inference request:
- Authorization Check: The proxy extracts the identity parameters (Cognito user pool ID or IAM session context) to identify the specific tenant19.
- Balance Verification: The proxy queries a DynamoDB tracker table to verify the user's spending balance:
If the remaining balance , the request terminates immediately with an HTTP 402 Payment Required response, blocking downstream execution and stopping runaway costs at the gateway level.
- Cost Accounting: If valid, the model call is executed over Bedrock. The proxy parses input/output tokens from the API response and updates the tenant's transaction ledger in DynamoDB:
If the remaining balance , B remaining <= 0 the request terminates immediately with an HTTP 402 Payment Required response, blocking downstream execution and stopping runaway costs at the gateway level.
- Cost Accounting: If valid, the model call is executed over Bedrock. The proxy parses input/output tokens from the API response and updates the tenant's transaction ledger in Auroa Serverless
The table below outlines the schema of the DynamoDB database used to track and manage tenant usage metrics.
| Attribute Name | DynamoDB Partition Type | Operational Significance |
|---|---|---|
| TenantID | Partition Key (String) | Mapped identity reference associated with the Cognito user. |
| TransactionTimestamp | Sort Key (Number) | Epoch millisecond timestamp used for chronological sorting. |
| SessionID | Attribute (String) | Trace value associated with the Bedrock AgentCore session ID. |
| ModelName | Attribute (String) | Target model path requested by the agent (e.g., Claude 3.5 Sonnet). |
| TokensInput | Attribute (Number) | Integer count of input tokens processed by the foundation model. |
| TokensOutput | Attribute (Number) | Integer count of output tokens generated by the foundation model. |
| CalculatedCost | Attribute (Number) | Computed cost value generated using current pricing metrics. |
Ingest, Authenticate, and Dispatch Flow
To secure webhook gateways against external exploits, the platform implements a secure validation pipeline.
Step 1: Cryptographic Ingestion Verification
When a webhook payload reaches API Gateway, the system performs validation before starting any compute:
- Slack Signature Verification: The Router Lambda calculates an HMAC-SHA256 signature using the raw request body, a timestamp, and a Slack Signing Secret from AWS Secrets Manager:
If the calculated signature does not match the header, or if the request timestamp is more than 5 minutes old (protecting against replay attacks), the request is rejected with an HTTP 403 Forbidden error.
- Telegram Security Token Validation: For Telegram webhooks, the system compares the request headers against a registered token hash. If the token is invalid, the connection is closed.
Step 2: User Allowlist and Identity Mapping
Once cryptographically validated, the system maps the platform-specific sender ID (such as a Telegram chat ID or Slack member ID) to an internal user identity. The Router Lambda queries a DynamoDB table to verify that the mapped user is on an active allowlist. If the user is authorized, the router retrieves their corresponding Amazon Cognito user record.
Step 3: Scoped Security Credentials Generation
To prevent unauthorized file access, the platform generates session-scoped temporary credentials6. The system assumes its configured execution IAM role with an attached STS session policy. This policy restricts S3 and DynamoDB data access to paths matching the tenant's specific namespace prefix.
These scoped credentials are injected directly into the Lambda MicroVM container. Because this isolation is enforced at the AWS IAM level, the agent cannot access other tenants' files or configurations, even if a user executes arbitrary commands within their Lambda MicroVM.
Visual Dashboard Bridge & State Telemetry Integration
The openclaw-character-dashboard repository (via the feat/agentcore-dashboard-bridge branch) is a highly customized frontend that translates serverless AgentCore state telemetry into a visual interactive workspace.
In the base project, the character dashboard is designed to run locally, checking a single user's directories to animate characters moving between office, bedroom, and living room areas based on active, busy, or idle execution statuses8.
Because Bedrock AgentCore Lambda MicroVMs run in highly isolated, private subnets with no public ingress paths, your agentcore-dashboard-bridge introduces a secure control-plane mapping layer:
A special branch has been added to support the AgentCore OpenClaw implementation: AgentCore Dashboard Bridge Branch
The original version was created by Anita Wong: Original OpenClaw Character Dashboard
Visual State Mapping
The dashboard bridge interacts directly with the private serverless architecture through two parallel channels:
- Telemetry and Lifecycle Synchronization: Instead of accessing local directories, the bridge polls the active serverless session states from Bedrock AgentCore. It maps the active Lambda MicroVM's state (Active, Idle, or Terminated) directly to the visual walk animations of the pixel characters. When an agent is actively running tasks or tool chains, the character moves to the "Office" workspace; when the AgentCore Lambda MicroVM transitions to Idle (waiting for input), the character migrates to the "Living Room". If the session is Terminated due to inactivity, the character is shown in the "Bedroom" sleeping, reflecting that the serverless Lambda MicroVM has shut down and consumed computing resources have scaled to zero.
- Config and Memory Overlays: The bridge accesses user-specific workspaces stored under S3 tenant prefixes. When an administrator edits custom character characteristics or modifies profile parameters on the dashboard, the bridge saves these changes back to the designated S3 bucket. On the next session trigger, the newly booted Lambda MicroVM retrieves these settings, ensuring that character profiles are dynamically managed via the visual dashboard even across cold starts.
AgentCore-Dashboard Bridge & Secure Communication Mechanics
The original AWS AgentCore samples do not support interactive dashboard visualization or management. The feat/agentcore-dashboard-bridge branch of wongcyrus/openclaw-character-dashboard addresses this limitation, serving as a customized administrative control plane that bridges user control interfaces with Bedrock AgentCore Runtime APIs.
Because serverless Lambda MicroVMs operate inside private VPC subnets with no public ingress ports, standard browser-to-container web connections are impossible. The dashboard bridge overcomes this isolation by routing browser requests through IAM-authorized, SigV4-signed AWS API calls. This architecture provides two distinct communication channels:
1. One-Shot Command Execution (InvokeAgentRuntimeCommand)
When an administrator checks a container's status, lists custom skills, or requests the current configuration properties of an active character, the dashboard triggers InvokeAgentRuntimeCommand. This API executes a single command within the tenant's active Lambda MicroVM and returns the stdout and stderr streams directly in the HTTP response. This request-response pattern avoids the overhead of managing a persistent terminal shell for simple administrative operations.
2. Persistent Interactive Terminals over WebSockets (InvokeAgentRuntimeCommandShell)
To support live debugging, shell interaction, and manual skill deployments directly within the isolated tenant environments, the dashboard implements a secure, PTY-backed interactive terminal.
When a developer clicks "Open Terminal" inside the character dashboard interface, the bridge triggers the InvokeAgentRuntimeCommandShell API. This call opens a persistent, bidirectional WebSocket connection that links the browser terminal directly to the tenant's active Lambda MicroVM.
- PTY Emulation & Signaling: The API establishes a full Pseudo-Terminal (PTY) interface inside the target container. This tunnel supports the complete interactive command loop directly through standard websocket channels.
- Session and Shell Identification: Each connection is mapped to a unique runtime session ID and shell ID. This tracking allows developers to open up to 10 parallel shells inside the same Lambda MicroVM to inspect different files or run concurrent diagnostic tasks4.
- Resilient State Retention: Because the shell state is preserved within the active Lambda MicroVM's kernel lifecycle, the developer's working directory, environment variables, and interactive command history remain intact if the network connection drops and reconnects. If a brief connection dropout occurs, the dashboard automatically reconnects and binds back to the same PTY.
This integration allows developers to debug multi-tenant agents inside secure private VPCs without exposing public SSH ports, deploying local reverse proxies, or maintaining complex port-forwarding rules6.
Cost Analysis: Development vs. Production Configurations
The platform’s 100% serverless compute model ensures that raw computing costs (AgentCore and Lambda MicroVMs) strictly scale to zero when agents are idle. However, the foundational network architecture introduces fixed baseline costs depending on how the environment is configured6.
Understanding the financial difference between a NAT-enabled production topology and a zero-base-cost development topology is critical for cost optimization6.
Production Environment (NAT Design)
To maintain strict enterprise security and isolate microVM execution environments from the public internet, production deployments place all serverless containers in private VPC subnets.
Because these private subnets have no direct internet routing, a Managed NAT Gateway is required to allow the AI agents to access external APIs (like web search tools or third-party webhooks). Furthermore, to keep internal AWS service traffic off the public internet, the architecture provisions multiple VPC Interface Endpoints (up to 7 for services like Bedrock, Secrets Manager, and ECR)30.
While highly secure, this network topology incurs a continuous, fixed monthly cost regardless of agent activity:
- NAT Gateway Base Cost: ~32.00 USD / month.
- VPC Endpoints (x7): ~51.00 USD / month (approximately 7.30 USD per endpoint).
- Total Fixed Network Overhead: ~83.00 USD / month.
Compute and inference costs (AgentCore runtime active seconds, Lambda invocations, DynamoDB read/writes, and Bedrock model tokens) are layered entirely on top of this fixed baseline as pay-per-use variables.
Development Environment (No NAT Design)
For development, testing, or individual hobbyist deployments, paying 83 USD per month for idle network infrastructure contradicts the serverless "scale-to-zero" philosophy.
A "No NAT" development configuration deliberately omits the Managed NAT Gateway and the associated VPC Interface Endpoints6. To achieve this while remaining 100% serverless, the deployment either provisions the serverless runtimes in public subnets behind an Internet Gateway (IGW) or simply restricts the agents from making outbound external internet calls (pure internal tool testing).
By removing these networking components, the infrastructure base cost drops effectively to 0.00 USD per month6. The user only pays the pure variable costs generated during active testing:
- Infrastructure Base Cost: 0.00 USD / month.
- Compute (AgentCore / Lambda MicroVM): Billed per active second.
- Storage (S3 / DynamoDB): Pay-per-request pricing models.
- Foundation Models (Bedrock): Billed exclusively per token generated.
For a team iterating on OpenClaw features, the "No NAT" development design ensures that environments left idle overnight or over the weekend accrue absolutely no charges, reserving the full NAT architecture strictly for hardened production environments.
Architectural Synthesis and Recommendations
This multi-repository serverless architecture demonstrates how to secure, scale, and manage stateful AI agents.
Using Bedrock AgentCore Runtime with Lambda MicroVMs ensures that each user’s execution environment is securely sandboxed. Running LiteLLM on stateful AWS Lambda MicroVMs creates a secure double-sandbox architecture, separating execution tools from financial budget tracking. Finally, the specialized openclaw-character-dashboard bridge maps serverless session states directly to a visual, interactive interface.
For production deployments, consider the following optimizations:
- Use Managed Session Storage: Shift from application-level S3 sync scripts to AgentCore's native Managed Session Storage to simplify persistent storage write cycles and reduce container initialization delays.
- Enable DynamoDB On-Demand Autoscaling: Set token ledgers and user allowlists to on-demand capacity. This ensures the database can scale instantly with parallel webhook invocations while keeping billing fully aligned with a serverless, pay-per-use model.
- Optimize the Idle Timeout Window: Set your session_idle_timeout parameters based on user interaction trends. Shorter timeouts reduce Lambda MicroVM compute costs, while longer windows improve responsiveness by preserving warm environments during multi-turn chats.
Works cited
- AI Agent 的迁移与现代化— 使用Amazon Bedrock AgentCore 将OpenClaw 从单机改造为多租户Serverless 架构第一篇, https://aws.amazon.com/cn/blogs/china/using-amazon-bedrock-agentcore-openclaw-multi-1/
- Running OpenClaw on Bedrock AgentCore: A Shared AI Assistant for Teams and Families, https://builder.aws.com/content/39vFiQ645qDsmGd9r77eFCuw29p/running-openclaw-on-bedrock-agentcore-a-shared-ai-assistant-for-teams-and-families
- Deploy OpenClaw on AWS AgentCore | Tutorial Guide - Dr. Melanie Li, https://melanieli.com.au/deploy-openclaw-agentcore/
- OpenClaw 安全和功能增强实践| 亚马逊AWS官方博客, https://aws.amazon.com/cn/blogs/china/openclaw-security-and-feature-enhancement-practices/
- aws-samples/sample-host-openclaw-on-amazon-bedrock-agentcore - GitHub, https://github.com/aws-samples/sample-host-openclaw-on-amazon-bedrock-agentcore
- OpenClaw on AWS Bedrock AgentCore: Secure and Serverless - DEV Community, https://dev.to/aws-builders/openclaw-on-aws-agentcore-secure-serverless-production-ready-i8n
- Amazon Bedrock AgentCore Pricing - AWS, https://aws.amazon.com/bedrock/agentcore/pricing/
- Host agent or tools with Amazon Bedrock AgentCore Runtime, https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html
- docs: /ping response requires undocumented `time_of_last_update` field — without it AgentCore silently reaps microVMs even when status is HealthyBusy · Issue #471 - GitHub, https://github.com/aws/bedrock-agentcore-sdk-python/issues/471
- How it works - Amazon Bedrock AgentCore - AWS Documentation, https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-how-it-works.html
- AI Agent 的迁移与现代化— 使用Amazon Bedrock AgentCore 将OpenClaw 从单机改造为多租户Serverless 架构第六篇, https://aws.amazon.com/cn/blogs/china/using-amazon-bedrock-agentcore-openclaw-multi-6/
- Voice AI agent for Ray-Ban Meta glasses using Amazon Bedrock AgentCore and Strands Agents - GitHub, https://github.com/elizabethfuentes12/meta-ai-agent-sample-for-aws-agentcore
- Deploying Strands Agents to Amazon Bedrock AgentCore Runtime, https://strandsagents.com/docs/user-guide/deploy/deploy_to_bedrock_agentcore/
- Amazon Bedrock AgentCore Runtime now supports managed session storage for persistent agent filesystem state (preview), https://aws.amazon.com/about-aws/whats-new/2026/03/bedrock-agentcore-runtime-session-storage/
- OpenClaw 開箱試玩｜Amazon Bedrock AgentCore 實測＋平價版本改造教學 - YouTube, https://www.youtube.com/watch?v=SL9QMTMcPGY
- Pull requests · aws-samples/sample-host-openclaw-on-amazon-bedrock-agentcore - GitHub, https://github.com/aws-samples/sample-host-openclaw-on-amazon-bedrock-agentcore/pulls
- Cyrus Wong - YouTube, https://www.youtube.com/c/CyrusWong/about
- Announcing Lambda MicroVMs: serverless compute environments with VM-level isolation and near-instant startup - AWS, https://aws.amazon.com/blogs/compute/announcing-lambda-microvms-serverless-compute-environments-with-vm-level-isolation-and-near-instant-startup/
- 基于Amazon Bedrock构建企业级AI Agent：多租户隔离与Token成本治理原创 - CSDN博客, https://blog.csdn.net/weixin_32238157/article/details/162775351
- OpenClaw Character Dashboard — 使用指南 - GitHub, https://github.com/an-it-a/openclaw-character-dashboard
- Use isolated sessions for agents - Amazon Bedrock AgentCore - AWS Documentation, https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-sessions.html
- OpenClaw + Bedrock AgentCore SDK 实战：AI Agent 从本地开发到云端生产的完整路径, https://www.cnblogs.com/AmazonwebService/p/19799084
- AI Agent 的迁移与现代化— 使用Amazon Bedrock AgentCore 将OpenClaw 从单机改造为多租户Serverless 架构第二篇, https://aws.amazon.com/cn/blogs/china/using-amazon-bedrock-agentcore-openclaw-multi-2/
- 用Bedrock AgentCore SDK 把OpenClaw Agent 部署到AWS 托管运行时 - MCP技术社区, https://mcp.csdn.net/6a2e30ae10ee7a33f27cc946.html
- AWS Lambda MicroVMs: The Serverless Backend AI Agents Need - YouTube, https://www.youtube.com/watch?v=zpF79PF-e2U
- The Ultimate Guide to the OpenClaw Gateway Dashboard: Your AI Command Center, https://skywork.ai/skypage/en/openclaw-gateway-dashboard-ai/2036714927809232896
- OpenClaw Dashboard: Complete Guide to the Control UI (2026) - ClawdHost, https://clawdhost.net/blog/openclaw-dashboard-complete-guide/
- AI Agent 的迁移与现代化— 使用Amazon Bedrock AgentCore 将OpenClaw 从单机改造为多租户Serverless 架构第三篇, https://aws.amazon.com/cn/blogs/china/using-amazon-bedrock-agentcore-openclaw-multi-3/
- 1 Amazon Bedrock AgentCore Runtime - Part 1 Introduction - DEV Community, https://dev.to/aws-heroes/amazon-bedrock-agentcore-runtime-part-1-introduction-e5i
- sample-host-openclaw-on-amazon-bedrock-agentcore/CLAUDE.md at main - GitHub, https://github.com/aws-samples/sample-host-openclaw-on-amazon-bedrock-agentcore/blob/main/CLAUDE.md
- Amazon Bedrock AgentCore Runtime introduces interactive shells for terminal access into agent sessions, https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-agentcore-runtime/
- sample-host-hermesagent-on-amazon-bedrock-agentcore/README_ZH.md at main, https://github.com/aws-samples/sample-host-hermesagent-on-amazon-bedrock-agentcore/blob/main/README_ZH.md
- sample-host-openclaw-on-amazon-bedrock-agentcore/docs/security.md at main - GitHub, https://github.com/aws-samples/sample-host-openclaw-on-amazon-bedrock-agentcore/blob/main/docs/security.md
- Amazon Bedrock AgentCore Runtime now supports stateful MCP server features - AWS, https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-bedrock-agentcore-runtime-stateful-mcp/
- Deploy OpenClaw on AWS: Choose the right options ... - Neura Market, https://www.neura.market/directories/copilot/blog/devto-3497987
Series: AWS OpenClaw (4 articles)
- 1Deep Dive Architectural Design of a Multi-Tenant Serverless OpenClaw Agent Platform Using Amazon Bedrock AgentCore, Lambda MicroVMs, and LiteLLM Budget Gates This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article