They'll show you a shiny dashboard with "70% savings vs. on-demand." Ignore it. It's based on list prices, not your actual, optimized baseline.
You need to run your own load on their platform and compare to your current, rightsized infrastructure. Don't let them define the benchmark. Here's how:
* **Instrument your representative workload.** Use their trial credits to run it. Capture:
* Peak vCPU/memory utilization
* I/O patterns
* Network egress volume
* **Model the same workload on your current cloud.** Use your actual, discounted rates (CUDs/SPs/RIs). Not the portal's on-demand column.
* If you're on AWS, your EC2 cost for this isn't the public rate. It's your effective hourly rate after discounts.
```bash
# Quick example: get your actual effective rate for an m5.2xlarge in us-east-1
# Total cost of Savings Plans/Reserved Instances for that region/family last month
# divided by total hours of usage for that instance type.
# Your finance tool should give you this. If not, that's your first red flag.
```
Their "savings" vanish when you compare to your committed spend, not theoretical on-demand. If they can't beat *that* number, walk away.
Show the math.
show the math
I'm a senior platform engineer at a 300-person fintech. We run our core transaction engine on a mix of self-managed K8s on EC2 and Lambda. It's about 150 services.
* **Your biggest savings is killing their margin.** Their sales deck shows savings vs. AWS's public on-demand rate, which no one paying at scale uses. Your real baseline is your EC2 effective rate after CUDs/SPs, which, in my last shop, was ~48% off list for our m5/c5 families. If OpenClaw can't beat *that* by at least 15-20%, the migration headache buys you nothing.
* **Network egress will get you.** They're cheap on compute because they're probably reselling someone else's excess capacity. The catch is cross-AZ or internet egress fees. If your workload is chatty between services or pushes lots of data to clients, model that cost at their per-GB rate. I've seen this add 30% to the bill.
* **Integration is a week of pain.** Their control plane isn't vanilla Kubernetes. Expect your ingress controllers, service meshes, and node autoscalers to need tweaks. Budget for 40-60 engineer-hours to get your PoC running and stable, not the 8 hours they claim.
* **Cold starts are real for batch jobs.** If your use case is microservices with steady traffic, fine. For our daily batch processing (spikes to 500 pods), we saw 3-4 minute delays scaling from zero, which blew our SLAs. Test your actual scaling pattern.
For a stateless, HTTP-based microservice with predictable traffic and low data egress, OpenClaw can work if the math is right. For anything with bursty scaling, significant inter-service communication, or high bandwidth out, I'd stick with your committed cloud discounts.
Tell me your average monthly egress in TB and whether your scaling is predictable or spiky.