Every Nepali founder we work with hits the same fork in the road: do we host on AWS Mumbai because that is what the textbook says, or do we go with Cloudflare Workers because the edge promise sounds amazing? We ran the test. Here are the actual numbers from May 2026.
What did we measure?
We tested response times from three networks in Nepal — Worldlink (FTTH, Kathmandu), NTC ADSL (Biratnagar) and Ncell mobile 4G (Pokhara) — to three deployment targets:
- Cloudflare Workers — edge deployment, automatic routing to nearest PoP (Singapore and Mumbai are closest to Nepal).
- AWS Mumbai (ap-south-1) — closest AWS region, both ALB + EC2 and Lambda + API Gateway tested.
- AWS Singapore (ap-southeast-1) — slightly further but heavier point of presence.
Each endpoint returned a 4KB JSON payload from a database read. We ran 1,000 cold-start and 5,000 warm requests per ISP per target over a week.
What were the actual latency numbers?
| From | Cloudflare Workers (p50) | AWS Mumbai Lambda (p50) | AWS Mumbai ALB+EC2 (p50) | AWS Singapore Lambda (p50) |
|---|---|---|---|---|
| Worldlink Kathmandu | 38 ms | 62 ms | 71 ms | 118 ms |
| NTC ADSL Biratnagar | 74 ms | 95 ms | 104 ms | 168 ms |
| Ncell 4G Pokhara | 89 ms | 112 ms | 129 ms | 184 ms |
| From | Cloudflare Workers (p95) | AWS Mumbai Lambda (p95) | AWS Mumbai ALB+EC2 (p95) | AWS Singapore Lambda (p95) |
|---|---|---|---|---|
| Worldlink Kathmandu | 58 ms | 121 ms | 96 ms | 192 ms |
| NTC ADSL Biratnagar | 112 ms | 189 ms | 158 ms | 278 ms |
| Ncell 4G Pokhara | 138 ms | 241 ms | 198 ms | 326 ms |
Cold-start tail latency on AWS Lambda was significantly worse — p99 cold starts on Mumbai Lambda hit 1,400ms from Worldlink. Cloudflare Workers cold starts were under 70ms p99 from the same network.
What does this mean in plain English?
For users inside Nepal, Cloudflare Workers is roughly 40% faster on median and 2-3x more consistent on the tail than AWS Mumbai Lambda. Against AWS Singapore the gap is even wider. If your product is consumer-facing inside Nepal, the user-perceived snappiness difference is real and visible.
For users outside Nepal, Cloudflare also wins because Workers run in the closest PoP to them, while AWS Mumbai is fixed in India.
What about cost?
| Workload | Cloudflare Workers | AWS Mumbai (Lambda) | AWS Mumbai (EC2 t3.small + ALB) |
|---|---|---|---|
| 1M requests/month | USD 5 | USD 2.20 + 0.85 GB-s | USD 17 (24x7) + ALB ~25 |
| 10M requests/month | USD 5 | USD 22 + 8.5 GB-s | USD 17 + ALB ~25 |
| 100M requests/month | USD 35 | USD 220 + 85 GB-s | USD 60 (m5.large) + ALB ~25 |
| Free tier | 100k req/day | 1M req/month | None |
For a typical bootstrapped Nepali startup doing under 10M requests per month, Cloudflare Workers is either free or roughly USD 5. The same workload on AWS Lambda lands around USD 30 once you add GB-seconds and data transfer. EC2 is cheaper at scale but more operational work.
So is Cloudflare always the answer?
No. Three places we still default to AWS:
- Heavy long-running jobs — Cloudflare Workers caps at 30s CPU (paid). Anything image-heavy, ML inference or long DB transactions belongs on a server.
- Postgres-heavy workloads — Cloudflare D1 is improving but is not yet a Postgres replacement. We pair Cloudflare Workers with Neon or Supabase Postgres, but that introduces an extra network hop.
- Tight integration with AWS-only services — if you need SageMaker, Bedrock with specific models, or Athena, AWS is the home turf.
What is our current default stack?
For a typical Nepali startup shipping a B2B or B2C SaaS in 2026, we default to:
- Frontend: Next.js on Cloudflare Pages (or Vercel if AI SDK features dominate).
- API: Cloudflare Workers if it is mostly thin endpoints; AWS Fargate or EC2 if it is Django / Rails / Node with longer requests.
- Database: Neon Postgres (Singapore) or Supabase. We avoid RDS Mumbai unless the client already runs AWS deeply.
- Object storage: Cloudflare R2 by default. Zero egress fees matter for a Nepali startup that may serve users globally.
- CDN: Cloudflare for everything. We have stopped pairing CloudFront with Mumbai EC2.
How do KV, R2, Durable Objects and D1 fit into the picture?
Cloudflare's storage primitives are improving fast in 2026, and most Nepali startups can ship a real product on them now without an AWS dependency. The mental model we use:
- KV — eventually-consistent key-value store. Great for feature flags, session caches, rate-limit counters. Avoid for anything that needs immediate read-your-write consistency.
- R2 — S3-compatible object storage with zero egress fees. We default file uploads to R2 for every new build.
- Durable Objects — single-instance stateful workers. Excellent for chatrooms, live cursors, leaderboards. Underrated for a startup that does not want to run Redis.
- D1 — SQLite-on-the-edge. Good for read-heavy public surfaces (catalogues, marketing data). Still not a Postgres replacement for the transactional core of a SaaS, so we pair it with Neon for the main database.
- Hyperdrive — connection pooler that lets Workers talk to Postgres without dying on cold-start connection setup. Worth the small fee.
What about cost surprises?
The single biggest surprise we have seen Nepali founders hit on AWS is data egress. CloudFront + S3 can cost more than the actual compute on a content-heavy app. Cloudflare R2's zero-egress pricing alone saves one client of ours USD 1,400/month. We wrote about other budget traps in our offshore-agency anti-checklist.
How do we test latency for new builds?
We publish a free latency tester on our tools page that runs the same test from your browser to Cloudflare and AWS endpoints in real time. Use it before you commit to a stack.
How do we migrate an existing AWS stack to Cloudflare?
We have done this migration four times in the last year. The pattern that works:
- Phase 1 (week 1-2): Move static assets and CDN to Cloudflare. Zero application-code changes. Wins on egress cost alone.
- Phase 2 (week 2-4): Move S3-served files to R2 with a one-way sync. Update upload paths to write to R2 going forward; backfill historical files in the background.
- Phase 3 (week 4-6): Move thin API routes (auth check, feature flags, read-heavy endpoints) to Cloudflare Workers. Keep heavy endpoints on AWS for now.
- Phase 4 (week 6-10): Decide whether to fully move compute (Workers + Hyperdrive for Postgres) or keep a hybrid Cloudflare-edge-plus-AWS-origin model. Most clients stay hybrid.
A full migration of a mid-sized SaaS runs USD 18,000-32,000 and typically pays back in 4-9 months through egress savings alone, before counting the latency wins.
What about regulatory and data-residency concerns?
Cloudflare Workers run globally by default, which can be a problem if your customers require data residency in a specific country. Cloudflare's Geo Steering and Regional Services let you constrain processing to specific regions (EU, India, Australia) for an additional fee. AWS regional locks are stricter and more familiar to compliance reviewers. If your customer base includes EU healthcare or financial-services buyers who care deeply about residency, AWS Mumbai or Frankfurt is often the easier sell — not because Cloudflare cannot do it, but because procurement teams know AWS's compliance posture better.
Ready to architect your infra?
If you want a 30-minute infra review for your product, send us a brief on our quote page — we will give you a stack recommendation and a cost projection inside 48 hours.