Velocity Stream LogoVelocity Stream Logo
Back to Insights
Security Engineering

Defending Against Layer 7 DDoS Attacks at the Edge

How we fortified a heavily targeted API by implementing intelligent, multi-layered edge rate limiting, stopping attacks before they hit the Kubernetes ingress.

When a rapidly growing fintech API went viral, it attracted more than just legitimate customers. Within hours, the platform was hit by a sophisticated Layer 7 (application layer) DDoS attack. The attackers weren't trying to overwhelm the network pipe with raw UDP garbage; they were slowly, methodically sending expensive database-heavy GraphQL queries to exhaust the RDS connection pool.

The existing AWS WAF was struggling to differentiate between the surge in legitimate mobile app traffic and the highly distributed botnet. The Kubernetes Ingress controller (NGINX) was dropping legitimate requests, and CPU utilization across the microservices was pegged at 100%.


The Architecture of Defense

We were brought in to stabilize the platform. Our strategy was to move the compute-heavy burden of request validation and rate limiting as far away from the origin servers as possible—specifically, to the edge.

Layer 1: Cloudflare Advanced Rate Limiting

The first line of defense was moving the DNS to Cloudflare and implementing Advanced Rate Limiting. We couldn't just limit by IP address, as the botnet was rotating through thousands of residential proxies.

Instead, we implemented a composite key strategy. We created a Cloudflare Worker that analyzed the incoming GraphQL request payload. If the query contained a specific, highly expensive nested query (which the attackers were abusing), the request was aggressively rate-limited based on a combination of ip.src and the http.request.headers.authorization token.

// Cloudflare Custom Rule Expression
(http.request.uri.path eq "/graphql" and 
 http.request.body contains "expensiveQuery") 
-> Rate Limit: 10 requests per 1 minute

Layer 2: NGINX Ingress Rate Limiting

While Cloudflare handles the distributed volumetric attacks, we needed a second layer of defense within the Kubernetes cluster itself to protect individual microservices from "noisy neighbors" (legitimate clients sending too many requests).

We configured the NGINX Ingress Controller using annotations to implement a leaky bucket algorithm:

nginx.ingress.kubernetes.io/limit-rps: "50" nginx.ingress.kubernetes.io/limit-burst-multiplier: "2" nginx.ingress.kubernetes.io/limit-connections: "20"

Engineering Reality

"The biggest challenge wasn't setting up the rate limits; it was tuning them so that valid power-users didn't hit 429 Too Many Requests errors. We ran the Cloudflare rules in 'Simulate' mode for 24 hours, piping the logs to Datadog to model the impact before enforcing them."

The Outcomes

Within 30 minutes of activating the multi-layered defense strategy, the cluster CPU utilization dropped from 100% to 15%.

99.9%
Malicious Traffic Dropped

Cloudflare Workers intercepted and blocked the expensive GraphQL queries at the edge.

0
Database Timeouts

The RDS connection pool stabilized immediately as the application layer was no longer starved for resources.

Verdict

Layer 7 DDoS attacks cannot be mitigated by simple IP blocking or volumetric scrubbing. They require deep packet inspection, application-aware rate limiting, and a multi-tiered architecture that kills bad requests before they ever consume origin compute.

Is your architecture slowing you down?

We specialize in auditing complex cloud environments, eliminating technical debt, and building pragmatic, high-performance infrastructure. Let's simplify your stack.

Chat with an Engineer