DDoS Defense at the API Gateway: Layered Controls and Failure Planning

An API gateway helps defend against application-layer DDoS by authenticating callers, validating requests, bounding rate, concurrency, and body size, and shedding expensive work before it reaches services. It cannot by itself stop an attack that saturates the network link before traffic reaches the gateway. Effective defense places provider, CDN, anycast, or scrubbing capacity upstream; restricts direct access to the origin; and uses the gateway as the application-aware admission layer.

Key Takeaways

• Match each control to the attack layer; one “DDoS protection” switch does not cover every failure mode.
• Stop volumetric floods upstream of the constrained link, not at an origin that traffic has already saturated.
• Prevent bypass by allowing the intended edge path to reach the gateway and protecting the origin address.
• At the gateway, constrain resource cost as well as request count: concurrency, payload size, pagination, batch width, and expensive operations matter.
• Use trusted identity and verified client-address restoration before applying per-client policies.
• Rehearse detection, escalation, mitigation, and recovery while dependencies are degraded.

Start with the Failure Point, Not the Product

CISA's DDoS guidance distinguishes attacks that exhaust bandwidth, protocol or infrastructure state, and application resources. The useful question is not simply “Can the gateway block DDoS?” It is “Which resource becomes unavailable first, and can the control act before that point?”

If a 100 Gbit/s flood reaches a 10 Gbit/s origin path, a gateway behind that path cannot inspect its way out of saturation. Filtering must occur where sufficient capacity exists. Conversely, an upstream network service cannot always tell that one valid-looking GraphQL query or export request is disproportionately expensive. The gateway and application must enforce that semantic boundary.

Use a Layered DDoS Architecture

flowchart LR
    I[Internet] --> E[Provider / Anycast / CDN / Scrubbing]
    E --> L[Load balancer or L4 protection]
    L --> G[API Gateway]
    G --> S[Isolated upstream pools]
    S --> D[(Databases and dependencies)]
    O[Control plane and admin access] -. separate path .-> G

Each layer has a distinct job:

• Provider or distributed edge: absorbs or diverts volumetric traffic and blocks obvious network/protocol floods before the origin link.
• Load balancer/L4 layer: manages connection state, SYN behavior, and transport-level health.
• API gateway: restores trusted identity, authenticates, validates, limits, prioritizes, and observes application requests.
• Application and dependencies: enforce operation-specific invariants, cost limits, authorization, and spending caps.
• Control plane: remains private and operational even when the public data plane is under pressure.

A web application firewall can add signatures and behavioral detection, but it does not replace capacity engineering, authentication, rate limits, or application bounds. For a concrete Apache APISIX integration, see the chaitin-waf plugin documentation.

Prevent Direct-Origin Bypass

An attacker should not be able to discover the gateway or origin address and avoid the upstream defense. Depending on deployment, controls can include:

• network access rules that accept data-plane traffic only from documented edge ranges;
• mutually authenticated connections between edge and origin;
• private connectivity or tunnels;
• removal of stale DNS records and leaked addresses;
• separate, restricted health-check and administrative paths;
• monitoring for traffic arriving outside the intended path.

IP allowlists change and can lock out legitimate traffic if automation fails. Use provider-published ranges, atomic updates, overlap during rotation, and an emergency recovery path. Do not copy a range once and assume it remains current.

Restore the original client address only from a trusted proxy. If the gateway accepts X-Forwarded-For directly from the internet, an attacker can choose the apparent source and evade or frame per-IP rules. Strip untrusted forwarding headers at the first trusted hop and configure address restoration for the exact proxy chain.

Bound Application-Layer Resource Consumption

OWASP API4:2023 identifies unrestricted execution time, memory, file descriptors, upload size, batch operations, pagination, and third-party spending as API risks. DDoS defense must therefore budget work, not merely count packets.

Rate and quota

Apply route- and identity-specific request rates. A password reset, report export, login, and cached catalog read should not share one arbitrary threshold. Use per-tenant or per-credential policy after authentication when possible; IP-only limits can penalize users behind shared networks and are easier for distributed attackers to spread across.

Concurrency

A low request rate can still hold all worker or database slots with slow operations. Use concurrency budgets at expensive routes and upstream pools. Reject before an unbounded gateway or application queue forms.

Request shape and size

Bound body bytes, header size, decompressed size, array length, pagination, GraphQL complexity, batch width, archive expansion, and response size where relevant. Validate these limits again in the application; the gateway may not understand every semantic cost.

Authentication and operation controls

Authentication raises attacker cost and enables fairer attribution, but compromised credentials are still valid credentials. Limit sensitive operations per subject and tenant, detect abnormal use, and make revocation fast. Put financial caps and alerts around SMS, email, AI inference, and other metered dependencies.

Caching

Caching stable public reads can reduce upstream work, but an attacker can defeat naive caches with unique query strings, headers, or keys. Normalize the cache key deliberately, reject meaningless variance, and never cache private responses without correct isolation.

Configure APISIX as the Admission Layer

Apache APISIX 3.18 provides complementary traffic and security plugins. This illustrative route combines request-rate and concurrency controls for a costly public search endpoint:

curl "http://127.0.0.1:9180/apisix/admin/routes/catalog-search" \
  -X PUT \
  -H "X-API-KEY: ${admin_key}" \
  -d '{
    "uri": "/v1/catalog/search",
    "methods": ["GET"],
    "plugins": {
      "limit-req": {
        "rate": 20,
        "burst": 10,
        "key_type": "var",
        "key": "remote_addr",
        "rejected_code": 429
      },
      "limit-conn": {
        "conn": 80,
        "burst": 0,
        "default_conn_delay": 0.1,
        "key_type": "var",
        "key": "server_addr",
        "rejected_code": 503
      },
      "prometheus": {}
    },
    "upstream": {
      "type": "roundrobin",
      "nodes": {
        "catalog.internal:8080": 1
      }
    }
  }'

The numbers and keys are examples. remote_addr is meaningful only after the trusted-proxy design is correct. server_addr demonstrates an instance-oriented safety key, not a single shared fleet counter. Establish values from legitimate bursts, gateway topology, and measured upstream capacity.

The limit-req plugin constrains arrival rate; limit-conn bounds concurrent requests. Use 429 for the caller-facing rate policy and 503 for shared capacity pressure so operators and clients can distinguish the conditions.

For uploads, APISIX's client-control plugin can set max_body_size, but the current documentation states that it requires APISIX-Runtime. Verify that prerequisite for your distribution. Otherwise enforce the body boundary in the supported listener/runtime configuration and again in the application.

APISIX ip-restriction can support an allowlist or denylist, but IP blocking alone is weak DDoS defense: source addresses may be numerous, spoofed at some layers, shared by legitimate clients, or changed. Use it for a well-defined trust boundary such as approved edge ranges, not as the entire incident strategy.

Protect the Gateway Itself

Gateway policies consume resources too. During an attack:

• avoid synchronous logging or remote policy calls on every rejected request;
• sample or aggregate high-volume rejection telemetry without losing incident counts;
• limit high-cardinality labels such as raw IP or unbounded user agent;
• keep configuration distribution and administrative APIs off the public listener;
• reserve capacity for health probes and operator access;
• test certificate and authentication costs under connection churn;
• ensure autoscaling signals arrive before instances are already saturated.

Autoscaling is not DDoS mitigation by itself. Scaling can lag, hit regional quotas, multiply cost, or expand an expensive downstream bottleneck. Put admission controls in front of autoscaling and set budget alerts and hard limits where a provider supports them.

Detect Attacks with Multiple Signals

The APISIX prometheus plugin exports request, status, bandwidth, and latency signals. Combine gateway observations with edge, load balancer, host, and application telemetry:

• packets and bits per second at the provider edge;
• connections opened, established, reset, and timed out;
• requests, unique trusted identities, and geographic/network distribution;
• 429, 503, authentication failures, and validation rejections by route;
• request-size and operation-cost distributions;
• gateway CPU, memory, sockets, event-loop lag, and upstream connections;
• upstream latency, saturation, queue depth, and dependency spending;
• cache hit ratio and cache-key cardinality.

Baseline normal campaigns, releases, partner batches, and mobile retry behavior. A popular launch and an attack can look similar at the edge but require different business decisions. Automate protection for clear safety boundaries while keeping an accountable path for policy escalation.

Build an Incident Runbook

A DDoS runbook should name people, thresholds, and actions before an incident:

1. Detect and classify. Identify the saturated resource, protocols, routes, identities, and regions.
2. Protect control. Confirm operator access, configuration delivery, and observability remain available.
3. Engage upstream help. Know the provider or scrubbing-service escalation channel and information required.
4. Apply reversible policy. Tighten expensive routes or affected identities first; record the change and expiry.
5. Preserve critical traffic. Isolate health, authentication, payment, or operator paths according to business priorities.
6. Communicate. State impact and mitigation without publishing details that help an attacker bypass controls.
7. Recover gradually. Remove emergency rules in stages and watch for a returning attack or retry surge.
8. Review evidence. Update capacity, baselines, allowlists, contacts, and application limits.

Avoid permanent emergency rules with no owner or expiry. They often become a later availability incident.

Test Without Creating an Incident

Coordinate DDoS tests with infrastructure providers and internal security teams. Use authorized environments and traffic volumes. Start with controlled application-layer scenarios:

• a burst within legitimate campaign expectations;
• distributed requests across many source addresses;
• slow, concurrency-heavy requests;
• large but schema-valid payloads;
• repeated costly operations using valid credentials;
• upstream pool loss while traffic remains high;
• log and metric pressure from a high rejection rate.

Verify that controls activate before the protected resource reaches its unsafe point, legitimate critical traffic retains its expected service, alerts identify the layer correctly, and rollback is available. Network-scale simulations require explicit provider coordination; do not point an internet load generator at production without authorization.

DDoS Readiness Checklist

• Which link, state table, worker pool, database, or paid dependency fails first?
• Can volumetric traffic be filtered before that point?
• Can attackers bypass the protected edge and reach the origin directly?
• Are forwarding headers trusted only from known proxies?
• Are rate, concurrency, payload, batch, pagination, and spending limits route-specific?
• Can the gateway reject cheaply without blocking on logs or remote dependencies?
• Are critical routes and operator access isolated?
• Do provider escalation and policy changes have tested owners and procedures?
• Are emergency rules reversible and time-limited?
• Has recovery from the attack and subsequent client retry surge been rehearsed?

Summary

An API gateway is the application-aware part of DDoS defense, not the whole defense. Put high-capacity mitigation before constrained network links, prevent direct-origin bypass, then use gateway identity, validation, rate, concurrency, and size controls to protect application resources. Combine those controls with dependency limits, efficient telemetry, and a rehearsed incident runbook. The result is a layered system that fails deliberately instead of asking one gateway to absorb every attack type.

FAQ

Can an API gateway stop a volumetric DDoS attack?

Not when the attack saturates the network before it reaches the gateway. Provider-edge, CDN, anycast, or scrubbing capacity must filter that traffic upstream. The gateway remains valuable for application-aware admission.

Is per-IP rate limiting enough for API DDoS defense?

No. Distributed attackers use many addresses, while legitimate users may share one address. Combine trusted client-address handling with identity-, route-, concurrency-, payload-, and operation-cost controls.

Will autoscaling solve an application-layer DDoS attack?

Autoscaling can add capacity, but it can lag, hit quotas, increase cost, or overload a fixed dependency. Use explicit admission limits and spending controls as well.

Next Steps

Map the first saturated resource for each public API and confirm where upstream mitigation acts. Then verify the current APISIX rate-limiting and concurrency-limiting options for your deployment. For centrally managed Apache APISIX security policies, explore API7 Enterprise.