What is a DDoS attack?
A DDoS attack (distributed denial-of-service attack) is a cyberattack that floods a target system with traffic from multiple sources simultaneously, overwhelming its capacity to respond to legitimate requests. When successful, these attacks cause service outages, revenue loss, reputational damage, and can even serve as cover for other malicious activity happening elsewhere in your environment.
The key word is "distributed." Traffic comes from hundreds or thousands of sources at once, including compromised devices and amplification servers. This makes it impossible to stop an attack by simply blocking a single IP address, which is why DDoS attacks are far more dangerous than their single-source predecessors.
Cloud environments face both classic volumetric attacks and newer cloud-native vectors. Attackers now target API endpoints, exploit auto-scaling mechanisms, and abuse serverless functions in ways that traditional perimeter defenses cannot detect. What started as simple bandwidth floods have evolved into sophisticated multi-vector campaigns that hit networks, protocols, and applications simultaneously.
Watch 5-minute demo
Learn about the full power of the Wiz cloud security platform. Built to protect your cloud environment from code to runtime.
Watch now
DoS vs DDoS: What is the difference?
A DoS attack (denial of service) comes from a single source, while a DDoS attack (distributed denial of service) comes from multiple sources. This distinction matters because DoS attacks can often be stopped by blocking one IP address. DDoS attacks require more sophisticated filtering since traffic appears to come from legitimate sources spread across the globe.
Modern attackers typically use distributed methods because single-source attacks are easier to block with basic network controls. Single-source attacks are often easier to mitigate with basic controls such as ACLs and rate limiting, so they're less likely to succeed against organizations with baseline protections in place.
How do DDoS attacks work?
Understanding the attack chain helps you identify where to implement controls and how to recognize an attack in progress. The basic flow follows a predictable pattern: an attacker builds or rents attack infrastructure, identifies a target, launches a coordinated traffic flood, and the target becomes unavailable to legitimate users.
Attackers rarely use their own bandwidth. Instead, they leverage compromised devices or amplification techniques to multiply their impact dramatically. A single attacker with modest resources can generate terabits of traffic by exploiting the right infrastructure.
| Stage | Component | Function |
|---|---|---|
| 1 | Attacker | Initiates and controls the attack |
| 2 | Command & Control | Coordinates botnet or amplification servers |
| 3 | Botnet/Amplifiers | Generates attack traffic |
| 4 | Target Infrastructure | Receives overwhelming traffic |
| 5 | Service Degradation | Legitimate users cannot access services |
Botnets and compromised devices
A botnet is a network of compromised devices controlled by an attacker. These devices include computers, IoT devices like cameras and routers, and even cloud servers. The attacker issues commands through a central infrastructure, and all compromised devices respond by sending traffic to the target.
The Mirai botnet demonstrated how dangerous IoT devices can become. Devices like security cameras and home routers often ship with weak default credentials and rarely receive security updates. Mirai exploited these weaknesses to build one of the largest botnets ever seen, capable of generating over 1 Tbps of attack traffic.
Cloud workloads can also become unwitting botnet participants. If your servers are compromised through vulnerabilities or misconfigurations, attackers may use them to attack others. Botnet-for-hire services, sometimes called DDoS-as-a-service, have lowered the barrier to launching attacks. Anyone with a few dollars can rent attack capacity without building their own infrastructure.
Amplification and reflection techniques
Amplification attacks exploit servers that respond to small requests with much larger replies. An attacker sends a tiny request to a vulnerable server, but spoofs the source IP address to be the victim's address. The server then sends its large response to the victim instead of the attacker. Amplification factors can exceed 50x, meaning 1 Mbps of attacker bandwidth becomes 50 Mbps hitting the target.
Common amplification vectors include:
DNS amplification: Attackers send small DNS queries that generate large responses
NTP amplification: Exploits the monlist command in older NTP servers
Memcached reflection: Misconfigured memcached servers can generate amplification factors over 50,000x
By spoofing the source IP address, attackers hide their true origin while directing massive traffic volumes at victims. These techniques allow attackers with limited bandwidth to generate traffic volumes that would otherwise require significant infrastructure investment.
What are the main types of DDoS attacks?
DDoS attacks fall into three main categories based on which layer of the network stack they target: volumetric, protocol, and application. Modern attacks often combine multiple types in a single campaign to overwhelm different defensive layers simultaneously.
Understanding the type of attack you face helps determine the appropriate mitigation strategy. A volumetric attack requires different defenses than an application-layer attack, and misidentifying the attack type can lead to ineffective response.
1.Volumetric attacks
Volumetric attacks aim to consume all available bandwidth between the target and the internet. The goal is simple bandwidth exhaustion, measured in gigabits per second (Gbps). When attack traffic exceeds your available bandwidth, legitimate traffic cannot get through.
Common volumetric attacks include UDP floods, ICMP floods, and amplification attacks. Defenses typically involve upstream filtering, anycast distribution across multiple data centers, and routing traffic through scrubbing centers that filter malicious packets before forwarding clean traffic.
These are the loudest attacks and often the easiest to identify. Traffic volumes spike dramatically, and network monitoring tools immediately flag the anomaly. However, their visibility also means they can serve as distractions while attackers pursue other objectives.
2. Protocol attacks
Protocol attacks exploit weaknesses in network protocols to exhaust resources on servers or network equipment like firewalls and load balancers. The goal is to consume connection state tables, measured in packets per second (PPS) rather than raw bandwidth.
SYN floods are the classic example. Attackers send TCP connection requests but never complete the handshake, filling up connection state tables with half-open connections. Stateful firewalls struggle because they must track each connection, and attackers can fill these tables faster than legitimate connections complete.
Other protocol attacks include ACK/RST floods that exhaust connection tracking tables and state-exhaustion attacks targeting load balancers and stateful firewalls. These attacks can bring down expensive network equipment with relatively modest traffic volumes because they target specific resource limitations.
3. Application-layer attacks
Application-layer attacks target specific applications with requests that appear legitimate but exhaust application resources. The goal is to consume CPU, memory, or application-specific resources, measured in requests per second (RPS).
Examples include:
HTTP floods: Overwhelming web servers with seemingly valid page requests
Slowloris: Holding connections open by sending partial requests very slowly
API attacks: Targeting expensive API endpoints with computationally intensive requests; for example, Cloudflare reported 197 billion blocked requests to generative AI services over 13 months, highlighting the scale of automated abuse that can include DDoS-like patterns
Authentication attacks including brute force: Flooding login endpoints to exhaust authentication services
These attacks evade volumetric defenses because traffic volume may be low and individual requests look legitimate. Cloud environments face specific vectors including attacks on authentication endpoints, API gateways, or serverless functions that trigger expensive compute operations with each request.
DDoS attack examples
Real-world attacks illustrate how DDoS techniques evolve and what lessons defenders can learn from them.
The Mirai botnet attack in 2016 demonstrated the power of compromised IoT devices. Mirai infected cameras, routers, and other devices using default credentials, building a massive botnet that attacked Dyn, a major DNS provider. The attack took down access to major websites including Twitter, Netflix, and Reddit for hours. The lesson: IoT security matters, and botnets can achieve scale that overwhelms even well-prepared infrastructure.
The GitHub memcached attack in 2018 set traffic records at the time by exploiting misconfigured memcached servers. Attackers achieved amplification factors exceeding 50,000x, generating 1.35 Tbps of attack traffic. GitHub survived because they quickly routed traffic through a scrubbing service. The lesson: amplification techniques can generate unprecedented traffic volumes, and third-party infrastructure you do not control can be weaponized against you.
Recent hyper-volumetric attacks have exceeded 29.7 Tbps, showing continued evolution in scale and sophistication. Attackers combine multiple techniques, shift vectors during attacks, and use increasingly sophisticated evasion methods. The threat landscape continues evolving faster than many defenses can adapt.
How to detect a DDoS attack?
Early detection enables faster response and reduces impact on your services. The challenge lies in distinguishing attacks from legitimate traffic spikes or internal misconfigurations that cause similar symptoms.
Common symptoms include sudden service degradation, unusual traffic patterns, and resource exhaustion alerts. Users may report slow response times or complete inability to access services. Your monitoring systems may show CPU or memory exhaustion, connection failures, or error rate spikes.
Network-level indicators
Network symptoms typically appear first in volumetric and protocol attacks. Look for sudden traffic volume spikes, unusual geographic distribution of incoming traffic, and protocol anomalies like unexpected UDP traffic to services that should only receive TCP.
Monitoring approaches include NetFlow analysis to understand traffic patterns, traffic sampling at network boundaries, and baseline comparison against normal traffic profiles. When current traffic deviates significantly from established baselines, investigate immediately.
Network monitoring has limitations. Application-layer attacks that use low traffic volumes may not trigger network-level alerts. You need visibility at multiple layers to catch sophisticated attacks.
Workload and application-level indicators
Application symptoms include CPU and memory exhaustion, container restarts, serverless function timeouts, error rate spikes, and increased latency. These indicators matter because sophisticated attacks may not generate enough traffic to trigger network alerts.
Cloud-native monitoring should track workload health metrics alongside network traffic. Watch for pods being evicted due to resource limits, functions hitting timeout thresholds, and database connections being exhausted. Application performance monitoring (APM) tools can identify which specific endpoints or services are under stress.
Distinguishing DDoS from legitimate traffic or misconfigurations
Viral content, product launches, or marketing campaigns can cause legitimate traffic spikes that look similar to attacks. The difference lies in user behavior patterns. Legitimate traffic shows recognizable patterns like session duration, page navigation, and geographic distribution consistent with your user base.
Attack traffic often displays uniform request patterns, unusual user agents, requests to non-existent endpoints, or geographic distribution that does not match your typical users. Attackers rarely perfectly mimic legitimate behavior.
Misconfigurations can also cause self-inflicted denial of service. Infinite retry loops, runaway batch jobs, or misconfigured auto-scaling can overwhelm your own systems. Baseline behavior and context help distinguish external attacks from internal problems.
How to prevent DDoS attacks?
Proactive measures reduce your attack surface and minimize impact before attacks occur. No single control prevents all DDoS attacks, so defense-in-depth is essential. Layer multiple protections so attackers must overcome several obstacles to succeed.
Reduce your attack surface
Fewer exposed endpoints means fewer targets for attackers, effectively shrinking your attack surface. Review your public-facing infrastructure regularly and ask whether each exposed service truly needs to be public.
Practical actions include:
Close unnecessary ports: If a service does not need to be reachable from the internet, do not expose it
Restrict public exposure: Use private endpoints and VPC service endpoints where possible
Implement network segmentation: Limit what attackers can reach even if they breach perimeter defenses
Attack surface monitoring: Regularly scan for misconfigurations that expand your target area
Assign explicit ownership: Make sure every internet-exposed endpoint has an owner and documented justification; otherwise it becomes a permanent, unmonitored DDoS target
Many successful attacks exploit services that should not have been publicly accessible. A misconfigured security group or forgotten test environment can become the entry point for an attack.
Implement rate limiting and traffic shaping
Rate limiting restricts the number of requests from a single source within a time window. This prevents any single client from consuming excessive resources, whether due to attack or misconfiguration.
Application-level controls include API throttling, connection limits, and authentication rate limits. If your login endpoint can only process 10 requests per second per IP, attackers cannot easily flood it with thousands of authentication attempts.
The balance matters. Too aggressive limits block legitimate users, especially those behind shared IP addresses like corporate NAT. Too permissive limits allow attacks to succeed. Adaptive rate limiting that adjusts based on traffic patterns can help find the right balance automatically.
Use cloud-native DDoS protection services
Major cloud providers include DDoS protection in their offerings, but coverage varies by tier:
AWS Shield:
Shield Standard (free, automatic): Protects against common network-layer (L3/L4) attacks on all AWS resources
Shield Advanced ($3,000/month): Adds 24/7 DDoS Response Team access, cost protection, and application-layer (L7) detection
Azure DDoS Protection:
Basic (free, automatic): Network-layer protection for all Azure resources
Standard (usage-based pricing): Adds adaptive tuning, attack analytics, and cost guarantee
Google Cloud Armor:
Standard (per-policy pricing): WAF rules and L7 DDoS protection for load-balanced traffic
Managed Protection Plus: Adds DDoS response support and advanced rate limiting
Cloud provider protections are a baseline, not a complete solution. Application-layer attacks targeting custom API logic or authentication flows typically require additional WAF rules tailored to your specific application behavior.
How to mitigate a DDoS attack in progress?
When an attack is underway, response measures aim to restore service while the attack continues. Preparation dramatically improves response speed. Runbooks, relationships with providers, and practiced procedures make the difference between minutes and hours of downtime.
Traffic filtering and scrubbing
Scrubbing centers are specialized infrastructure that filters malicious traffic before forwarding clean traffic to your servers. During an attack, you route traffic through the scrubbing provider, which uses pattern matching, rate limiting, and behavioral analysis to separate attack traffic from legitimate requests.
Upstream filtering involves working with your ISPs or CDN providers to block attack traffic before it reaches your infrastructure. Many providers can implement null routes or traffic filters at their network edge, stopping attacks before they consume your bandwidth allocation.
CDNs and WAFs play important roles in filtering application-layer attacks. By distributing traffic across many edge locations and applying request filtering rules, these services can absorb and filter attacks that would otherwise overwhelm origin servers.
Blackhole routing
Blackhole routing (also called null routing) directs all traffic to a targeted IP address into a "black hole" where it is discarded. This is a last-resort measure when you need to protect the rest of your infrastructure from collateral damage.
Use blackhole routing when a specific IP or service is under heavy attack and the attack is affecting other services. By sacrificing the targeted service, you protect everything else.
The trade-off is significant. Blackhole routing stops the attack but also blocks all legitimate traffic to that destination. You are essentially taking the service offline yourself rather than letting the attacker do it. This may be acceptable for non-critical services but is rarely desirable for customer-facing systems.
Scaling and absorbing the attack
Cloud auto-scaling can help absorb some application-layer load, but it won't mitigate attacks that saturate upstream bandwidth, exhaust shared edge/state resources, or overwhelm dependencies like databases. If you can scale faster than the attack grows, you may maintain availability by absorbing some of the traffic, though attacks can reach peaks of 270,000 requests per second sustained over 8-hour periods. Auto-scaling groups, serverless functions, and elastic load balancers can all expand capacity automatically.
Cost considerations are serious. Scaling to absorb attack traffic can result in massive cloud bills. This is sometimes called "wallet denial" because attackers cause financial damage rather than availability damage. A sustained attack against auto-scaling infrastructure can generate costs that far exceed the business value of the attacked service.
Scaling works for short attacks when you have sufficient budget and can outpace the attacker. It creates new problems for sustained attacks or when budget constraints exist. Combine scaling with other defenses rather than relying on it alone.
Incident response coordination
DDoS response requires coordination across multiple parties. You may need to communicate with cloud providers, ISPs, CDN providers, and internal teams including operations, security, and communications.
Pre-established runbooks and relationships make coordination faster. Know who to contact at your providers, what information they need, and what actions they can take. Document escalation paths and contact information before you need them.
During the incident, isolate affected services where possible, communicate status to stakeholders, and preserve evidence for later analysis. Log everything. After the incident, conduct post-mortem analysis to identify how similar attacks can be prevented or mitigated faster in the future.
How Wiz helps detect and prevent DDoS
Wiz Defend provides workload-level visibility into the impact of traffic spikes and resource-exhaustion patterns, going beyond packet-level monitoring to show which workloads and dependencies are affected. While network tools show traffic volumes, Wiz shows which critical workloads are experiencing resource exhaustion, what data they can access, and what identity permissions are involved, enabling prioritized response based on business impact rather than just packet counts.
Wiz Defend combines eBPF-powered runtime signals, deep analysis of cloud and SaaS logs, and agentless risk context so you can detect emerging threats faster and understand the full story of the attack path and potential blast radius in minutes. This combination means you see both the attack itself and any related suspicious activity happening elsewhere in your environment.
The correlation capabilities are particularly valuable for identifying whether a DDoS is a standalone incident or a smokescreen for other activity like lateral movement or data exfiltration. The incident timeline helps reconstruct events and determine if configuration drift or vulnerabilities preceded the outage, informing both immediate response and longer-term remediation.
Get a demo to see how Wiz helps teams understand DDoS impact in cloud context: what's affected, what's at risk, and what to fix first.