What a Cloud DDoS Simulation Actually Validates

A DDoS cloud simulation is a controlled, authorized exercise, not an attempt to overwhelm the cloud provider’s global infrastructure. If you run AWS Shield Advanced or Azure DDoS Network Protection, the practical question is whether that protection performs as expected inside your architecture, against the attack vectors that could realistically reach it.

This article covers what a cloud DDoS simulation validates, where the provider’s responsibility ends, and yours begins, and how to tell whether a vendor is challenging your defenses or simply running a generic volumetric flood. For the engagements themselves, see Red Button’s AWS DDoS testing and Azure DDoS testing services.

Key Takeaways

• Validate the deployment, not the product.
  Shield Advanced and Azure DDoS Network Protection are validated by how they behave around your workload, not by what the datasheet claims.
• “Mitigated” is not a result.
  A useful test measures detection time, mitigation time, legitimate-user impact, and recovery – an attack can be blocked and still cost several minutes of customer-facing degradation.
• The gap is usually between the layers.
  In both case studies below, the provider’s network-layer protection worked exactly as designed while the application layer stayed exposed.
• Vectors follow the architecture.
  A catalog of 100 attack vectors proves nothing. The selection, and the reason behind each selection, is what makes a test meaningful.

A Cloud DDoS Simulation Validates the Whole Path

A cloud DDoS simulation establishes whether your service stays available while the protection stack and the operational teams respond to realistic attack traffic. The result cannot be reduced to whether a provider dashboard labels an attack “mitigated.” A meaningful test evaluates five things:

• Did the cloud platform, WAF, CDN, or monitoring system identify the traffic as an attack?
• Did the relevant control block or reduce the traffic, and how quickly?
• Service availability. Could legitimate users still reach the application, complete transactions, and call its APIs?
• Did the attack cause latency, errors, resource exhaustion, or uncontrolled autoscaling before mitigation activated?
• Operational response. Did alerts reach the right teams, and were escalation and recovery procedures followed as planned?

These outcomes have to be assessed across the complete traffic path, including exposed endpoints and dependencies that sit outside the primary protection layer. An attack can be eventually blocked and still cause several minutes of customer-facing degradation. This is why joint guidance from CISA, the FBI, and MS-ISAC on understanding and responding to DDoS attacks treats detection, response, and post-incident recovery as parts of one capability rather than as a filtering problem alone. A test that reports only pass or fail has measured one of the five.

The Provider Protects the Platform; You Configure the Workload

Cloud DDoS protection follows a shared-responsibility model. AWS frames its own version as security of the cloud versus security in the cloud: AWS is “responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud,” while customer responsibility “will be determined by the AWS Cloud services that a customer selects,” explicitly including firewall and security-group configuration and any application software the customer deploys. Azure applies the same division. The provider supplies capacity and mitigation capability; you decide which resources are covered, how traffic reaches them, and how application-layer controls and response procedures are set up.

Protection area	Cloud provider’s role	Customer’s role	What the simulation establishes
Network layer (L3/L4)	Network capacity, traffic monitoring, and mitigation for volumetric and protocol attacks	Enabling the appropriate protection, including the correct resources, and configuring routing and traffic paths	Whether the provider detects and mitigates the attack before it disrupts the protected workload
Application layer (L7)	Services such as WAFs, CDNs, managed rule sets, and rate-limiting capabilities	Policies, thresholds, API exposure, caching, origin protection, and application-specific rules	Whether realistic HTTP or API attacks are blocked without preventing legitimate users from reaching the service
Operations and response	Telemetry, alerts, mitigation data, and provider support	Monitoring, escalation paths, runbooks, and recovery procedures	Whether the organization detects, understands, and responds to the incident quickly enough

The distinction matters because surviving a network flood demonstrates nothing about resilience against an application-layer attack. The two categories target different resources and depend on different controls, as Red Button’s guide to application-layer DDoS attacks sets out in detail. Where both are relevant to the architecture, a cloud test covers both. The broader case for treating validation as a layer distinct from protection is made in DDoS testing vs DDoS protection.

Validate Shield Advanced and Azure DDoS Protection As Deployed, Not As Products

The validation principle is identical on both platforms: test the protection as it sits around your workload, not as an isolated cloud product. Attack scenarios, monitored components, and success criteria all reflect the architecture that users and attackers actually reach.

Validating Azure DDoS Protection

Azure DDoS Protection is offered in two tiers: DDoS Network Protection, the plan-based tier many teams still call “Standard,” and DDoS IP Protection, a pay-per-protected-IP model built on the same core mitigation engine but without four things Network Protection includes: rapid-response support, cost protection, the WAF discount, and the automatic coverage that Azure DDoS infrastructure protection – the free baseline, formerly called Basic – extends to your other public IPs. Which tier you run changes what is in scope, so confirm it before scoping the test.

For either tier, the test confirms that the relevant public-facing resources are genuinely covered and that network-layer mitigation activates without unacceptable impact on the application. Metrics, diagnostic logs, alerts, service availability, and the operations team’s response are all monitored during the exercise.

Microsoft restricts who may generate that traffic. Its simulation testing guidance permits testing only through approved partners, only “against Azure-hosted public IP addresses that belong to an Azure subscription of your own, which will be validated by our partners before testing,” and only where “these target public IP addresses must be protected under Azure DDoS Protection.” Microsoft also recommends testing “in staging environments or during nonpeak hours.”

Red Button tests against either tier – Network Protection or IP Protection – since Microsoft’s guidance does not name a specific tier, only that the target public IP must be covered. One practical caveat: raising test rates above Azure’s default caps requires the customer’s Microsoft account team and a rapid-response ticket, and rapid response is a Network Protection benefit only, so that escalation route is weaker for an IP Protection target.

Where the architecture includes Azure Application Gateway, Azure WAF, Azure Front Door, or public APIs, the scope extends to application-layer scenarios. Mitigating an L3/L4 flood validates the network protection and nothing more; it does not establish that the application layer withstands realistic HTTP or API attacks. Red Button’s Azure DDoS testing challenges the platform controls and the way they have been configured for the specific deployment.

Validating AWS Shield Advanced

An AWS test reflects the complete deployment, whether traffic passes through CloudFront, an Application Load Balancer and EC2, or API Gateway and Lambda. The simulation measures when Shield detects and mitigates the attack, whether AWS WAF and rate-based rules respond correctly, whether the origin stays protected, and what legitimate users experience while mitigation is active.

An incident-response fire drill validates escalation procedures, but it answers a different question from an independent attack simulation. Verifying how Shield Advanced protects a real workload requires exercising the controls with authorized attack traffic and architecture-specific scenarios. Red Button is one of the APN partners pre-approved under the AWS DDoS Simulation Testing Policy and conducts AWS DDoS testing within the traffic ceilings and conditions that policy defines.

Vector Selection Follows the Architecture, Not a Catalog

A realistic DDoS simulation does not begin with a standard list of attacks. Vector selection follows an analysis of the architecture, the exposed services, normal traffic patterns, business-critical workflows, and the specific control each scenario is meant to challenge.

A test may include:

• Volumetric attacks, to assess upstream mitigation, bandwidth protection, and the ability to absorb sustained traffic floods.
• Protocol attacks, to challenge connection handling and stateful components such as firewalls, load balancers, and network services.
• Application-layer attacks, to determine whether legitimate-looking HTTP or API requests can exhaust application resources without ever triggering volumetric defenses.

For an environment protected by AWS WAF, a large network flood on its own establishes almost nothing. A meaningful test adds application-layer scenarios tied to the deployment: attacks against exposed APIs, resource-intensive application functions, rate-limited endpoints, and requests engineered to reach the origin through normal traffic paths. The question being answered is whether WAF rules, rate limits, caching, bot controls, and backend protections work together without blocking legitimate users.

Red Button maintains more than 100 attack vectors, but the size of the repository is not what makes a test realistic. The value comes from selecting and adapting the vectors most likely to expose weaknesses in the target environment, which is why Red Button begins with a white-box review of the architecture, protection tools, traffic flows, and risk tolerance before defining the test plan.

How to Spot a Superficial Simulation

Ask the vendor to explain, before the engagement is signed:

• Why each attack vector was selected.
• Which protection layer and failure mode it is meant to test.
• How the attack will be escalated, and how it will be stopped safely.
• Which application and security metrics will be monitored.
• How legitimate-user impact and false positives will be measured.
• What distinguishes full mitigation from delayed or partial mitigation.

A high-volume flood followed by a pass/fail summary demonstrates that one network control activated. It does not validate the resilience of a cloud environment.

The Most Useful Findings Sit Between the Layers

The most valuable cloud DDoS findings are rarely cases where the provider’s protection failed. Far more often, one protection layer performs exactly as designed while another part of the workload stays exposed.

Azure: Network Protection Held, the Application Layer Did Not

A Big Four accounting firm ran an Azure DDoS Protection Plan alongside Azure WAF on Application Gateway. Red Button designed six simulations: three targeting the network layer, three targeting the application layer.

Azure detected and mitigated all three network-layer attacks. None of the three application-layer attacks was detected or mitigated. The HTTPS GET attacks caused server downtime until they were terminated, and a large-file-download scenario consumed server resources for roughly ten minutes without interruption. Successful L3/L4 mitigation had not made the application safe.

The recommendations were architectural rather than product replacements: deploy Azure Front Door for application-layer protection with rate limiting and geo-filtering, and configure custom rate-limit rules on Azure WAF. In the retest, five of six application-layer scenarios were mitigated. The sixth still succeeded because of a misconfigured caching header, a fault no product decision would have surfaced. The firm’s DDoS Resiliency Score moved from 1.5 to 5.0. The full Azure case study covers both rounds.

AWS: A Valid API Request Walked Through Every Control

In a test conducted for a bank running on AWS, Shield Advanced was active with Layer 7 auto-mitigation enabled. Several simulated attacks appeared to be absorbed by API Gateway, though only because of the rates used; higher rates would have reached the origin servers. One scenario behaved differently. A simulated GET flood built from valid API requests passed through every protection layer and took the service down.

The root cause was architectural. The mobile application was published through a Regional API Gateway configuration with no CloudFront distribution in front of it, so Shield Advanced’s application-layer mitigation did not apply to that path. A WAF was present but carried no rules relevant to the test. Red Button recommended placing CloudFront in front of API Gateway to extend Shield Advanced protection, adding rate-based AWS WAF rules, and enabling automated protection against scanners and probes. The AWS case study records a DDoS Resiliency Score of 4.0 at the time of testing.

Neither test produced a verdict on whether Azure or AWS “works.” Both identified where the provider’s protection ended and where the customer’s architecture or configuration needed to change.

Production Simulation Is Controlled, Not Risk-Free

A DDoS simulation exists to reveal how the real environment behaves under attack, which is why many organizations test production rather than a simplified staging environment. Staging lowers operational exposure, but it rarely reproduces production’s routing, capacity, protection policies, third-party dependencies, or application behavior.

The risk is managed through a controlled process:

• A review of the architecture and a baseline of normal traffic.
• A precisely defined scope and an approved test plan.
• A coordinated testing window and named escalation contacts.
• Gradual increases in traffic rather than an immediate full-scale attack.
• Agreed traffic ceilings and acceptable-impact thresholds.
• Continuous monitoring of both security controls and user-facing services.
• An emergency stop procedure that ends the simulation immediately, and a named person authorized to invoke it.

The objective is not to claim that a live test carries no risk. It is to bound that risk, identify degradation early, and stop before it exceeds the limits agreed with the customer. Planned and monitored properly, a production test produces evidence a sandbox cannot: whether the actual service, protection stack, and response teams hold up under realistic attack conditions.

Validate the Workload, Not Just the Product

The relevant question is not whether AWS, Azure, Cloudflare, or any other provider offers robust DDoS protection. It is whether that protection has been configured, integrated, and validated for your workloads and for the attack vectors most likely to reach them.

Client time follows the same shape as any Red Button managed engagement: roughly five hours in total, with the live test itself typically running about three hours. The full cycle – from planning through execution to the final report – is usually completed within two months.

A well-designed simulation provides independent evidence of what is protected, where the gaps remain, and what has to change before a real attacker tests the same assumptions.
Talk to Red Button’s DDoS experts about defining the right test scope for your cloud architecture.

 

Frequently Asked Questions

Are DDoS simulation tests legal?

DDoS simulation testing is lawful when it is explicitly authorized, limited to an agreed scope, and conducted in line with the relevant cloud, hosting, ISP, and mitigation-provider policies. Written permission, defined targets, traffic limits, and stop procedures are established before any traffic is generated. Red Button’s guide to the legal requirements for DDoS simulation testing covers the applicable law in more detail.

Is a DDoS simulation the same as load testing?

No. Load testing measures how an application performs under high volumes of expected, legitimate use. A DDoS simulation uses hostile traffic patterns to evaluate attack detection, mitigation, protection bypasses, availability, and operational response. Red Button sets out the distinction in its comparison of DDoS testing, stress testing, and penetration testing.

Do AWS or Azure need to be notified before a simulation?

Prior approval and notification are separate questions. The AWS DDoS Simulation Testing Policy states that pre-approved APN partners “are authorized to conduct DDoS simulation tests on behalf of AWS customers without prior approval from AWS,” provided the test stays inside the published traffic limits. Red Button is one of those pre-approved partners. Microsoft lists Red Button as an approved Azure simulation partner for the Azure Public cloud, but its guidance sets conditions rather than a blanket exemption: targets must be public IPs in your own subscription, validated by the partner beforehand, and protected under Azure DDoS Protection. Eligibility and coordination are therefore confirmed during scoping. Internal change-management, compliance, and third-party approvals may apply regardless.

Does a passing network-layer result mean my cloud workload is protected?

No. Network-layer mitigation and application-layer protection are separate controls with separate configurations. In the Azure engagement described above, all three network-layer attacks were mitigated, and all three application-layer attacks succeeded, in the same environment on the same day. If the architecture exposes HTTP endpoints or APIs, a test that omits application-layer scenarios has left the more likely failure mode unmeasured.