The mental image most people still carry of a DDoS attack is a wall of traffic, a graph that goes vertical, and a site that falls over because the pipe filled up, and that image is now mostly obsolete, because bandwidth is cheap and attackers figured out a while ago that they don't need to outgun you when they can outspend you or outthink your middleboxes instead.

What has actually changed is the target, and the target is no longer your connection, it's your state table, your application logic, your API cost model, and your cloud bill, because those are the places where a small amount of attacker effort produces a large amount of defender pain.

So here is where the trend lines actually point, which techniques are rising, and what defenders should be doing about each one rather than buying more bandwidth and hoping.

Important Disclaimer

This article is intended for educational and defensive purposes only, and it describes general attack patterns and defensive practices rather than specific incidents or vendor claims. Attack techniques evolve quickly and mitigation choices depend on your architecture, your providers, and your budget, so validate every control against your own environment and test it before you need it. 

Never run load tests or attack simulations against systems you do not own or have explicit written permission to test, because unauthorised testing is a criminal offence in most jurisdictions. The author assumes no liability for missed detections, service impact, cloud costs, business outcomes, or damages resulting from the use or misuse of this information.

Trend One: Volume Stopped Being the Point

The old model was that attack size had to exceed your capacity, and the defence was to buy more capacity than the attacker could generate, which was a straightforward arms race that a large provider could win.

That model broke for two reasons, which are that attack capacity became commoditised through cheap cloud instances and infected consumer devices, and that defenders moved behind anycast networks with enormous aggregate capacity, so the pipe stopped being the weak link. Attackers responded by going after whatever is smallest and most expensive in your stack, which is usually a stateful device, an uncached endpoint, or a database query.

The practical consequence is that an attack measured in a few gigabits per second can now take down a service that shrugs off a hundred times that volume, because the limiting factor isn't throughput, it's connection state, CPU per request, or a query that takes two seconds of database time.

Trend Two: Carpet Bombing Defeats Simple Thresholds

The most common defensive control is still a per-IP rate limit, and the most common bypass is to distribute the attack across a very large number of source addresses so that no single address ever crosses the threshold.

This is called carpet bombing, and it's effective for a simple reason, which is that the attack stays under every individual limit while the aggregate volume lands squarely on the target. It also defeats reputation-based blocking, because the sources aren't known bad addresses, they're ordinary residential and mobile IPs that have been recruited or proxied.

Defending against it requires shifting from per-source thinking to per-target and per-path thinking, which means measuring the request rate to a specific endpoint, comparing it against a baseline, and applying a challenge rather than a block when the aggregate deviates.

Trend Three: Application Layer Attacks Target the Most Expensive Endpoint

The highest return for an attacker is the endpoint that costs you the most to serve, which is typically a search function, a report generator, an export job, a login flow, or a GraphQL endpoint that lets one request trigger dozens of backend calls.

A small number of well-chosen requests can exhaust a connection pool or saturate a database, and because the requests look like normal traffic and often come from residential addresses, signature matching does nothing and per-IP limits are irrelevant.

The defences that work here are architectural rather than network-level, which means query complexity limits, pagination caps, caching for anything cacheable, per-account and per-session quotas in addition to per-IP quotas, and a hard ceiling on how much work any single request can trigger.

Practical Example: 

An unauthenticated search endpoint that runs a wildcard query across a large table will fall over long before your bandwidth does, so the fix isn't more scrubbing capacity, it's a query timeout, a result cap, and a cache in front of it.

Trend Four: Attacks Are Designed to Cost You Money

The most underrated trend is that the damage is now often financial rather than availability-related, because autoscaling responds to load by adding instances, and egress is metered, and both of those convert an attack into a bill.

An attacker who can drive your fleet from ten instances to three hundred for six hours has achieved something more durable than downtime, because the invoice arrives whether or not the site stayed up. The same logic applies to third-party API calls that are billed per request, and to any managed service that scales automatically.

The defensive controls are boring and effective, which means autoscaling maximums, budget alerts that fire before the invoice does, egress monitoring with anomaly alerts, caching to reduce origin hits, and a documented decision about which third-party calls to shed under load.

Trend Five: Origin IP Discovery Bypasses Your Entire Edge

A large share of successful DDoS incidents don't attack the CDN at all, because the attacker finds the real server address and hits it directly, which removes every protection you paid for in a single step.

Common ways the origin leaks are historical DNS records, subdomains that were never proxied, mail servers on the same range, scanning for certificates that reveal the hostname, error pages and headers that disclose internal addresses, and old infrastructure that still resolves. Once the origin is known, the CDN is irrelevant, because the attacker simply doesn't use it.

The defence is to treat your origin as a secret that has to be maintained, which means restricting inbound traffic to your provider's published ranges, rotating the origin address if it has ever been exposed, checking your own DNS history, and regularly scanning your own estate for services that answer directly to the internet.

# Check whether your origin answers directly to the world
curl -sI https://origin-ip/ | head -20

# Look for a bypass: compare headers served via CDN vs direct
curl -sI https://example.com | grep -iE 'server|via|cf-ray|x-cache'

Trend Six: TLS and Protocol Exhaustion

Because bandwidth got cheap, attackers moved down the stack to the parts of your infrastructure that are computationally expensive, and TLS handshakes are the obvious candidate.

A flood of half-open connections, repeated handshakes, or expensive key exchange operations burns CPU on your terminators without requiring much bandwidth, and the same principle applies to HTTP/2 and HTTP/3 where a small request can trigger a disproportionate amount of state. Protocol-level floods against VPN concentrators, firewalls, and load balancers are a variant, and they're popular because a stateful device that fills its table stops serving everyone, not just the attacker.

The defences are connection limits at the edge, aggressive timeouts, SYN cookies, handshake rate limits, and offloading termination to a provider whose entire job is absorbing that cost.

Trend Seven: Residential and IoT Sources Look Legitimate

The composition of the average botnet has shifted toward devices that are hard to block, which means home routers, smart TVs, IP cameras, and above all residential proxies that route traffic through real consumer connections.

From your logs they look like ordinary users on ordinary ISPs, and blocking them wholesale means blocking real customers, so the useful signals move from reputation to behaviour, which means request patterns, session behaviour, header consistency, JavaScript execution capability, and whether the client can actually complete a challenge.

This is also why purely IP-based mitigation ages badly, and why behavioural bot management became a category rather than a feature.

Trend Eight: Short Bursts to Evade Detection and Billing Cycles

Long sustained attacks are easy to notice, and short bursts are not, which is why attackers increasingly send minutes of traffic rather than hours.

A two-minute spike every twenty minutes never trips a five-minute average alert, never justifies an incident call, and never appears in a monthly report, while still degrading service for the users who happened to hit it. The same pattern can be used to probe which mitigation thresholds exist, by watching how your response changes as the volume rises.

The defence is to alert on short-window percentiles rather than long averages, keep the retention granular enough to see the burst after the fact, and treat repeatable spikes as an incident rather than as noise.

Trend Nine: DDoS as Cover and as Leverage

Two hybrid patterns are increasingly common, and both change how you should interpret an availability incident.

• The first is DDoS as distraction, where the availability event is designed to pull attention and staff toward the edge while something quieter happens elsewhere, which means an availability incident should also trigger a check of authentication logs, admin activity, and data access rather than just a traffic graph.
• The second is extortion, where the attacker demonstrates capability with a short attack and then demands payment, sometimes alongside a data theft claim. The correct posture is not to pay, because payment funds the next round and rarely stops it, but the decision belongs with leadership and legal rather than with the network team mid-incident.

What Actually Works: Defensive Architecture

Given all of that, the controls that hold up are not exotic, and most of them are architectural decisions made before an incident rather than purchases made during one.

• Absorb at the edge with anycast. Terminating traffic across a large distributed network means the attack is spread across many locations, and the attacker's per-location volume becomes uninteresting.
• Hide and protect the origin. Restrict inbound to your provider's ranges, rotate the address if it has ever leaked, and verify regularly that nothing answers directly.
• Mitigate on behaviour, not on source. Per-path baselines, aggregate rate limits, session-level quotas, and challenge-based verification outperform IP blocklists against residential botnets.
• Cap the cost. Autoscaling maximums, budget alerts, egress monitoring, and caching so the origin sees less traffic and you pay for less transfer.
• Protect the expensive endpoints specifically. Query complexity limits, pagination caps, timeouts, and caches in front of search, export, and report generation.
• Test the plan. A runbook nobody has executed is a hypothesis, so run a controlled load test against your own staging environment with your provider notified, and find the thresholds before an attacker does.

Tools Worth Having in Place

A useful small example is limiting a single expensive path without touching the rest of the site:

limit_req_zone $binary_remote_addr zone=search:10m rate=5r/s;

location /api/search {
    limit_req zone=search burst=10 nodelay;
    limit_req_status 429;
    proxy_read_timeout 5s;
}

That's not a DDoS defence on its own, and it is exactly the kind of control that turns an expensive-endpoint attack from an outage into a rate-limited annoyance.

Real Two Scenarios

Scenario 1: The Attack That Never Touched the CDN

The Setup

A company pays for a well-known scrubbing service, has a WAF in front of the site, and considers availability handled, while an old subdomain still resolves directly to the origin server and has never been proxied.

What Happened

The attacker finds the subdomain, resolves the origin address, and sends traffic straight to it, so the CDN sees nothing, the WAF sees nothing, and the origin collapses under a volume it was never sized for.

The Result

The site goes down while the scrubbing dashboards stay flat, and the first hour of the incident is spent arguing about whether the provider is failing, when the real problem is that the provider was never in the path.

The Lesson

Edge protection is only as good as your origin hygiene, and a single unproxied record undoes the entire investment, which is why origin discovery deserves its own recurring check.

Scenario 2: The Expensive Endpoint and the Invoice

The Setup

Another company front-loads caching, caps autoscaling, and limits query complexity on the endpoints that cost the most to serve, and it alerts on short-window request rates rather than daily averages.

What Happened

An attacker sends bursts of unauthenticated search requests from residential addresses, spread widely enough that no single IP limit triggers, and the aggregate rate on that one path triples within ninety seconds.

The Result

The per-path alert fires, the complexity limit and cache absorb most of the load, autoscaling caps prevent the fleet from ballooning, the burst dies out within minutes, and the incident report shows a modest cost increase rather than a runaway bill.

The Lesson

The controls that mattered were the unglamorous ones, which were caching, caps, per-path limits, and short-window alerting, and none of them required a bigger scrubbing contract.

How to Spot That You're Being Targeted

• The edge dashboard is flat while users report errors. That suggests the attack is bypassing your provider and hitting the origin directly.
• No single IP is misbehaving but one endpoint's rate triples. That's carpet bombing or a distributed L7 attack.
• CPU saturates while bandwidth stays normal. That points to handshake exhaustion or expensive requests rather than a volume flood.
• Cloud spend spikes without a matching traffic spike. Cost-targeted attacks often look unremarkable in the traffic graph.
• Short, repeatable spikes appear every few minutes. Burst patterns designed to stay under averaging windows look exactly like this.
• Authentication or admin logs show activity during the availability incident. Assume distraction until proven otherwise.
• A challenge page suddenly fails for real users. Residential-sourced bots are often indistinguishable from customers, so test challenge impact before enabling it globally.

Quick Reference: Trend to Countermeasure

The Bottom Line

The trend that matters isn't that attacks got bigger, it's that they got cheaper and more precise, aimed at the state tables, the expensive endpoints, the origin addresses, and the billing models that defenders built while assuming the threat was purely volumetric.

The controls that hold up are unglamorous and mostly architectural, which means absorbing at the edge, hiding and verifying your origin, limiting by path and by session rather than by IP, capping the blast radius of autoscaling and egress, and alerting on short windows instead of monthly averages.

So pick one thing this week, which should be checking whether your origin answers directly to the internet, because it's a five-minute test and it's the single control whose absence makes every other investment irrelevant.

FAQ

What is the biggest change in DDoS attacks recently?

The target shifted from bandwidth to bottlenecks, which means attackers now aim at stateful devices, expensive endpoints, origin addresses that bypass the CDN, and cloud billing models, because those produce far more damage per unit of attacker effort than a large volume flood.

What is a carpet bombing DDoS attack?

It is an attack distributed across a very large number of source addresses so that no individual address ever crosses a per-IP rate limit, while the aggregate volume lands on the target, which is why per-path and per-session limits matter more than per-source limits.

How do attackers find my origin IP behind a CDN?

Through historical DNS records, subdomains that were never proxied, mail servers on the same range, certificate transparency and hostname scanning, error pages that disclose internal addresses, and old infrastructure that still resolves, so origin hygiene needs to be a recurring check rather than a one-off setup.

Can a DDoS attack increase my cloud bill without taking my site down?

Yes, and that is increasingly the point, because autoscaling responds to load and egress is metered, so driving your fleet to its maximum for a few hours produces a financial loss even if availability holds, which is why autoscaling caps and budget alerts are security controls rather than finance controls.

Why does my CDN dashboard show nothing during an attack?

Because the attacker may be hitting your origin directly rather than going through the CDN, which is why restricting inbound traffic to your provider's published ranges and rotating a leaked origin address are essential rather than optional.

Are application layer attacks harder to stop than volume attacks?

They are harder to distinguish, because the requests look like normal traffic and often come from residential addresses, so the effective controls are behavioural rather than signature-based, including per-path baselines, query complexity limits, caching, and challenge-based verification.

Should I pay a DDoS extortion demand?

The general guidance is not to pay, because payment funds further attacks and rarely stops them, but the decision belongs with leadership and legal, and the technical priority in the meantime is mitigation and evidence preservation rather than negotiation.

How do I test whether my defences work?

Run a controlled load test against your own staging environment using a tool like k6 or locust, notify your provider first, and measure where the system breaks, because a runbook that has never been executed is a hypothesis rather than a plan.

Sources:

• Cloudflare (DDoS Threat Report)
• NETSCOUT (DDoS Threat Intelligence Report)