DDoS Mitigation

DDoS mitigation protects availability when many sources simultaneously send traffic intended to overwhelm a service. The constrained resource might be an internet connection, a connection-tracking table, a web server, or a database behind an apparently inexpensive API request. Successful mitigation is not simply blocking high traffic volumes: it requires distinguishing attack traffic from legitimate demand and keeping critical business functions usable.

Choose edge defenses according to the anticipated attack. Volumetric attacks, including reflection and amplification attacks, attempt to saturate bandwidth and require upstream filtering or a sufficiently distributed provider edge. Protocol attacks, such as SYN floods, target connection establishment and network state. Application-layer attacks use HTTP requests that can resemble legitimate activity but exhaust expensive operations such as searching, authentication, or report generation. A web application firewall can inspect HTTP requests, but it does not replace network-layer DDoS protection.

Cloud architectures typically place managed edge infrastructure in front of regional application resources. A content delivery network distributes incoming requests and serves cacheable responses without contacting the origin. Managed authoritative DNS reduces dependence on a small, self-managed DNS deployment. For non-HTTP applications, a distributed network entry point can provide an appropriate protected path without relying on HTTP-specific controls. Multi-zone application capacity improves resilience, but it cannot compensate for an unprotected upstream bottleneck.

For example, an online store can cache product images and public catalog pages at the edge while applying application-layer rate controls to login and search endpoints. Requests to checkout may require separate thresholds because legitimate customers have different usage patterns there. Request aggregation can use IP addresses or other supported attributes, but IP-only limits can penalize users behind shared NAT gateways, while a widely distributed botnet may remain below each individual IP threshold. Challenge mechanisms must also account for API clients that cannot execute browser challenges.

Prevent attackers from bypassing the protected entry point. Where supported, use private origins; otherwise restrict origin network access and verify that requests arrive through the intended distribution. Merely changing the public DNS record to point at a CDN does not protect an origin that remains directly reachable. Security groups and network ACLs reduce exposure, but rules close to the application cannot recover bandwidth already saturated farther upstream.

In AWS scenarios, distinguish automatic network and transport-layer protection from configurable HTTP filtering and enhanced incident-response capabilities. AWS Shield Standard provides baseline protection automatically, while Shield Advanced adds capabilities for eligible protected resources, including enhanced detection, response assistance, and conditional DDoS-related cost protection. AWS WAF supplies application-layer controls. Do not assume that purchasing enhanced protection automatically enrolls every resource, configures application-specific rules, or eliminates all attack-related charges.

Capacity and operational controls remain essential. Autoscaling can absorb some demand, but scaling alone can increase costs or move the bottleneck to a database. Use caching, bounded concurrency, timeouts, and load shedding to limit work per request. Monitor request rates, error rates, latency, cache hit ratios, and backend saturation together. During an incident, inspect edge logs and mitigation metrics, check for origin bypass, and tune rules cautiously to avoid blocking legitimate traffic. Maintain an escalation runbook and conduct testing only within provider policies and authorization requirements.