If you've been playing around with OpenClaw, you know how handy it is to have an autonomous private AI agent handling tasks right from your WhatsApp, Telegram, or browser. But what are the options other than keeping it running on your home computer 24/7? Moving it to AWS is the logical next step, especially since you can hook it directly into Amazon Bedrock to avoid juggling random API keys for the LLM models.
But how should you actually host it? I spent some time exploring different AWS deployment methods, and it really comes down to three main paths: spinning up a traditional EC2 server, taking the easy route with Lightsail, or going fully serverless.
Here is a breakdown of each option so you can pick the one that fits your budget and technical comfort level.
🖥 Option 1 - Amazon EC2
If you want total control and predictable costs, running OpenClaw on a standard EC2 instance is a great path. AWS maintains a dedicated CloudFormation template that automates the whole setup in about eight minutes.
The biggest advantage here is hardware flexibility. You get to choose your processor, and the example default to use t4g.medium which is ARM-based Graviton instance. Graviton processors run 20% to 40% cheaper for the same performance. t4g.medium will cost you ~$24 per month. The automation script builds out your VPC, sets up IAM roles so you never have to manage API keys, and routes everything securely through private network endpoints.
Since it is a traditional server, you pay a fixed monthly price regardless of whether the bot is actively chatting or sitting idle. It also forces you to use AWS Systems Manager (SSM) for access, meaning you don't have to leave any public ports open to the internet. If you need a 24/7 always-on agent and know your way around AWS networking, this is a solid choice.
The detailed steps and Cloudformation template for setting this up can be found here: https://github.com/aws-samples/sample-OpenClaw-on-AWS-with-Bedrock
⛵ Option 2 - Amazon Lightsail
EC2 can feel a bit heavy if you just want to get your bot running without thinking about subnets and IAM policies. For that, AWS recently added a pre-configured OpenClaw blueprint to Amazon Lightsail.
Lightsail is Amazon's simplified virtual private server service. You just log into the console, pick the OpenClaw Linux/Unix blueprint, select a monthly plan (AWS recommends at least the 4GB RAM plan for good performance), and hit create.
Once the machine boots, you connect through a browser-based SSH terminal to grab your security credentials. You paste an access token into the OpenClaw dashboard to pair your browser, run a quick pre-provided script in CloudShell to enable Bedrock access, and you are immediately ready to start chatting.
You still pay a flat, predictable rate, but the pricing and setup are incredibly straightforward. The main thing to watch out for is security. Because you manage the instance yourself, AWS warns that you should rotate your gateway auth token regularly and keep the gateway off the public internet. If you want a managed VM with a guided, point-and-click experience, start here.
Here's the AWS official blog post and AWS official documentation on how to set it up.
⚡Option 3 - Serverless
This is by far the most interesting setup. Instead of paying for a server that sits idle while you sleep, you can deploy OpenClaw on the Amazon Bedrock AgentCore Runtime using a serverless architecture.
Here is how it works: when you message your bot on Telegram or Slack, an API Gateway catches the webhook and triggers a routing Lambda function. The system looks up who you are in a DynamoDB table and spins up an isolated, per-user microVM specifically for your session. You only pay for the exact compute time your agent uses to process the request and reply.
The hardest part about running bots serverless is that they lose their memory every time the container shuts down. This project solves that brilliantly by using S3 workspace syncing. Right before the microVM boots your agent, it pulls your specific .openclaw/ directory (containing your conversation history and preferences) from an S3 bucket. When the session spins down, it saves everything back to S3.
This option requires the AWS Cloud Development Kit (CDK) to deploy and involves building a custom Docker bridge image, so the initial setup is much more hands-on. But if you are building a multi-tenant bot for several users, or just want to cut your AWS bill by eliminating idle compute costs, the serverless route is absolutely worth the upfront effort.
Here's the git repo for this deployment method https://github.com/aws-samples/sample-host-openclaw-on-amazon-bedrock-agentcore
💡 Conclusion
The table below is a breakdown comparing the three deployment options.
| Feature | Amazon EC2 | Amazon Lightsail | Serverless |
|---|---|---|---|
| Best For | Users wanting full control, high security, and an always-on dedicated server. | Beginners or users who want the easiest, fastest point-and-click setup. | Multi-user setups or cost-conscious users who want to pay only when chatting. |
| Setup Complexity | Low – Automated via an 8-minute CloudFormation template, but requires some AWS knowledge. | Low – Uses a pre-configured Lightsail blueprint. Very guided and beginner-friendly. | High – Requires AWS CDK, building custom Docker images, and manual deployment. |
| Cost Model | Fixed – Pay 24/7 for the instance and VPC endpoints, even when idle. | Fixed – Predictable flat monthly rate based on the instance size you choose. | Pay-per-use – Scales to zero. You only pay for the exact compute time used. |
| Estimated Compute Cost | ~$24/month (t4g.medium). | ~$24/month (4GB RAM plan). | Depend on usage. |
| Compute Type | Dedicated Virtual Machine (supports x86, Graviton ARM, or Mac). | Managed Virtual Private Server (VPS). | Ephemeral per-user microVMs spun up on demand. |
| Memory State | Saved locally on the instance's hard drive. | Saved locally on the instance's hard drive. | Synced dynamically to an Amazon S3 bucket (.openclaw/ directory) between sessions. |
| Security Setup | Highly secure by default (VPC Endpoints, SSM Session Manager, no public ports). | Requires user diligence (keep gateway off the public internet, rotate tokens). | Defense-in-depth (cryptographic webhook validation, VPC isolation, IAM least privilege). |
Top comments (0)