All DDoS Definitions
DDoS Testing Definition

Yo-Yo Attack

When an autoscaler reads an attacker's burst as genuine demand and provisions for it, the service stays up and the bill climbs with it. That is a yo-yo attack, an application-layer failure mode a thorough DDoS test is built to exercise against elastic infrastructure. The attacker sends enough load to trip the autoscaler, stops once new instances come online, waits for the platform to scale back down, and repeats.

Yo-yo: burst, scale out, stop, scale in, repeat time → load / capacity attack burst attacker stops scales out (late) scales in on cool-down attack load provisioned capacity (lags, chases) The cost capacity arrives after the burst, drains during idle you pay for scale the burst never uses latency spikes on every transition availability control becomes a liability Test characterizes the autoscaler reaction window and cool-down, whether the burst can sit inside that hysteresis, and the spend accrued per cycle. BlackNeuron™
Yo-yo attack: a repeating burst-then-idle pattern drives an autoscaler up and down, so the target pays for capacity it never uses while latency spikes on each scale transition

Why the target's own elasticity is the vulnerability

A yo-yo attack does not defeat a control; it turns one against its owner. The exposure is the one described in autoscaler exposure: scaling absorbs a flood instead of failing under it, so the attack converts into spend rather than downtime. The load itself is unremarkable, a modest HTTP flood of valid-looking requests; the damage is entirely in what the platform does in response.

What makes the yo-yo variant specific is that it targets the hysteresis in the scaling loop. An autoscaler does not track load instantly. It scales out only after a threshold holds for some period, and scales back in only after a longer cool-down, precisely so normal spikes do not cause thrashing. The attacker measures that cool-down and tunes the burst period to sit inside it: load arrives, capacity is added, the load vanishes before that capacity does any useful work, the capacity is eventually removed, and the next burst restarts the cycle.

Every transition also carries a latency tax. New instances are cold, so they pull container images, warm their JITs, and start with empty connection pools and caches, and the requests that land during a scale-out see elevated latency even though nothing is technically saturated. On a serverless backend the same pattern shows up as concurrency-limit churn and a cold-start penalty on every burst.

Yo-yo: capacity chases a load that vanishes Steady-state capacity Usable capacity headroom Time (one burst-idle cycle) Burst trips the autoscaler New instances still warming: latency spikes Capacity online, attacker stops Scale-in completes, next burst hits The burst period is tuned to sit inside the scale-out and cool-down window BlackNeuron™
Yo-yo attack in motion: usable capacity headroom drops when a burst trips the autoscaler and new instances are still warming, recovers once they are online, then the attacker stops and the whole cycle repeats.

Why it matters under attack

This vector is dangerous because it is invisible to the test most teams actually run. A check that asks "did the site stay up?" passes cleanly through a yo-yo attack, because staying up is the mechanism. The damage lands on two axes an uptime check never looks at: the cloud bill, sometimes called economic denial of sustainability, and tail latency, which degrades on every scale transition for as long as the attacker cares to continue.

What a DDoS test measures

A test for a yo-yo attack characterizes the scaling loop as an attack surface. It measures the autoscaler's reaction window in both directions, the scale-out threshold and the scale-in cool-down, then probes whether a burst period can be tuned to sit inside that hysteresis and drive churn indefinitely.

Alongside the timing it records the two costs: the request-latency penalty during each transition, and the spend accrued across cycles against a steady-state baseline. Finally it validates the guardrails that actually bound the damage: a hard max-instance or max-concurrency cap, budget alarms that fire on the spend curve rather than on availability, and authenticating or rate-limiting requests ahead of the scaling boundary so a flood cannot be read as demand in the first place. How to run this without an unbounded cloud bill is set out in running a DDoS test without disrupting production.