[kennethh]

AWS x86 Price $0.0000166667 for every GB-second $0.20 per 1M requests

Arm Price $0.0000133334 for every GB-second $0.20 per 1M requests

DO $0.0000185/GB-second So basically a little higher price for each GB/s but no cost pr request.

AWS free tier provides 400,000 GB-s and 1 million free requests per month

DO free tier 90,000GB-seconds of usage for free per month

So cheaper in some respects compared to AWS. Google and Azure is roughly the same as AWS. Also DO include egress which is expensive on AWS (it does not say it cost anything).

[Zababa]

Cloudflare workers: $0.15 per 1M requests per month, minimum charge of $5 per month.

Free tier is 100 000 requests per day

Here's the pricing page: https://workers.cloudflare.com/#plans

[upupandup]

up to 10ms CPU time per request

Not much of a room here it seems. AWS still offers more generous CPU time.

In fact any price move by new entrants can be countered by AWS going forward.

So AWS users benefit from not moving. Simply wait for others to reduce their prices and expect AWS to do the same.

[vamega]

The key difference is that unlike lambda where you are charged for network waiting time, Cloudflare from what I can tell, doesn't count time the CPU is suspended for networking operations.

I use a cloudflare worker for DDNS updates, and it runs on the free tier. If the 10ms included network time, my worker would consistently timeout, but it hasn't timed out yet so I must conclude that it doesn't count network time.

[kkielhofner]

This is absolutely correct. I have a worker function that takes ~200ms clock time to execute but most of that is waiting on I/O and doesn’t count against CPU.

Last I checked I think our median is 6ms (against a limit of 50 IIRC) on Workers Bundled.

[Zababa]

There's some clarification on the "limits" page [1]:

> Most Workers requests consume less than a millisecond. It is rare to find a normally operating Workers script that exceeds the CPU time limit. A Worker may consume up to 10 ms on the Free plan and up to 50 ms for Bundled Workers on the Paid Plan. The Paid Plan also offers up to a 30 second duration for increased compute time. The 10 ms allowance on the Free plan is enough execution time for most use cases including application hosting.

> There is no limit on the real runtime for a Workers script. As long as the client that sent the request remains connected, the Workers script can continue processing, making subrequests, and setting timeouts on behalf of that request. When the client disconnects, all tasks associated with that client request are canceled. You can use event.waitUntil() to delay cancellation for another 30 seconds or until the promise passed to waitUntil() completes.

My understanding is that you could consume 1/10 ms of CPU time every hour, and your worker would hit the limit only after 100 hours for the free tier. This would also work with the paid plan - bundled, with up to 500 hours. However, this wouldn't work with the paid plan - unbound, as you pay GB-s, which are counted even if the CPU is not used. From the "Duration" part of "Limits":

> Duration is the measurement of wall-clock time. This is measured in Gigabyte-seconds (GB-s). When a Worker is executed, it is allocated 128 MB of memory . As the Worker continues to execute that memory remains allocated, even during network IO requests.

> For example, when a Worker executes via a scheduled event , it executes for four seconds, including network-bound IO time: 4s x 0.125GB (or 128Mb) = .5 GB-s.

There is also a pricing page that's more detailed [2].

[1]: https://developers.cloudflare.com/workers/platform/limits/

[2]: https://developers.cloudflare.com/workers/platform/pricing/

[upupandup]

Thanks this was the information I was looking for and glad I won't be moving off AWS Lambda anytime soon.

Really puzzling why DO would announce a new product and make it more expensive than incumbents.

Typically, you would want to undercut existing competitors right out of the gate because your competitors will do it for you....by making the first move to reduce their prices, diminishing your own market.

Perhaps there is some other lining here but I don't understand how you launch a serverless hosting and make it more expensive than AWS.

[unethical_ban]

Cost isn't everything, especially at low rates. UI, tooling, and even the "it isn't Amazon" tax. AWS can be complicated for small deployments.

Also, they may be charging their best profitable/break-even rate right now, working on the product to get cheaper over time or with scale.

Basically, I challenge the implication that one should not enter a market unless they are cheaper than the competition.

[impulser_]

Because they want to be a profitable and cash flow positive company

They don't want to be like most of the other cloud infrastructure companies like Cloudflare that are burning a lot of cash to look cheap. Eventually they will have to increase prices too.

AWS, Azure, GCP get the advantage of having contracts with big technology companies that they can oversell their products too to help make up for the loses they have from basic users. It a lot easier to sell junk to big corporations to increase revenue than it is for DigitalOcean to do the same for SMB and start ups.

[erikerikson]

Guess: it's for existing DO users, not for attracting new users. Lock in is very real and for most users mostly fine.

[chickenpotpie]

Digital Ocean's pricing model lines up more with how I expect serverless to be used. It's cheaper for APIs that are very simple and lightweight, but need to be able to handle infinite traffic. I like it. I think it incentives people to use it correctly.

[upupandup]

but wouldn't I simply use AWS free tier which offers more capacity and at cheaper rates than DO in any case?

or is this so much more convenient to pay a bit more and stay on DO?

[kennethh]

Forgot to mention that AWS bills with minimum of 1 ms and DO minimum is 100ms. This also adds up.

[gagan2020]

But then why would I shift to DO. Not much delta to encourage shift. Even individual developer wouldn't find it compelling.

[Hamuko]

It's probably more that you don't have to shift from DO to AWS because you wanted to run lambda. Although I'm not sure if this product is (yet) compelling enough to keep you on DO.

[upupandup]

so this means that DO users have been moving to AWS Lambda?

[lf-non]

As serverless has been gaining traction a lot of users have moved from traditional vps deployments to serverless offerings because it is more affordable for sporadic workloads.

[upupandup]

ah interesting! are there any numbers/stats

[sillycube]

DO may try to better serve the existing users, not trying to encourage shift