A denial of service (DoS) attack makes an application, service, or network resource unavailable to legitimate users by overwhelming systems with traffic, requests, or state transitions. In a distributed denial of service (DDoS) attack, the attacker coordinates traffic from many sources (often botnets) to amplify volume and complicate blocking. One common denial of service attack example is a flood of repeated HTTP requests that prevent real users from loading a website.
While DoS/DDoS primarily threaten availability rather than confidentiality, they frequently coincide with other malicious activity: They can distract defenders, take advantage of operational chaos, or drain capacity and budget exactly when you need both.
How denial of service attacks work
Most DoS/DDoS techniques exploit three forms of exhaustion:
Bandwidth exhaustion: Flooding saturates network capacity
Resource exhaustion: Burning CPU, memory, file descriptors, or connection pools
State exhaustion: Draining the connection/session state until capacity is exhausted
Attackers often harness botnets, compromised IoT devices, infected desktops, and open proxies or misconfigured servers. Volumetric attacks (more on these soon) frequently rely on reflection and amplification. By setting the packets’ source IP to the victim’s address, an adversary can send small requests to “reflector” services, such as open DNS resolvers, that reply with much larger responses to the victim, concentrating a flood that’s cheap to trigger and expensive to absorb.
Quickstart Template for Cloud Incident Response
We've created this template with a stronger focus on the needs of cloud security operations teams.
Attack layers and defenses
DoS attacks target different layers of the OSI model, requiring layer-specific defenses:
L3/L4 (Network/Transport layer): Volumetric attacks like UDP floods and SYN floods consume bandwidth and connection state. Defend with cloud DDoS services (AWS Shield, Azure DDoS Protection, Google Cloud Armor) that scrub traffic at the network edge before it reaches your infrastructure.
L4/Session layer: Protocol attacks like TCP state exhaustion and TLS handshake floods drain connection pools and CPU. Defend with SYN cookies, connection rate limits, and TLS session resumption to reduce handshake overhead.
L7 (Application layer): HTTP floods, API abuse, and slowloris attacks exhaust application resources and database connections. Defend with WAF rate-based rules, API gateway throttling, CAPTCHA challenges, and application-level circuit breakers.
DoS vs. DDoS attacks: Understanding the difference
Both DoS and DDoS aim to knock services offline, but their core difference is the number of systems the malicious activity stems from.
A DoS attack originates from a single host or a small set of sources, often making attribution and blocking straightforward with local controls (think firewall rules, WAF policies, or per-IP rate limits).
DDoS attacks, on the other hand, involve a high number of botnets and reflectors that span many networks and geographies. Source IPs churn, spoofing is common, and traffic surges arrive from numerous edges. That’s why detection must focus on behavioral patterns—burst shapes, protocol anomalies, and reflector fingerprints. Mitigation usually requires upstream scrubbing via cloud DDoS protection services, dynamic edge rules, and, when needed, coordinated provider actions such as RTBH (Remotely Triggered Black Hole routing). RTBH instructs upstream routers to drop all traffic destined for a specific IP address, effectively taking that resource offline to protect the broader network infrastructure.
Protecting against DoS in cloud environments
Cloud providers offer native protections that can absorb and filter traffic before it reaches your infrastructure (AWS Shield, Azure DDoS Protection, Google Cloud Armor). These services form the foundation of denial of service attack protection in a cloud environment.
Beyond implementing CSP protections, there are some nuances of DoS attacks in the cloud that you should keep in mind:
Autoscaling can add capacity during legitimate surges and blunt some L7 floods, but without strict limits and budgets, it can also convert attack traffic into runaway spend, resulting in an economic denial of sustainability (aka EDoS) attack.
The public edge works best as a coordinated tier: The CDN caches static content and offloads origin servers, the WAF challenges suspicious requests and applies rate-based rules to block floods, and the load balancer performs active health checks every 5–30 seconds to detect degraded backends and automatically fails over to healthy instances. This layered approach ensures traffic reaches only responsive, properly functioning servers.
Detecting denial of service attacks
Effective detection hinges on streaming telemetry and fast feedback loops.
Ingestion matters: Ingest WAF logs, load balancer logs, flow data, and service metrics into a low-latency pipeline where threshold rules, anomaly detection, and protocol-aware heuristics can flag abnormal bursts promptly.
Tuning matters: Thresholds should account for fault and seasonal patterns, and alert logic should be mapped to MITRE ATT&CK techniques—specifically T1498 (Network Denial of Service) for volumetric attacks and T1499 (Endpoint Denial of Service) for application-layer attacks. Platforms that unify WAF/LB logs, runtime telemetry, and identity context in a single security graph reduce false positives by correlating DoS signals with real exposure and asset criticality. For example, a traffic spike to a public-facing marketing site with no sensitive data receives lower priority than the same spike targeting an internet-exposed database with customer PII.
Watch 12-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
Prevention and mitigation strategies
Prevention and mitigation work best when they’re systematic, measurable, and baked into the request path. The aim is to slow, deflect, or cheapen hostile traffic at every hop—and to fail gracefully when saturation is unavoidable.
When combined and tuned together, these controls deliver resilience:
Defense in depth and tiered rate-limits: Apply rate limits at API gateway, WAF, and application layers, with strict per-IP/per-token quotas and adaptive backoff.
Cloud DDoS services: AWS Shield, Azure DDoS Protection, and Google Cloud Armor provide automatic edge mitigation through globally distributed Anycast networks. These services activate protection automatically when attacks are detected—no manual pre-warming is required. Controls include traffic scrubbing, rate limiting, and protocol validation at the network edge before traffic reaches your infrastructure.
WAF rate-based rules: Cap requests, block known malicious patterns, and throttle abusive behaviors.
Bot management and challenges: Implement CAPTCHA/JS challenges, device fingerprinting, and behavioral scoring to filter automation while minimizing user friction.
Circuit breaker patterns: Temporarily shed load or defer expensive routes when backends degrade; serve stale-while-revalidate or static fallbacks.
Cache hardening: Aggressively cache, normalize headers/query params, and avoid cache-busting pitfalls.
Geo/IP allowlisting and RTBH considerations: Restrict sensitive/internal tools to known IP ranges or geographic regions. Apply geofencing to block regions where you have no legitimate customers. When using provider-coordinated RTBH (remotely triggered black hole routing), understand that it drops all traffic to the targeted IP address—both malicious and legitimate. Reserve RTBH for non-critical endpoints or as a last resort when other mitigation methods fail, since it creates a complete service outage for the blackholed resource.
Private access for internal services: Replace public exposure with PrivateLink (AWS), Azure Private Link (Azure), and Private Service Connect (GCP).
7 Best Incident Response Plan Templates for Security Teams
Access top incident response plan templates for your security team, find out which are cloud native, and learn how you can respond faster to minimize damage.
Leggi di più
Common DoS defense mistakes to avoid
Many organizations invest heavily in DoS defenses, yet still leave avoidable gaps in place. These are the most common pitfalls that quietly weaken real-world resilience:
Incomplete coverage or ignoring critical components: Many teams lock down the perimeter but leave L7 protections underdeveloped. This creates an easy opening for HTTP-level or state-exhaustion attacks. Every layer, from the network to the application, needs proper DoS safeguards.
Network misconfigurations and routing gaps: Misconfigured firewalls, load balancers, and DNS paths can unintentionally expose weak spots. Regular audits and controlled tests help uncover routing issues, bypass paths, or filtering gaps before attackers do.
Assuming protection is automatic: Cloud-native DDoS defenses are powerful, but they aren’t a full strategy by themselves. Relying on default protection without adding rate limits, WAF rules, or traffic shaping leaves risks unaddressed.
Poor visibility and resilience: Limited monitoring or missing redundancy make it harder to detect an attack early and recover quickly. Strong observability and built-in failover keep systems stable even under pressure.
Neglecting to have a plan and regular exercises: Without a clear incident response plan and periodic simulations, teams often react slowly or inconsistently when an attack actually hits.
Incident response for denial of service attacks
Preparedness is the difference between scrambling and executing. Predefined runbooks should name owners and escalation paths, outline first-hour actions (tighten WAF rate limits, apply temporary LB routing or capacity changes, harden cache policies), and set circuit-breaker thresholds. They should also define EDoS guardrails, like autoscaling and budget alarms, to cap economic exposure.
Leverage platform-driven automation to execute these actions directly from detections—for example, automatically enabling bot challenges when HTTP request rates exceed 5,000 per minute, or temporarily reducing autoscaling maximums when cost anomalies are detected. This automation reduces response time from minutes to seconds and ensures consistent execution, even during high-stress incidents.
After attacks, run a post-incident review. Preserve WAF/LB/CDN and flow/DNS logs, export DDoS reports from providers, snapshot relevant configurations, and rebuild a UTC-timestamped timeline. Use findings to tune rules, refine scaling policies, and close gaps. Adhere to digital forensics and incident response best practices to ensure evidence is complete and the chain of custody is clear.
How Wiz detects and responds to cloud-native DoS attacks
Wiz accelerates detection, triage, and post-incident hardening while maintaining a zero noise posture to minimize false positives. Here’s how:
To pinpoint attempted DoS attacks, Wiz Defend monitors workloads across VMs, containers, serverless, and managed services, establishing behavioral baselines and surfacing anomalies that indicate volumetric spikes, protocol misuse, or resource exhaustion. Armed with this info, the Wiz Security Graph correlates infrastructure, application, and identity signals, differentiating genuine traffic surges from hostile floods and prioritizing protection for the most critical assets.
Wiz Attack Surface Management (ASM) provides clear visibility into external exposures and identifies potential attack paths, misconfigurations, and vulnerabilities that could be exploited in DoS attacks. This includes assessing "denial of wallet" risks from misconfigured storage and overly permissive data-transfer paths that can be abused to drive up bandwidth and egress costs during an attack. ASM helps teams reduce unnecessary exposure and strengthen defenses preemptively.
The Wiz Sensor is a lightweight agent deployed in your cloud environment that continuously monitors resource usage, runtime signals, and process behavior. These runtime indicators enrich Wiz Defend detections and accelerate triage during active attacks. By providing real-time visibility into workload stress patterns, the Wiz Sensor helps distinguish benign scaling events from early signs of a DoS attack.
Through native integrations with WAFs and load balancers, detections can drive automated responses, such as tightening rate limits or enabling bot challenges.
Ready to see for yourself? Schedule a demo today to explore how unified, graph-driven detections and automated responses reduce DoS noise while protecting critical services. See how Wiz correlates DoS signals with asset exposure, identity permissions, and vulnerability context to prioritize the attacks that pose real business risk.
Protect Everything You Build and Run in the Cloud
Learn what makes Wiz the platform to enable your cloud security operation
