AWS Lambda to Cloudflare Workers migration for I/O-heavy APIs.
Workers bills CPU time. Lambda bills wall-clock, including the wait on your database or model API. I move the paths where that gap is real, and I leave the rest on AWS.
Move this
- The function mostly waits on a database, webhook, or third-party API, and Lambda bills wall-clock time for that wait
- API Gateway, NAT, logs, and S3 egress are larger than the compute line
- The path is TypeScript, globally cached or lightly CPU-bound, and does not need a VPC
Leave this on AWS
- Python, Step Functions, Glue, or jobs longer than Workers will allow
- RDS or other data that must stay in a VPC
- Memory above the Workers ceiling, or GPU and SageMaker-shaped work
How it is sold
- Audit
- $5,000, 5 business days.
- Build
- Implementation quoted after the audit. Minimum $4,500.
Proof
Whydonate runs Cloudflare-first APIs at 4M+ requests/day (Workers, Pages, R2, Queues, PlanetScale, Typesense). Hudpro still uses Python and AWS Lambda where that stack is the right regional fit.
Questions
Will you move my whole AWS account to Cloudflare?
No. This is a slice migration: I/O-heavy TypeScript APIs, webhooks, and object egress. The rest stays on AWS until there is a reason to move it.
What is the first paid step?
A $5,000 architecture audit in five business days. Implementation is quoted after that and starts at $4,500.
How do you avoid a risky cutover?
One endpoint, metrics before and after, shadow traffic when it is useful, and the old Lambda path kept until error rate and p95 are clear.
Is Lambda the line item you keep explaining?
Email [email protected] or book a call with the function list and last month's bill.