Personal OpenClaw on AWS AgentCore for ~$9/mo — learnings
Serverless OpenClaw on AWS Bedrock AgentCore Runtime with CloudFormation. Real cost data, cron scheduling, security hardening, and Alexa integration.
Disclaimer: This is my personal project and experiment. You will incur AWS costs if you follow along. The repo is open source and the CloudFormation template is free to use. Also any opinions in this article are from myself and may not reflect the opinions of AWS.
Why AgentCore Instead of EC2 or Lightsail?
I'd been running OpenClaw on a standard EC2 setup and the cost was bothering me.
A t4g.medium runs ~$24/month just for compute, plus EBS, plus model tokens. Lightsail is simpler but still $24/month flat for the 4GB plan — and the VM sits idle 95% of the time. Let's not even talk about a Mac mini super hyped thing.
Then I looked at Bedrock AgentCore Runtime.
The pitch: your container runs on-demand in a Firecracker microVM, freezes between invocations, and you only pay for compute when you're actually using it. For a personal assistant I chat with a few times a day, that sounded like exactly the right model.
Two months later, my infrastructure bill is ~$9/month. Yay! But let's go on how I got there and what broke along the way.
The Architecture
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Discord / WhatsApp / Telegram / Slack
│
▼
┌──────────────────────────────────────────────────────────┐
│ AWS Cloud │
│ │
│ EC2 t4g.nano ──invoke──▶ AgentCore Runtime │
│ (Discord bot) (OpenClaw container) │
│ │ │
│ IAM Role │
│ │ │
│ Bedrock │
│ (Haiku 4.5 / Sonnet / Nova) │
│ │
│ ┌─────────┐ ┌──────────┐ ┌─────────┐ ┌───────────┐ │
│ │ KMS │ │ Secrets │ │ S3 │ │EventBridge│ │
│ │(encrypt)│ │ Manager │ │(sessions│ │(cron jobs) │ │
│ └─────────┘ └──────────┘ │ memory) │ └───────────┘ │
│ └─────────┘ │
│ CloudWatch ─── SNS ─── Budget Alerts │
└──────────────────────────────────────────────────────────┘Everything is defined in a single CloudFormation template. One
bash scripts/deploy.sh command builds the Docker image, pushes to ECR, and deploys the entire stack.The First Problem: Cron Jobs Don't Work
This was the first real surprise. I set up cron jobs inside the container — daily weather forecasts, weekly email summaries — and they just... stopped firing.
The reason: AgentCore freezes the container between invocations. The cron daemon starts, the container handles a request, then AgentCore freezes everything. The cron daemon is frozen too. It never wakes up to fire the next job.
The fix: EventBridge Scheduler as an external trigger. I built a Lambda bridge that sits between EventBridge and AgentCore:
1
EventBridge Schedule → Lambda → invoke_agent_runtime → AgentCore wakes up → executes the cron taskEventBridge doesn't support
bedrock-agentcore as a direct target, so the Lambda is a thin bridge that receives the schedule payload and calls invoke_agent_runtime. Each cron job created via the cron-add action in the container also creates a corresponding EventBridge schedule.One gotcha: the EventBridge schedule group was managed by CloudFormation, and on redeploy it would sometimes recreate the group — deleting all schedules inside it. Fixed with
DeletionPolicy: Retain and UpdateReplacePolicy: Retain on the schedule group resource.The Second Problem: Secrets in Plaintext
The initial setup had API keys and tokens hardcoded in CloudFormation environment variables. That's fine for a quick prototype but not great for something running in production.
I moved everything to AWS Secrets Manager with a KMS CMK:
OPENCLAW_AUTH_TOKEN,TAVILY_API_KEY,GOG_KEYRING_PASSWORD,DISCORD_BOT_TOKEN— all in Secrets Manager- S3 bucket encrypted with the same KMS key
- S3 bucket policy restricting access to the execution role only
- IAM roles scoped per component (AgentCore, Discord bot, Lambda, Scheduler)
The container fetches secrets from Secrets Manager at startup via
load_secrets_from_secrets_manager() in server.py. No plaintext secrets anywhere in CloudFormation.The Third Problem: Session Persistence
AgentCore containers are ephemeral. When the container freezes and a new invocation starts, you might get a fresh container with no memory of previous conversations.
OpenClaw stores everything in the
.openclaw/ directory — conversation history, MEMORY.md, SOUL.md, workspace files. If that directory is empty on startup, the agent has amnesia.The fix: S3-backed workspace sync. On startup, the container restores sessions, memory, and workspace from S3. Every 5 minutes, it syncs back. On SIGTERM (container shutdown), it does a final save. The agent's personality, memories, and conversation history survive across container restarts. That was a real game changer for an open claw instance for me.
The Discord Bot Problem
Discord bots need a persistent WebSocket connection to Discord's gateway — they have to be "always on" listening for messages. You can't run that inside an AgentCore container that freezes between invocations.
The solution: a tiny EC2 t4g.nano (~$4/month) running a Python Discord bot. It listens for messages, calls
invoke_agent_runtime to wake up the AgentCore container, gets the response, and sends it back to Discord. It's a thin relay.The interesting thing: if you use WhatsApp or Telegram instead of Discord, you don't need the EC2 at all. Both platforms support webhooks (push-based), so you could use API Gateway + Lambda as the webhook handler — fully serverless, no EC2. That would drop infrastructure costs to ~$1-2/month.
The Model Cost Lesson: Sonnet 4 → Haiku
When I first deployed the stack, I used Claude Sonnet 4 as the default model. It's a fantastic model — great at reasoning, coding, and following complex instructions. But my February bill told a different story: $28.64 in Sonnet 4 token costs alone. For a personal assistant handling weather checks, calendar queries, and casual conversation, that's overkill.
I switched to Claude 4.5 Haiku, which dropped token costs to ~$5-7/month for the same usage patterns. The quality difference for everyday tasks? Barely noticeable. Haiku handles Portuguese conversations (my native language), skill execution, and cron job messages just fine. Sonnet's extra reasoning power only matters for complex multi-step tasks — which represent maybe 5% of my interactions.
The takeaway: start with the cheapest model that handles your use case, not the most capable one. You can always switch with one line in
.env. I keep Sonnet available for when I need it, but Haiku 4.5 is the daily driver now.The Model Migration
I started on Claude 3.5 Haiku, which worked great. Then AWS sent a deprecation notice — EOL June 2026. Time to migrate to Haiku 4.5.
This turned into a multi-step adventure:
- Updated the model ID in
.env— easy - Discovered
deploy.shhad a hardcoded fallback that ignored the.envvalue — fixed - Haiku 4.5 requires cross-region inference profiles (
us.prefix) which needaws-marketplace:Subscribepermissions on the execution role — added - The first invocation auto-subscribes via Marketplace, which can take up to 15 minutes — waited
- The budget cost filter needed updating from "Claude 3.5 Haiku (Amazon Bedrock Edition)" to "Claude Haiku 4.5 (Amazon Bedrock Edition)" — manual update since billing dimension names can't be derived from model IDs
Lesson learned: switching models on Bedrock isn't just changing an ID. The IAM permissions, marketplace subscriptions, and billing dimensions all need to align.
Real Cost Data (Per Month)
Here's what I actually paid:
| Component | Monthly Cost |
|---|---|
| EC2 t4g.nano (Discord bot) | ~$4 |
| Public IPv4 address | ~$3.60 |
| KMS | ~$1 |
| ECR, S3, Secrets Manager, CloudWatch | < $1 |
| AgentCore Runtime compute | ~$0 (light personal use) |
| Infrastructure total | ~$9/month |
Model tokens are on top — Haiku 4.5 cost me ~$5-7/month for casual daily use. Sonnet 4 was $28 in February when I was using it more heavily.
The hidden cost surprise: public IPv4 addresses. AWS charges $0.005/hour per public IP since February 2024. That's $3.60/month per IP — almost as much as the nano instance itself.
vs Other Options
| EC2 (t4g.medium) | Lightsail 4GB | This AgentCore Stack | |
|---|---|---|---|
| Compute | ~$24/mo (always-on) | $24/mo (always-on) | Pay-per-use (~$0) |
| Total infra | ~$35-56/mo | ~$24/mo | ~$9/mo |
| Idle cost | Full price | Full price | Nothing |
The Skills System
OpenClaw comes with 30+ bundled skills, but I wanted custom ones. I built a two-tier system:
- Local custom skills — SKILL.md files in
agent-container/skills/for weather, notes/reminders, stock tracking, soccer scores, and a personal assistant briefing - Community skills — a
community-skills.jsonfile (gitignored) that lists ClawHub skills to auto-install at Docker build time viainstall-community-skills.sh
All custom skills use free APIs (wttr.in for weather, football-data.org for soccer, Yahoo Finance for stocks) — no additional API keys needed.
The Alexa Integration
One of the more fun additions: I integrated the
alexacli skill so the agent can control Echo devices — text-to-speech announcements, smart home control, and Alexa+ routines. The idea is simple: tell Lobby (fun name for lobster) "announce on the kitchen Echo that dinner is ready" and it happens.The implementation required cross-compiling the Go-based
alexacli binary for Linux ARM64 (AgentCore runs Graviton), syncing Alexa refresh tokens via S3, and handling credential restoration on container startup. The deploy.sh script clones the repo, builds with GOOS=linux GOARCH=arm64, and copies the binary into the Docker image.The tricky part was authentication —
alexacli needs a refresh token obtained via alexa-cookie-cli, which involves a one-time browser-based login flow. Once you have the token, it's uploaded to S3 via upload-alexa-credentials.sh and restored automatically on each container start.It's a niche integration, but having an AI assistant that can talk to your house through Alexa is genuinely useful — especially for hands-free announcements and smart home automation triggered by cron jobs, grocery lists and so on.
Security Hardening
Running an AI agent that can execute commands and access your data requires taking security seriously. Here's what the stack implements:
| Layer | What it does |
|---|---|
| KMS (CMK) | Encrypts S3 data, Secrets Manager values, and SNS topics |
| Secrets Manager | All sensitive values — no plaintext in CloudFormation |
| IAM Roles | Least-privilege per component |
| S3 Bucket Policy | Session/memory access restricted to execution role only |
| No public ports | Discord bot calls out only |
| AgentCore isolation | Container runs in AWS-managed Firecracker microVM |
| Budget alerts | SNS notifications at 80% and 100% of monthly limit |
What I'd Do Differently
- Start with Telegram or WhatsApp — webhook-based channels eliminate the EC2 instance entirely. Discord's WebSocket requirement is the single biggest infrastructure cost driver.
- Use tag-based budget filters from day one — service-name filters captured costs from other EC2 instances in the same account. Switching to
Project=OpenClawcost allocation tags fixed it. - Don't hardcode model IDs anywhere — they change. The deprecation notice taught me to parameterize everything through
.env.
Try It Yourself
The entire stack is open source:
One-click CloudFormation deploy button in the README, or:
1
2
3
cp agent-container/.env.example agent-container/.env
# Edit .env with your settings
bash scripts/deploy.shDeploy takes about 10 minutes. If you prefer a guided experience, open the repo in Kiro and say "help me deploy my personal OpenClaw."
References
- OpenClaw — the open-source AI assistant
- sample-OpenClaw-on-AWS-with-Bedrock — the original AWS sample (forked from)
- Amazon Bedrock AgentCore Runtime
- OpenClaw on Amazon Lightsail — official AWS guide
- Amazon Bedrock Pricing
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article