DDoS — Distributed Denial of Service — used to be something only big targets worried about. In 2026 it’s a baseline operational concern for any internet-facing service. Botnets-for-hire start at $5/hour. A motivated competitor or a single angry user can cause real disruption with very little budget.

This post is the application developer’s primer: what DDoS actually is, what kinds of attacks exist, what defenses work at each layer, and how to think about IP-level signals as part of the defense.

What “DDoS” Means

A DoS (Denial of Service) attack tries to make a service unavailable by overwhelming it with traffic or requests. DDoS adds the “distributed” — the attack comes from many sources at once, usually a botnet of compromised devices.

The “distributed” part matters because:

You can’t just block the attacker’s IP — there isn’t one IP, there are thousands or millions.
Source IPs are often legitimate — compromised IoT devices, hijacked servers, infected end-user machines. They look like normal traffic at first glance.
The attack pattern shifts as the botnet rotates IPs.

The Layers of DDoS Attacks

DDoS attacks happen at different layers of the network stack. Each requires different defenses.

Layer 3 / 4: Network and transport

UDP floods — Send massive volumes of UDP packets to fill your bandwidth or saturate your firewall.
SYN floods — Open many TCP connections without completing them, exhausting connection tables.
Amplification attacks — Send small requests to misconfigured servers (DNS, NTP, memcached) that send big responses to your IP.

These attacks measure success in bits per second or packets per second. They saturate your network link before they even reach your application.

Layer 7: Application

HTTP floods — Send millions of “legitimate-looking” HTTP requests, exhausting your web server or backend.
Slowloris — Open many HTTP connections and keep them open slowly, exhausting connection limits.
API abuse — Hammer expensive endpoints (search, AI inference, signup) until they slow down or fall over.

These attacks measure success in requests per second and typically use lower volume than L3/4 attacks. They look more like real traffic, which makes them harder to filter.

Why You Can’t Defend Alone

For all but trivial attacks, defending against DDoS at your origin server is hopeless. Reasons:

Your bandwidth is finite. A 100 Gbps attack against your 10 Gbps link saturates the link before your firewall even sees the packets.
Your upstream ISP can’t help much. They can null-route your IP (drop all traffic to you) but that’s “the attack succeeded.”
Your firewall can’t see L7 attack patterns. Modern attacks look like legitimate HTTP requests.

The practical solution: put a DDoS-protection layer in front of your origin. This layer has the bandwidth, the global presence, and the detection expertise that you, the application developer, do not.

The Standard Stack

In 2026, the standard production stack is:

Cloudflare, AWS Shield, Fastly, or Akamai in front of your origin.
Configurable rate limiting at that layer.
WAF rules for L7 patterns.
Origin hidden so attackers can’t bypass the protection by hitting your IP directly.

This isn’t even particularly expensive. Cloudflare’s free tier protects against most common attacks. AWS Shield Standard is free for AWS customers. Fastly and others have tiered pricing.

The single most impactful security decision for a small/medium business in 2026 is “are we behind a major CDN/DDoS provider?” — and the answer should be yes.

How the Protection Works

DDoS protection services use a combination of:

Anycast capacity

Anycast means the provider has hundreds of POPs worldwide, each absorbing a fraction of the attack. A 1 Tbps attack split across 100 POPs is 10 Gbps per POP — manageable.

Pattern detection

Layer 7 attacks rarely look exactly like real traffic. They have telltale patterns:

Repeated User-Agent strings unique to attack tools
Geographic concentration that doesn’t match your real users
Request-rate distribution that’s “too clean”
Missing headers that real browsers always send

Protection services train on global traffic patterns and detect these in real time.

Challenge / response

For borderline traffic (could be human, could be bot), the protection layer issues a challenge — a CAPTCHA, a JS challenge, a managed challenge — that legitimate browsers pass and attack scripts fail.

Rate limiting

The first line of defense once an attack is in progress. Discussed below.

Rate Limiting as the First Defense

Even without a sophisticated DDoS, rate limiting handles a lot. The pattern:

Per-IP rate limit on sensitive endpoints (login, signup, password reset). Limit to ~10 attempts/minute.
Per-account rate limit on user actions. Limit to ~1000 requests/hour.
Global rate limit to prevent runaway costs. Limit total RPS to your origin to what your infrastructure can handle.

For more on rate limiting design, see rate limiting IP lookup API.

Where IP Geolocation and ASN Help

DDoS protection doesn’t stop at the protection layer. At the application layer, you can use IP geolocation and ASN data to filter intelligently:

Block known hosting providers from user-facing endpoints

Real users browse from residential ISPs and mobile carriers. Real users don’t browse from AWS, GCP, Azure, Hetzner, OVH. Traffic from hosting ASNs on signup or login endpoints is almost always automated.

const HOSTING_ASNS = new Set([16509, 14061, 15169, 8075, 16276])  // AWS, DO, Google, Microsoft, OVH
const result = await convertIP(ip)
if (HOSTING_ASNS.has(result.data.asn.number)) {
    // Apply stricter rate limit or require additional verification
}

Country-based filtering for unusual traffic

If your service is US-only and you suddenly see 90% of signup traffic from Vietnam, something is wrong. You don’t have to block — but you should rate-limit or require additional verification.

VPN / Tor detection

Some fraction of legitimate users use VPNs, but attack traffic is disproportionately VPN-routed. See VPN/proxy blocking for the trade-offs.

The Ip2Geo API returns ASN classification inline, so these checks add ~one API call to the critical path.

Defending Specific Attack Types

HTTP flood

Defense: Rate limiting + WAF rules + CDN caching. Make sure your CDN actually serves cached responses without hitting origin. If every “GET /” hits your backend, a flood scales linearly into the backend. Configure cache properly so static traffic absorbs the flood.

API abuse

Defense: Authentication required + per-account rate limits + cost-based throttling. If endpoint X costs you $0.01 per call (e.g., AI inference), price-throttle: charge or rate-limit unauthenticated users aggressively.

Slowloris

Defense: Connection timeouts + connection limits at the reverse proxy layer. Nginx and modern Apache handle this with reasonable defaults. Don’t run pre-2010 web servers exposed.

UDP flood

Defense: Upstream filtering only. You can’t defend at the origin. Use a DDoS provider or have your ISP null-route during attacks.

Amplification

Defense: Same as UDP flood. Plus: don’t run open DNS resolvers, NTP servers, or memcached publicly — those are what attackers use to generate amplification, and running one makes you part of the problem.

Origin Hiding

If attackers know your origin IP, they can bypass your CDN and hit you directly. Origin hiding is the practice of never publishing the origin IP:

Only allow traffic from your CDN’s IP ranges (Cloudflare publishes its IPs; same for AWS CloudFront, Fastly).
Block all other traffic at the network layer.
Never use the origin IP in error messages, headers, or DNS records.

Without origin hiding, sophisticated attackers can sometimes find the origin by:

Historical DNS records (crt.sh, securitytrails.com)
SSL certificate transparency logs
Old subdomains that don’t go through the CDN
Email server reverse DNS that points back to your infrastructure

A 2026-compliant deployment hides the origin from the start.

When the Attack Is in Progress

If you’re under attack right now:

Confirm it’s actually DDoS. Check traffic patterns, not just “site is slow.” Legitimate viral traffic looks similar but has different signatures (more browser diversity, more geo distribution, more session depth).
Enable maximum protection mode at your CDN (Cloudflare’s “Under Attack Mode,” AWS Shield Advanced auto-mitigations, etc.).
Block or challenge known attack source patterns (specific countries, specific ASNs, specific User-Agents).
Rate limit aggressively even legitimate-looking traffic.
Don’t change DNS unless you have to — DNS changes propagate slowly, and the attacker may already have the new IP.
Capture data while the attack runs — IPs, ASNs, request patterns. Useful post-mortem.

For a serious sustained attack, escalate to your DDoS provider’s incident response — they have tools and bandwidth you don’t.

Cost of Protection vs Cost of Outage

A common decision: “do we need DDoS protection?”

The math:

CloudFlare Free — protects against most common attacks, costs $0.
Cloudflare Pro ($20/month) — better WAF, more rate-limiting options.
Cloudflare Business ($200/month) — uptime guarantees, sustained-attack support.
AWS Shield Advanced ($3000/month + traffic) — for enterprise-grade SLAs.

Compared to the cost of being offline during a viral moment or under an attack, the free or low-tier protection pays for itself a hundred times over. There’s almost no reason for a public-facing service in 2026 to not be behind a major DDoS-protected CDN.

TL;DR

DDoS attacks come at layer 3/4 (network) or layer 7 (application). Different defenses for each.
You cannot defend at the origin for serious attacks. Put a CDN/DDoS layer in front.
Cloudflare/CloudFront/Fastly handle most cases — even on free tiers.
Rate limit per-IP, per-account, globally. First line of defense.
Use ASN data to block hosting traffic on user-facing endpoints.
Hide your origin IP. Don’t let attackers bypass your protection.
WAF + caching + rate limits stop the bulk of L7 attacks.
During an attack, enable max protection mode and capture data for post-mortem.

DDoS protection is one of those areas where 2026’s defaults are dramatically better than 2016’s. Most attacks are stopped automatically by the CDN layer before your application sees them. The remaining work is application-level signals like ASN-based rate limiting and fraud detection — and that’s where IP intelligence APIs like Ip2Geo fit in.

DDoS Protection Basics for Application Developers