Worker request Billable Usage

Developers Workers
,
#1

I am very enjoying looking at the potential of the Edge Worker solution you guys have.

One nagging question I have is, how can I prevent myself from running up a bill of $100’s serving non-genuine requests?

To test this question was worth asking, I ran 90k apache bench requests from a vm against a test setup I made yesterday.

I have looked at the bill today and see billable usage of 90k requests.

I’d love to leverage workers - I am just concerned the pricing is actually a bit of a liability as i could run up a large bill as the result of an attack that sailed > genuine < ddos.

Is rate limiting the suggested mitigation?

1 Like
#2

The rate-limiting service currently costs 50$/10M requests.

#3

While technically not incorrect, the intervals as not ten million requests but ten thousand. So it is 0.05 a 10k, with the first batch being free. So in this example it should be $0.4

#4

Is there a suggested mitigation?

#5

There is not, if the request passes the firewall rules and it’s on an active route the Worker will run.

#6

Well, he could write rate-limitation into the worker itself and it would work - however, globals don’t work across isolates so the protection would not work all the time.

#7

That would be still charged.

#8

His issue is with billing, so the number of requests doesn’t change.

#9

Ah, sorry, I was thinking of another thread about rate-limiting…
So yeah, there’s no way around the issue.

It’s quite a big issue because any competitor could take advantage of it.

#10

But everything that has a bill can, you host your site? Load it and force you to upgrade or pay more bandwidth. Use Lambda? Cloud Functions? Workers? Anything serverless has variability in its cost due to the usage. The trick is to use it only when needed and not activate it everywhere just because it’s simpler.

#11

The thing I wonder about is why rate limiting would not trigger before worker invocation.

#12

What do you mean?

Rate-limiting runs on the firewall so it runs before workers, as mentioned above.

#13

If that is the case the OP doesnt need to worry about workers as rate limiting would kick in.

#14

Correct, but he would need to pay for the rate-limiting feature.

#15

It does run before, but if they have it disabled enabling it to remove billing issues with Workers is counter productive, it would change things if he were bombarded with requests or he knew that there couldn’t be more than a specific number of requests per minute, but rate limiting is way more expensive than Workers.

#16

Agreed, in that case rate limiting is a bit counter productive and Cloudflare should probably revisit the billing plans.

So the bottom line (for the OP) is, there currently is no proper way to protect worker billing from abuse.

#17

I’m also not sure if the rate-limiting is per visitor or per “User” because the billing page mentions “Client A, B, C” etc. If it’s rate-limited on the total amount of visits (many IP’s) then it could block a service from working at all (like if a worker renders a webpage). In this case, rate-limiting won’t work…

#18

Rate-Limiting is total requests per IP per rule per amount of time specified.

#19

Then it’s all good, but yeah, they should take a new look on the billing for rate-limiting to make more sense for workers.

#20

Rate-Limiting isn’t for workers theoretically, it’s for protecting API endpoints, reducing the risk of overwhelming the origin or preventing abuse.

You pay only the good requests.