OpenClaw on AWS Bedrock AgentCore: Secure and Serverless

Intro

This week AWS released an offering to run OpenClaw in Lightsail
That was a great announcement, and the community was very excited about this feature (Including myself).

While this is super easy to deploy, it requires the instance to be up and running (spending) the entire month. OpenClaw is a great open source product, but its security posture is a concern for many users. AWS Hero Gerardo Castro Arica did a great analysis on the security aspects of this Lightsail implementation. Bottom line, it is heading in the right direction, but it needs some extra steps to secure it.

But guess what? Lightsail is not the only way to run OpenClaw in AWS, there is another "more secure/serverless" way to run OpenClaw in AWS: Using Bedrock AgentCore.

A team of AWS Engineers released this repo that contains the resources to set up everything. It uses CDK to deploy the entire thing. This is not as simple as the Lightsail approach, but ok for users who are familiar with CLI tools (Yes, Kiro/Claude Code can read the instructions and do the deploy themselves)

Architecture

S3 Workspace Sync
AgentCore microVMs are ephemeral by design (They spin up on demand and disappear when idle)
The problem is that OpenClaw stores everything it knows about a user on the local filesystem under .openclaw/ (conversation memory, user profiles, agent configuration, tool outputs). Without a persistence strategy, all of that evaporates the moment a session ends.
The solution is a lightweight S3-backed sync layer built into the container:
When the session starts, the contract server restores the user's .openclaw/ directory from S3 before OpenClaw initializes, giving the agent full context as if the previous session never ended.
Every 5 minutes: a background timer pushes the workspace back to S3, protecting against unexpected failures mid-session.
On shutdown (SIGTERM): a final save runs within AgentCore's 15-second grace window, capturing everything from the session before the microVM terminates.

Security
Network: AgentCore containers run in private VPC subnets with no direct internet exposure. All AWS service traffic routes through VPC endpoints (S3, Bedrock, Secrets Manager, ECR, DynamoDB, STS, CloudWatch). The only public entry point is the API Gateway HTTP API.
Webhook authenticatin: Every inbound webhook is cryptographically validated before any processing occurs. Telegram uses a secret token registered via setWebhook; Slack uses HMAC-SHA256 signature validation with a 5-minute replay window. Both are fail-closed — requests are rejected if secrets aren't configured.
Per-user isolation: Each user runs in their own AgentCore microVM with a dedicated S3 namespace. There is no shared state between users, and namespace assignment is system-controlled — it cannot be influenced by user input.
STS session-scoped credentials: The container assumes its IAM role with a session policy that restricts S3 and DynamoDB access to the current user's namespace and records. Even if a user somehow gained shell access to the container, they couldn't read another user's data.
Secret management: All sensitive values (bot tokens, webhook secrets, Cognito credentials) live in Secrets Manager encrypted with a customer-managed KMS key, fetched at runtime into process memory.
Tool hardening: OpenClaw's read tool is blocked to prevent credential access via /proc or local file reads. The exec tool is allowed for skill management, but the scoped STS credentials limit blast radius. The proxy is bound to loopback only, and security group egress is restricted to HTTPS.
Container hardening: The bridge runs as a non-root user (openclaw, uid 1001). Request bodies are capped at 1 MB. Internal error details and stack traces are never surfaced in API responses.
Encryption: Everything is encrypted at rest (S3 and Secrets Manager with CMK, DynamoDB with AWS-managed keys) and in transit (TLS for all AWS API calls, HTTPS on API Gateway).
Least-privilege IAM: Each component has tightly scoped permissions. The Router Lambda can only invoke its specific AgentCore Runtime.

Instructions

1. Clone repo

git clone https://github.com/aws-samples/sample-host-openclaw-on-amazon-bedrock-agentcore.git
cd sample-host-openclaw-on-amazon-bedrock-agentcore

# Set your AWS account and region
export CDK_DEFAULT_ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
export CDK_DEFAULT_REGION=us-east-1  # change to your preferred region

1. Install Python dependencies

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

1. Bootstrap CDK

cdk bootstrap aws://$CDK_DEFAULT_ACCOUNT/$CDK_DEFAULT_REGION

1. Deploy all stacks

cdk synth          
cdk deploy --all --require-approval never 

1. Build OpenClaw container image

# Authenticate Docker to ECR
aws ecr get-login-password --region $CDK_DEFAULT_REGION | \
  docker login --username AWS --password-stdin \
  $CDK_DEFAULT_ACCOUNT.dkr.ecr.$CDK_DEFAULT_REGION.amazonaws.com

# Read version from cdk.json for versioned image tags
VERSION=$(python3 -c "import json; print(json.load(open('cdk.json'))['context']['image_version'])")

# Build ARM64 image (required by AgentCore Runtime)
docker build --platform linux/arm64 -t openclaw-bridge:v${VERSION} bridge/

# Tag and push
docker tag openclaw-bridge:v${VERSION} \
  $CDK_DEFAULT_ACCOUNT.dkr.ecr.$CDK_DEFAULT_REGION.amazonaws.com/openclaw-bridge:v${VERSION}
docker push \
  $CDK_DEFAULT_ACCOUNT.dkr.ecr.$CDK_DEFAULT_REGION.amazonaws.com/openclaw-bridge:v${VERSION}

1. Create a bot on Telegram a. Message @botfather on Telegram b. Create a new bot with /newbot c. Copy the bot token
2. Store your telegram token

aws secretsmanager update-secret \
  --secret-id openclaw/channels/telegram \
  --secret-string 'YOUR_TELEGRAM_BOT_TOKEN' \
  --region $CDK_DEFAULT_REGION

1. Run telegram setup script to add yourself to the allowlist:
2. Start using openclaw, the first run takes a few minutes, but subsequent iterations are faster. If something fails, check AgentCore logs.

./scripts/setup-telegram.sh

Conclusion

The solution is nice, it works pretty well. However, I found a few things that you may need to consider:

• This solution deploys an entirely new VPC including a NAT gateway. The NAT gateway cost (around 32 USD/month) is pricier than a Lightsail OpenClaw instance, but this architecture could be modified to reuse an existing VPC, or it could host multiple agents. (Not a great deal for a single instance)
• There are a few things that didn't work for me, and I had to fix them: Hardcoded region configurations, DynamoDB API deprecation warnings, an IAM role circular dependency issue, and availability zones need to be configurable as some AZs don't support AgentCore yet (surprisingly). Submitted a PR
• You can change the solution to use Nova Pro (I have some AWS credits that don't cover Claude spend, so I had to switch, and it works pretty well)

Want to try it? This is the GitHub Repo