Probably not, and this is worth measuring rather than assuming. Edge rate counters are kept per data centre and are built for speed rather than accuracy. A caller spread across several of them is counted several times over, each count below your threshold. Measured against one of our own endpoints, most requests that should have been refused passed.
That is fine for what it is good at, and wrong for everything else. A loose edge counter is nearly free and shapes a burst, which is a real job. It is the wrong instrument for any number you PUBLISH as a limit, bill against, or rely on to protect an expensive endpoint.
So run two kinds, and know which is which.
- The loose edge counter stays, for burst shaping, because it costs almost nothing.
- Anything that must be exact gets a single-writer counter - one object that every request for that key goes through, so the count is real. On Cloudflare that is a Durable Object; elsewhere a Redis counter does the same job.
Two design points that are easy to get wrong. Put a daily budget on top of the per-request limit, and key it per APP GROUP rather than per hostname: two hostnames in front of the same backend would otherwise get double the allowance for the same capacity. And when a budget trips, do not keep consulting the counter under load - set a cached flag that later requests read cheaply, so refusing costs less work than serving did. A breach must make the system do less, never more.
Also worth separating in your head: a per-address limit says nothing about total load. A hundred addresses each comfortably under their own limit can still take an app down together, which is a different problem with a different answer.
Related: rate limiting and getting the real client IP, and the perimeter section of the checklist.
Building something like this? How I work covers the rates, the availability and what I take on.