Learn Multigress - DDoS Protection & Rate Limiting

#Introduction

Legitimate traffic may be crowded; malicious traffic must be stopped from the start. Episode 14 covers DDoS protection and rate limiting in Multigress: limiting request rates, protecting backends from abusive clients, and building logging and alerting to detect anomalies before they become disasters.

Remember: the gateway is the first line of defense. The earlier you reject bad traffic, the less load reaches your applications and databases.

#Implementing Rate Limiting and Request Throttling

#Local Rate Limit

The simplest rate limiting is local, per proxy instance. Configure it via BackendTrafficPolicy:

apiVersion: gateway.multigress.io/v1
kind: BackendTrafficPolicy
metadata:
  name: api-rate-limit
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: api-route
  rateLimit:
    type: Local
    requests: 100
    unit: Second

The policy above limits requests to 100 per second per proxy instance. Because it's local, the total depends on the number of replicas — this value is divided evenly between pods.

#Global Rate Limit with RateLimitService

If the limit must be accurate at the gateway level as a whole, use a global rate limit. Multigress uses a helper service to count the shared tokens:

helm upgrade multigress multigress/multigress \
  --namespace multigress-system \
  --set ratelimit.enabled=true

apiVersion: gateway.multigress.io/v1
kind: BackendTrafficPolicy
metadata:
  name: api-rate-limit-global
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: api-route
  rateLimit:
    type: Global
    rps: 500

With type: Global, the 500-request-per-second limit is counted across all instances, so it can't be worked around by adding replicas.

#Throttling by Time Unit

Besides per-second limits, you can set burst and per-minute limits. Combining rps with a burst is a common pattern for API applications:

spec:
  rateLimit:
    type: Global
    rps: 100
    burst: 20

The burst value allows short spikes above the average — for example during a flash sale — without immediately rejecting requests.

#Protection Patterns Against Abusive Clients

#Limiting by Client Address

A rate limit per client IP is very effective against simple attacks. Enable a key based on the client address:

apiVersion: gateway.multigress.io/v1
kind: BackendTrafficPolicy
metadata:
  name: client-rate-limit
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: api-route
  rateLimit:
    type: Global
    rps: 10
    key:
      clientAddress: true

Each IP address is limited to 10 requests per second. This ensures one client can't monopolize capacity away from other users.

#Layered Defense Patterns

DDoS protection works in layers:

• IP filtering to automatically block known malicious ranges.
• Rate limiting to slow down clients without stopping the service.
• JWT validation (episode 12) to reject requests without credentials.
• WAF in front of the gateway for malicious payloads.

seq 1 200 | xargs -P 20 -I {} curl -s -o /dev/null -w "%{http_code}\n" \
  http://localhost:8080/api | sort | uniq -c

The seq 1 200 | xargs -P 20 -I {} curl -s command sends 200 parallel requests. Once the limit is passed, you'll see many 429 Too Many Requests codes — a sign the rate limiter is working.

#Logging and Alerting for Traffic Anomalies

#Detecting Anomalies from Metrics

The rate limiter works, but you also need to know when an attack happens. Monitor the multigress_http_requests_total and multigress_http_requests_rejected_total metrics:

sum(rate(multigress_http_requests_rejected_total[5m])) by (reason)

The query above shows the rejection reasons per 5 minutes: due to rate limit, due to policy, or due to resources. A spike pattern in one reason is an early clue to the attack type.

#Alert Rules for Anomalies

Create an alert in Prometheus when the rejection rate suddenly climbs:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: multigress-rejections
  namespace: monitoring
spec:
  groups:
    - name: multigress-traffic
      rules:
        - alert: MultigressRejectionSpike
          expr: |
            sum(rate(multigress_http_requests_rejected_total[5m])) by (route)
            / sum(rate(multigress_http_requests_total[5m])) by (route)
            > 0.2
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "Lonjakan penolakan pada route {{ $labels.route }}"

If more than 20 percent of requests are rejected for 5 minutes, the MultigressRejectionSpike alert fires. This alert connects to Alertmanager to reach the on-call channel — a runbook topic in episode 21.

#Closing

Episode 14 gave you weapons against bad traffic: local and global rate limits, per-client limits, layered defense strategies, and alerting that notifies you early when anomalies occur.

The key takeaways:

• Local rate limits are divided per instance; global ones are counted across instances.
• burst allows short spikes above the average.
• Per-client-address rate limits block clients that monopolize resources.
• Layered defense: IP filtering, rate limiting, JWT, and WAF.
• Rejection spike alerts detect anomalies before backends get overwhelmed.

In the next episode 15 we'll discuss performance tuning & scalability — gateway concurrency and resource sizing, optimizing route evaluation and backend connections, and horizontal scaling with autoscaling for gateway pods. Your rate limiting configuration will be tested under load for the first time.