One post gets shared, the bots arrive, and every request runs your code: API Gateway charges for it, Lambda bills the time, and the whole Region shares 1,000 concurrent executions. Worked numbers for a six-hour flood with no firewall, with filtering in code, and with AWS WAF or Cloudflare in front, and why the third is about availability more than money.
Bad traffic rarely arrives slowly. A post reaches a big forum, a scraper finds your API, an AI crawler decides to re-read the whole site, or someone points a load tool at a search endpoint. Traffic goes from tens of requests a second to thousands in minutes, and on serverless every one of them is a billed invocation of your code.
The question is not whether to reject that traffic, but where: inside your function, after it has already been paid for, or in front of it.
A dynamic route behind API Gateway (HTTP API) and Lambda, 512 MB, 300 ms per request including a database call. A flood of 2,000 requests a second for six hours: 43.2 million requests. US East prices: HTTP API $1.00 per million, Lambda $0.20 per million requests plus $0.0000166667 per GB-second, CloudWatch Logs $0.50 per GB ingested.
Over a weekend the no-filtering column is about $1,450 before the database bill, which is often the larger line: an auto-scaling database scales up to serve the flood, and a provisioned one simply slows down for everyone.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Lambda gives an account 1,000 concurrent executions per Region by default, shared by every function, and a requests-per-second limit of ten times that. Concurrency is requests per second times duration: 2,000 a second at 300 ms is 600. Double the flood and it is 1,200, past the limit, and Lambda starts throttling every function in the Region, including checkout, login and the webhook handler for your payment provider. The bot doesn't need to break anything; it only has to use the pool.
Reserved concurrency on public-facing functions caps how much of the pool they can take, so a flood throttles that route and not your webhooks.
Filtering in code helps here: a 5 ms rejection uses a sixtieth of the concurrency of a 300 ms request.
Blocking at the edge helps most: the request never invokes anything.
You still pay per request at the front door (API Gateway, load balancer LCUs) and per invocation.
Your code sees one request at a time. Rate limits need shared state, which means a cache or table on every request, which is load in its own right.
Modern bots look like browsers: residential IPs, real user agents, headless Chrome. Edge services see traffic across many sites and maintain reputation lists and bot signatures; your function sees one request.
Code is the right place for business rules: per-account quotas, per-user AI spend caps, abuse of one feature. Keep those there.
Put every public route behind CloudFront or Cloudflare. Nothing should hit API Gateway or a function URL directly.
A rate-based rule on every expensive route: sign-up, login, search, AI endpoints, forms. Answer 429.
Managed bot rules that let verified search and AI crawlers through, since they are how people find you.
Reserved concurrency on public functions so a flood can't starve webhooks and internal jobs.
Per-user quotas in code for anything that costs money per call (AI tokens, SMS, email).
A billing alarm and a dashboard of blocked versus allowed requests, so the next flood is a graph, not a surprise.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
Lambda Web Functions vs Event Functions: Where the New Model Saves Money, and Where It Doesn't
Web Functions bill active CPU and held memory; Event Functions bill wall-clock time multiplied by memory. For AWS's own three example workloads, classic Lambda at 512 MB is cheaper. Once requests spend seconds waiting (LLM streaming, slow APIs, long polls) Web Functions win by 40 times or more: a 10-second stream costs about $3 per million requests instead of $134. The arithmetic, the crossover and a checklist.
Read
Fargate on EKS vs Nodes in 2026: The Price per Pod, and What Fargate Can't Do
Fargate on EKS bills each pod by vCPU and memory per second: about $18 a month for a 0.5 vCPU, 1 GB pod running all month in US East. No nodes to manage, but no Spot on EKS, no DaemonSets, no Pod Identity and no VPC CNI network policies. The math against nodes, and where each fits.
Read
As of November 2, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.