Unlike a flood that knocks a service over, an attack on autoscaler exposure does not produce an outage; it produces an invoice. It is one of the quieter risks a DDoS test is built to characterise: an application-layer flood is read by the autoscaler as legitimate demand, so the platform adds instances, containers or serverless invocations, and the service stays up while the cloud bill climbs. The failure mode is sometimes called economic denial of sustainability.
How a flood becomes a bill
Autoscalers act on signals: CPU, requests per target, queue depth, concurrent executions. An HTTP flood of valid-looking requests raises every one of them, and none of them can tell a customer from a bot. If the requests reach the scaling signal, they are demand as far as the platform is concerned.
Compute is only part of it. Each extra request may also pay for database capacity that scales alongside, load-balancer capacity units, NAT data processing, log ingestion and egress. A request that is cheap at the edge can be expensive by the time every metered service behind it has counted it.
Scaling is also lopsided in time. Scale-out is tuned to react within minutes, while scale-in is deliberately slow so the fleet does not flap. The Kubernetes Horizontal Pod Autoscaler is a concrete case: scale-up has no stabilization window by default, while scale-down waits 300 seconds and acts on the highest recommendation seen in that window. When the flood stops, the extra capacity stays billed through that delay. An attacker who pulses traffic, a pattern known as a yo-yo attack, can keep the fleet large while sending load only part of the time.
The choice of signal sets how much a flood can buy. Request count and requests per target grow one for one with attack traffic, so they are the easiest to inflate. Queue depth can be worse: if each junk request enqueues a job, or a slow worker lets the backlog grow, the queue swells faster than the request rate and the scaler adds workers to drain work that should never have been accepted. CPU sits in between and depends on how expensive each request is to serve.
Why it matters under attack
Each guardrail trades one risk for another. A max-instance cap bounds the bill, but at the cap the service stops absorbing and the attack is an availability problem again, so the cap is a choice about which failure you prefer rather than a fix. Budget alarms lag: billing data arrives hours after the spend, long after the scale-out happened.
Serverless adds a shared ceiling. On AWS Lambda the default concurrency quota is 1,000 per account per region, shared by every function, so a flood on one function can throttle unrelated ones. A cost problem becomes a blast radius problem unless reserved concurrency fences the critical functions off.
The durable fix is to filter in front of the scaling boundary. Rate limiting or a WAF rule at the edge stops junk before it reaches the metric the autoscaler reads, and scaling on signals an attacker cannot cheaply inflate, such as authenticated sessions rather than raw request count, narrows what a flood can buy.
What a DDoS test measures
A test drives a controlled application-layer flood and records the scaling response step by step: instances or concurrency at each load level, time to reach the cap, latency once at the cap, and how long the fleet takes to shrink after the attack ends. Multiplying the peak and the tail by unit prices turns that into a cost per attack-hour, a figure a budget owner can act on.
It also checks the order of events. If the edge filter engages before the autoscaler reacts, the exposure is small. If the fleet has already doubled by the time any control notices, the edge is guarding availability and leaving the bill unguarded. How this is exercised alongside concurrency limits and cold starts is described in Serverless DDoS Testing.