Ashish Sharma

Full-stack backend developer -- Cloudflare Workers, AWS, Node.js/TypeScript, Python, and production application architecture.

Migration

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

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.

Whydonate case study · Workers vs Lambda cost notes

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.

Email [email protected] or book a call.