What I was trying to say is that the article describes an architecture that takes cloud billing abuse attacks into account (they point out specifically that R2

What I was trying to say is that the article describes an architecture that takes cloud billing abuse attacks into account (they point out specifically that R2 is preferred to S3 due to egress cost structure) and this design is what partially allows them to ignore the light attack. Most of the cloud architecture posts on HN either focus on how k8s/%your favourite new tool% is good for scale or detrimental to keeping complexity under control. And I think it's valuable for startups to consider cloud billing abuse attacks in addition to horizontal scaling concerns and complexity, which is what I referred to when I said the article has a point. As you wrote, rate limiting and extra checks could get the job done in a scalable deployment, so there is more than one way to keep cloud bill from an attack.