Containers

Kubernetes DDoS Protection | Stop Attacks Now

Secure your Kubernetes infrastructure with proven DDoS prevention, detection, and mitigation strategies

By InventiveHQ Team

To stop DDoS attacks on a Kubernetes cluster, absorb volumetric traffic at the edge with a CDN or cloud DDoS service, throttle requests at the ingress controller, segment the cluster with NetworkPolicies, and cap your autoscalers so an attack cannot inflate your cloud bill. No single control is enough: edge scrubbing (Cloudflare, Fastly, AWS Shield, Google Cloud Armor) stops the volume, ingress rate limits protect the application layer, Calico or Cilium NetworkPolicies block malicious ranges and lateral movement, and hard HPA/node ceilings defeat Economic Denial of Sustainability (EDoS) attacks that weaponize your own auto-scaling.

That is the summary an AI Overview would give you. Here is what it cannot show you: where in the request path each control actually fires, why autoscaling is a liability rather than a defense, and the exact manifest changes that separate a resilient cluster from a bankruptcy-by-billing. The animated defense-in-depth diagram below traces a malicious packet from the internet to your pods and shows which layer stops it — followed by a copy-paste mitigation checklist and the specific YAML that caps an EDoS attack.

Kubernetes clusters, with their dynamic scaling and cloud-native design, offer incredible flexibility and resilience. But these same features can also be exploited by attackers. DDoS campaigns can overwhelm your system's resources, disrupt operations, and even exploit your auto-scaling capabilities to inflate cloud costs—an insidious new tactic known as an Economic Denial of Sustainability (EDoS) attack.

Defense-in-depth layers for Kubernetes DDoS protection A malicious packet travels from the internet through the CDN edge, ingress rate limiting, NetworkPolicies, and capped autoscaling before reaching pods. Each layer stops a share of the attack. Kubernetes DDoS Defense in Depth Each layer absorbs part of the flood so less reaches your pods Internet attack + real traffic 1. CDN / Edge Cloudflare, Fastly, AWS Shield, GCP Armor Absorbs volumetric L3/L4 floods ~90% of volume stopped 2. Ingress Limit NGINX limit-rps limit-connections Throttles L7 HTTP per source IP 429 excess rejected 3. NetworkPolicy Calico / Cilium ipBlock deny rules Blocks bad CIDRs + lateral movement deny known-bad ranges 4. Autoscale Cap HPA maxReplicas node-group limit Stops EDoS / Yo-Yo bill spike $ cap budget protected Healthy Pods
Advertisement

How DDoS Attacks Target Kubernetes

External Threats

Your Kubernetes cluster's public-facing services, such as exposed APIs or web applications, are the most common targets for external attackers. These entry points are vulnerable to being bombarded with illegitimate traffic:

  • SYN Flood Attacks: Exploit the handshake process in TCP connections
  • HTTP-Based DDoS Attacks: Flood web-facing services with massive numbers of fake requests

Internal Threats

If an attacker gains access to your cluster, they can escalate the attack from within. Kubernetes' default networking allows lateral movement, making it possible for attackers to infect other workloads and amplify the damage.

Economic Denial of Sustainability (EDoS)

The Yo-Yo Attack is one of the newest and most insidious forms of DDoS attacks. Attackers generate sudden traffic spikes, triggering Kubernetes' auto-scaling mechanisms, then back off, forcing your system into a constant loop of scaling up and down—like a yo-yo—without any real user activity.

Critical Threat: EDoS Attacks

While traditional DDoS attacks aim to disrupt availability, EDoS attacks exploit cloud-native auto-scaling to drain your budget. By driving up compute, storage, and bandwidth costs, attackers can harm your business without ever taking down your systems.

Which Defense Layer Stops Which Attack

No single control covers every attack type. The value of defense-in-depth is that each layer catches what the previous one missed. Use this to decide where to invest first based on the threats you actually face.

Defense layerStops (attack type)Where it runsWhen to reach for it
CDN / edge scrubbing (Cloudflare, Fastly, AWS Shield, GCP Armor)Volumetric L3/L4 floods, most HTTP floodsBefore your origin, globally distributedAlways — this is the first thing to put in front of any public endpoint
Ingress rate limiting (NGINX limit-rps)L7 HTTP floods, slow request abuseAt the cluster edge, per source IPWhen you have public APIs/web apps and need per-client throttling
Web Application FirewallMalicious request patterns, bad bots, L7 exploitsEdge or ingress sidecarWhen attacks are request-shaped, not just high-volume
NetworkPolicy (Calico / Cilium)Lateral movement, known-bad CIDRsInside the cluster, per podFor internal segmentation and surgical IP blocking
Autoscaler caps (HPA maxReplicas, node limits)EDoS / Yo-Yo bill inflationControl planeAlways — the one control that protects your budget, not uptime
Baseline monitoring (Prometheus + Grafana)Detection of all of the aboveObservability stackAlways — you cannot mitigate what you cannot see

Which should you do first? If you run public services and have none of these, put a CDN in front of every endpoint today and cap your autoscalers before the weekend — those two controls stop the largest and the most expensive attacks respectively, and neither requires touching application code.

DDoS Prevention Strategies

Network-Level Protections

  • Web Application Firewalls (WAFs): Google Cloud Armor, AWS Shield, or Azure DDoS Protection
  • Rate Limiting: Set limits on ingress traffic using NGINX annotations
nginx.ingress.kubernetes.io/limit-rps: '10'
nginx.ingress.kubernetes.io/limit-connections: '2'

Zero Trust Network Policies

Adopt a zero-trust approach using tools like Calico or Cilium to enforce strict network policies. Control which external traffic is allowed into your cluster and restrict outgoing traffic to limit potential data exfiltration.

Global Traffic Distribution

CDNs like Cloudflare and Fastly are designed to handle massive amounts of traffic, making them ideal for absorbing and mitigating DDoS attacks. They route traffic through globally distributed networks, offloading surges from your Kubernetes cluster.

Detection and Mitigation

Key Metrics to Monitor

  • CPU and Memory Usage Spikes: Sudden surges often signal malicious traffic
  • Increased Inbound Traffic: Abnormally high volume of requests to specific services
  • Baseline Monitoring: Establish normal traffic patterns for rapid anomaly detection

Symptom to Cause to Fix

When an alert fires at 2 a.m., you need the mapping from what you see to what to do — not a lecture on DDoS theory. Use this triage table.

Symptom you observeLikely causeImmediate fix
Inbound request rate 10x+ baseline to one serviceL7 HTTP flood on a public endpointTighten limit-rps on that Ingress; enable CDN "under attack" mode
HPA scaling to max, then back down, in a loopYo-Yo / EDoS attack on autoscalingLower maxReplicas temporarily; add cost anomaly alert; block source at edge
CPU/memory spike with no traffic increaseCompromised pod amplifying internallyIsolate with a deny-all NetworkPolicy; audit pod for lateral movement
Ingress returning mass 429/503Rate limits doing their job (or overwhelmed)Confirm legit users aren't blocked; push scrubbing upstream to CDN
Cloud bill spikes but service stays upEDoS — the attack you don't noticeEnforce node-group max; review Cluster Autoscaler ceilings
Traffic from a tight set of CIDRsBotnet with limited source rangeBlock the range via NetworkPolicy ipBlock and edge firewall rules

Immediate Mitigation Actions

  • Temporarily reduce rate limits on ingress controllers
  • Identify and block attacking IPs with Network Policies
  • Capture and analyze traffic patterns using tools like tcpdump
  • Implement packet capture for forensic analysis
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-malicious-traffic
spec:
  podSelector: {}
  ingress:
  - from:
    - ipBlock:
        cidr: 203.0.113.0/24

Best Practice: Use tools like Prometheus and Grafana for real-time monitoring, or integrate with Calico for comprehensive network visibility and anomaly detection.

Cost Controls for EDoS Protection

Protect your budget from Economic Denial of Sustainability attacks by implementing proper cost controls:

  • Optimize Autoscaling: Configure HPA and Cluster Autoscaler with sensible limits
  • Enforce Resource Limits: Use resource requests and limits in pod specifications
  • Set Maximum Scaling Boundaries: Define maximum pod limits to control resource allocation
resources:
  requests:
    memory: "256Mi"
    cpu: "500m"
  limits:
    memory: "512Mi"
    cpu: "1"

Elevate Your IT Efficiency with Expert Solutions

Transform Your Technology, Propel Your Business

Protect your Kubernetes clusters from sophisticated DDoS attacks with proven defense strategies. At InventiveHQ, we help you implement comprehensive security measures that safeguard your infrastructure and your bottom line from evolving cyber threats.

Secure Your Kubernetes Cluster

Frequently Asked Questions

How do I stop a DDoS attack on my Kubernetes cluster?

Stop the flood before it reaches the cluster. Layer defenses in this order: (1) put a CDN or scrubbing provider (Cloudflare, Fastly, AWS Shield, Google Cloud Armor) in front of every public endpoint so volumetric traffic is absorbed at the edge; (2) enforce rate limits at the ingress controller (nginx.ingress.kubernetes.io/limit-rps and limit-connections); (3) apply Kubernetes NetworkPolicies with Calico or Cilium to deny malicious source ranges and block lateral movement; and (4) cap the Horizontal Pod Autoscaler and Cluster Autoscaler with maxReplicas and node limits so an attack cannot balloon your bill. Never rely on autoscaling alone to "absorb" a DDoS — that is exactly what an EDoS attacker wants.

What is an EDoS or Yo-Yo attack in Kubernetes?

Economic Denial of Sustainability (EDoS) is a DDoS variant that targets your cloud bill instead of your uptime. The Yo-Yo attack sends a burst of traffic to trigger autoscaling, backs off once new pods and nodes spin up, then repeats — forcing the cluster to scale up and down in a loop while you pay for compute that served no real users. Because the service often stays technically available, EDoS can run undetected for days. Fixed HPA ceilings, node-group maximums, and cost anomaly alerts are the primary defense.

Do Kubernetes NetworkPolicies stop DDoS attacks?

Partially. NetworkPolicies (enforced by Calico, Cilium, or your CNI) are excellent for blocking known malicious CIDRs and stopping lateral movement between pods, which contains an attacker who already has a foothold. But they are not volumetric scrubbers — a large layer-3/4 flood will saturate your network links before a NetworkPolicy rule is evaluated. Use NetworkPolicies for internal segmentation and targeted IP blocking, and pair them with an edge CDN or cloud DDoS service for volumetric protection.

How do I rate limit ingress traffic in Kubernetes?

With the NGINX Ingress Controller, add annotations to the Ingress resource: nginx.ingress.kubernetes.io/limit-rps sets requests per second per client IP, and nginx.ingress.kubernetes.io/limit-connections caps concurrent connections. For example, limit-rps '10' allows ten requests per second per source. Start conservative on public endpoints and tune against your real baseline traffic. For API-level throttling with quotas and burst allowances, an API gateway or service mesh (Istio, Kong) gives finer control than ingress annotations alone.

Can autoscaling protect against a DDoS attack?

No — treating autoscaling as DDoS protection is a trap. Scaling out to meet malicious demand keeps the service up but hands the attacker exactly what an EDoS campaign wants: an unbounded cloud bill. Autoscaling should have hard ceilings (HPA maxReplicas, Cluster Autoscaler node maximums) so it absorbs legitimate spikes but refuses to chase an attack. Real DDoS protection happens at the edge, before traffic reaches the pods that would trigger scaling.

What metrics indicate a DDoS attack on Kubernetes?

Watch for a sudden, sustained spike in inbound request volume to specific services, CPU and memory surges that do not match business hours, a jump in HPA scaling events or new node provisioning, rising ingress controller 429/503 rates, and connection counts far above your established baseline. The key word is baseline — anomaly detection only works if you already know what normal looks like. Prometheus plus Grafana (or Calico's flow logs) give you the request-rate and per-pod resource visibility needed to spot the deviation early.

Should I use a WAF or a CDN to protect Kubernetes from DDoS?

Use both — they solve different layers. A CDN (Cloudflare, Fastly) absorbs volumetric layer-3/4 floods across a globally distributed network before traffic ever hits your origin. A Web Application Firewall inspects layer-7 HTTP traffic and blocks application-layer attacks like HTTP floods, bad bots, and malicious request patterns. Cloud DDoS services such as AWS Shield, Azure DDoS Protection, and Google Cloud Armor often bundle both. The CDN handles the raw volume; the WAF handles the intelligent, request-shaped attacks that slip through.

How do I block a specific IP range during an attack in Kubernetes?

Apply a NetworkPolicy with an ipBlock rule that excludes the attacking CIDR, or invert it to allow only trusted ranges. NetworkPolicies require a CNI that enforces them (Calico, Cilium — the default kubenet does not). For faster mitigation of large ranges, block at the edge (CDN firewall rules or cloud security groups) since that stops the traffic before it consumes cluster bandwidth. Cluster-level NetworkPolicies are best for surgical, in-cluster blocking and long-term segmentation.