How do I stop my HPA from scaling up just to serve bot traffic?

November 14, 2026 5 answers
Asked by nearly.unfamiliar

My small Kubernetes cluster is scaling up to handle a flood of requests for nonexistent endpoints. Most requests seem to come from different IPs, so ingress rate limiting hasn't helped much. How can I keep this traffic from eating compute without an expensive enterprise WAF?

Answers

Vellby-3n

Put a CDN or WAF in front of the ingress so filtering happens before requests reach your cluster. Cloudflare is one option with a free tier for simple deployments, though you'll need to check its current limits and whether its privacy tradeoffs work for you.

Make sure the origin isn't still directly reachable from the internet, or clients can bypass the edge filtering. A tunnel or firewall rules restricting access to the proxy are possible ways to address that.

r42~zipper_506:

An external service does mean handing it some traffic visibility and depending on it for availability. That's worth weighing against the resources it saves.

Reply to this answer
marnet+afterhours

Have the ingress reject paths that shouldn't exist before forwarding them to the application. A default route that returns an error locally can keep random endpoint probes from reaching your app pods.

That won't make the requests disappear. The ingress still has to handle them, and legitimate applications may need routes that aren't easy to enumerate. Check what is actually generating the 404s before tightening the rules.

Reply to this answer
Vaskel.7p

Take a look at why you need HPA on this workload at all. If a fixed replica count is enough for normal use, removing autoscaling or lowering the maximum replicas puts a ceiling on how much capacity the traffic can trigger.

It's a damage limit, not bot protection. A low ceiling can also leave real users with slow responses or errors during a traffic spike.

Reply to this answer
u63!spareclip_2

Per-IP limits are a weak fit when the requests are spread across lots of addresses. You could look at rules based on request patterns, such as repeated probes for missing paths, and block or divert suspicious traffic at the ingress.

Fail2ban or a security-oriented proxy may help with repeat offenders, but neither magically identifies every distributed bot. Be careful with automatic blocks, since legitimate clients can generate 404s too.

Reply to this answer
w.9~stencil

If browser access is the main use case, a proof-of-work challenge such as Anubis is another option to investigate. It can make automated access more costly without requiring a paid edge service.

Check compatibility before putting it in front of everything. Non-browser clients and integrations may not be able to complete a browser challenge, and a challenge hosted in the cluster still consumes some local resources.

Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions