How to Run an Authorized DDoS Test in AWS and Azure

An authorized DDoS test in AWS or Azure begins by confirming that you own the target, that the relevant DDoS protection service covers it, and that an approved partner will conduct the simulation within the provider’s policy. Under those conditions, separate prior approval is generally not required from AWS or Microsoft. AWS does require an exception request when a test falls outside its published conditions.

This guide covers the approved routes on both platforms, including eligibility, lead times, vendor requirements, and pre-test logging. For the engagements themselves, see Red Button’s AWS DDoS testing and Azure DDoS testing services. For the objectives and limitations of the exercise, see what a cloud DDoS simulation actually validates.

Key Takeaways

• Ownership and authorization are separate questions.
  Owning the application does not authorize testing against infrastructure the cloud provider also controls. Both approvals are required.
• The approved-partner route is what removes the approval step, not a general exception for DDoS testing.
  Outside that route, both providers’ default posture is closer to prohibition than permission.
• Neither provider publishes a lead time for the approved-partner route.
  AWS publishes one only for its exception process – a 14-day minimum for non-approved vendors or out-of-limits tests.
• Partner status confirms eligibility, not quality.
  It is what gets a test authorized. It says nothing about whether the vectors, controls, and reporting are worth paying for.
• Regulated data and MSP-managed accounts add a consent layer, not a technical one.
  Neither provider’s approved-partner eligibility criteria mention data sensitivity or account management structure – the gap is who has the authority to say yes.

Why Cloud DDoS Testing Is Sensitive

In an on-premises environment, you have direct control over the target and network path, although ISP and mitigation-provider rules may still apply. When using a public cloud service provider (CSP), traffic passes through infrastructure the provider controls, and other tenants also depend on. The cloud provider therefore has an independent stake in the traffic that crosses its network, which is exactly why AWS and Microsoft each publish a separate approval route for this specific type of test rather than folding it into general penetration-testing terms.

DDoS simulation is also governed differently from other security and performance tests:

Test type	Primary purpose	Cloud requirement
Penetration test	Identify exploitable security weaknesses	Follow the provider’s penetration-testing rules
Load or stress test	Measure application capacity under legitimate traffic	Follow load-testing and acceptable-use policies
DDoS simulation	Test attack detection, mitigation, and response	Use the provider’s approved DDoS testing route

DDoS simulation is the one category both Microsoft and AWS treat as presumptively prohibited outside a named exception. Microsoft’s own Security Testing Rules of Engagement list denial-of-service testing among prohibited activities and state that “Distributed Denial-of-Service (DDoS) attacks are strictly prohibited under all circumstances” – a blanket rule that the Azure DDoS Protection simulation-testing program exists specifically to carve an exception into. Running a DDoS-shaped test without going through that exception is not a gray area; it is the activity the general rule was written to prohibit.

AWS vs. Azure DDoS Authorization Requirements

Both providers permit controlled simulations, but their exception rules differ.

Requirement	AWS	Azure
Standard route	AWS-approved DDoS Test Partner	Microsoft-approved simulation partner
Eligible target	Shield Advanced Protected Resource, or an eligible edge-optimized Amazon API Gateway endpoint	Customer-owned Azure public IP protected by Azure DDoS Protection, in the Public cloud only
Separate provider approval	Not required for a compliant test by an approved partner	No separate customer request under the approved-partner route
Exception	Available for a non-approved vendor or a test outside the technical limits	Testing outside the approved simulation route is prohibited
Provider lead time	AWS exception request: at least 14 days before the test	No separate Microsoft approval period is published
Approved vendors	NCC Group, RedWolf Security, Red Button, and Safedash Analytics	MazeBolt, Red Button, and RedWolf

Partner status allows the vendor to use the provider’s recognized route and keeps the traffic from being treated as unauthorized activity in the first place. AWS’s own Acceptable Use Policy prohibits using its services “to violate the security, integrity, or availability of any user, network, computer or communications system, software application, or network or computing device” — language broad enough to cover exactly the traffic pattern a DDoS test generates. The approved-partner route is what keeps an authorized test from reading, to the provider’s own systems and policies, as the thing it is designed to detect. Traffic sent outside that route has no such standing: it may be treated, mitigated, and reported on as a genuine attack, which defeats the test and exposes the account to the same scrutiny as an unauthorized denial-of-service attempt.

Vendor lists and technical conditions can change. Check the current AWS DDoS Simulation Testing Policy and Azure DDoS Protection simulation-testing guidance before scheduling a test.

The AWS Route: Approved Partner, Eligible Target, Published Limits

On AWS, the customer must use an AWS-approved DDoS Test Partner and own the target. The target must be registered as a Protected Resource in a Shield Advanced account or be an eligible edge-optimized Amazon API Gateway endpoint in such an account.

No prior AWS approval is needed when an approved partner stays within these restrictions:

• No more than 20 gigabits per second.
• No more than 5 million packets per second for CloudFront, or 50,000 packets per second for other AWS resources.
• No more than 50,000 requests per second.
• No traffic originating from AWS resources, and no use of AWS resources for amplification.

A test outside those limits, or one conducted by a vendor that is not approved, requires an AWS exception request at least 14 days before the proposed date. This is a submission deadline, not a guaranteed approval time – AWS does not publish a maximum turnaround, so an out-of-limits or non-approved-vendor test should be scoped with schedule slack beyond the 14-day minimum, not against it.

Confirm that every target is actually registered under Shield Advanced; hosting a CloudFront distribution, load balancer, or public endpoint in AWS does not make it a Protected Resource automatically. Red Button’s AWS DDoS testing service follows the approved route for eligible customer-owned resources.

The Azure Route: Approved Partner and a Validated Public IP

An Azure simulation must run through a Microsoft-approved partner. The target must be an Azure-hosted public IP that belongs to the customer’s subscription and is protected by Azure DDoS Protection.

That validation is not independent technical verification – there is no WHOIS lookup or DNS challenge behind it. It combines the customer’s own attestation with the cloud provider’s eligibility gate. In practice: the customer signs a DDoS Test Agreement warranting that it has the legal right to test the target systems, or has obtained that right from the legal owner; a named, titled approver signs off the specific target list in the test plan; and the customer remains responsible for notifying and securing approval from its own ISP, hosting, cloud, and mitigation providers. The provider’s own gate then does the technical enforcement: on AWS, the target must sit inside a Shield Advanced Protected Resource in an account the customer owns, and an exception request asks for the WAF Web ACL ARN as practical proof; on Azure, the approved partner confirms the public IP belongs to the customer’s own subscription before any traffic is generated. Ownership, in other words, is established by warranty and named sign-off, backed by the provider’s own eligibility check – not by independent technical verification.

The approved-partner route also applies to the Public cloud only – Microsoft’s guidance notes that Red Button, for example, is available there and not in Azure Government or other sovereign cloud environments, which matters for regulated customers scoping a test in advance.

The customer does not submit a separate request asking Microsoft to approve the date, and Microsoft publishes no fixed authorization lead time. Preparation time instead depends on target validation, planning, logging, internal approval, and change control.

This is narrower than it first sounds, and the narrowness is deliberate. Microsoft’s general penetration-testing rules prohibit independent DoS or DDoS testing outright; permission to test your own application does not override that restriction, because the restriction was never about ownership of the application in the first place. The Azure DDoS Protection simulation-testing program is the specific, named exception, and it only covers traffic that runs through one of the three approved partners against a validated, protected target. Verify every public IP rather than assuming that the existence of a DDoS Protection plan means it is covered. Red Button is a Microsoft-approved partner providing Azure DDoS testing against validated customer-owned resources.

Whichever platform is in scope, one rule-of-engagement step applies regardless: agree acceptable impact, named contacts, and emergency stop conditions in writing before any traffic is generated.

Testing Through a Reseller, Partner or Managed Environment

Red Button routinely runs tests where the party paying for the engagement is not the owner of the assets being tested – through a reseller or partner arrangement rather than directly with the end customer. Depending on the partner agreement, either the end customer signs its own test agreement or the partner is authorized to approve on the customer’s behalf; either way, the target still has to sit inside an account the customer itself owns, which AWS enforces structurally through the Shield Advanced Protected Resource requirement.

A managed service provider that actually operates the customer’s infrastructure is a different and rarer case. Whoever holds the credentials – reseller, partner, or MSP – is not automatically the party who can authorize a simulation; that authority should be confirmed in writing before scheduling, not assumed. Shared services supporting other customers must remain outside the scope unless their owners approve them too.

Microsoft’s published eligibility criteria focus on ownership and DDoS protection, not the type of data the application processes, and – as above – on the Public cloud specifically, which is worth confirming early for any financial-services deployment that might sit in a government or sovereign cloud. A regulated financial environment must still satisfy its own regulatory, data-handling, and change-management obligations on top of the provider’s eligibility rules; the two are separate gates, and clearing one does not clear the other. Keep the simulation limited to approved public endpoints; the vendor should not need customer records, credentials, or financial data to run it. Provider compliance and customer authorization remain separate requirements. See the wider legal requirements for DDoS simulation testing.

Logging to Enable Before the Window Opens

Enable and validate logging before the test window. Mitigation can work while the test still produces an inconclusive result if the customer cannot reconstruct what was detected, blocked, or forwarded.

AWS	Azure
Shield Advanced events and CloudWatch metrics	DDoS Protection metrics for every public IP in scope
AWS WAF logging, metrics, and request sampling	Diagnostic Settings routing logs and metrics to Log Analytics
CloudFront, ALB, or API Gateway requests, latency, and errors	An alert on the “Under DDoS attack or not” metric
Origin health, application errors, and autoscaling	Notifications, mitigation reports, and mitigation flow logs
Route 53 health checks and relevant SIEM data	WAF, Application Gateway, Load Balancer, and Application Insights telemetry

The monitoring must also show legitimate-user availability, traffic reaching the origin, and any scaling or dependency bottlenecks.

The single most important item at kickoff is simpler than a logging checklist: customer dashboards should be open and actively watched for the duration of the test – covering the mitigation vendor, network elements, and server health – not reviewed afterward. On AWS, Red Button asks customers to build CloudWatch dashboards for the load balancer, API Gateway, and CloudFront and to set the metric period to the minimum available, specifically to see what is getting past the WAF, and asks outright whether DDoS alerting already exists and what triggers it. Red Button also runs its own external availability monitoring during the test and captures the customer’s monitoring screenshots as evidence.

Confirm dashboard access before the window opens. Timestamp alignment does not require synchronized clocks or a captured baseline in advance – in practice, each vector’s start and stop is announced in a shared communications channel with the customer as the test runs, which is what makes the logs interpretable afterward.

Use the Route the Provider Recognizes

Red Button is an approved DDoS testing partner for AWS and Microsoft Azure. Learn more about its controlled, expert-led DDoS testing services, or contact the team to confirm whether your cloud resources are eligible.

Frequently Asked Questions

Do I need to notify AWS before a DDoS simulation?

No prior AWS approval is required when an AWS-approved DDoS Test Partner tests an eligible resource within the published limits. A non-approved vendor, or a test outside those limits, requires an exception request submitted at least 14 days in advance.

Does Microsoft require advance approval for an Azure DDoS simulation?

Microsoft publishes no separate approval request or notice period for testing through an approved simulation partner. The partner must first validate that the customer owns the target and that Azure DDoS Protection covers it, and the route applies to the Azure Public cloud only.

Which vendors are approved for both AWS and Azure?

Red Button and RedWolf currently appear on both providers’ approved-vendor lists. Confirm the lists against the current provider policies when planning the test, since vendor status can change.

How long does cloud-provider authorization take?

There is no provider approval queue for a standard test through an approved partner like Red Button. AWS exception requests must be submitted at least 14 days in advance for a non-approved vendor or an out-of-limits test. Microsoft publishes no separate authorization period for the Azure approved-partner route; the schedule is set by target validation and the customer’s own internal approval process instead.

Can a DDoS simulation run against an Azure environment that hosts regulated financial data?

Yes, provided the target meets Microsoft’s eligibility criteria – a customer-owned public IP in the Azure Public cloud, protected by Azure DDoS Protection, and validated by an approved partner. Data sensitivity is not a criterion in that eligibility check; it is a separate obligation the organization still has to satisfy under its own regulatory and change-management requirements before authorizing the test.

How do we handle a DDoS simulation when our cloud environment is managed by a third-party MSP?

Confirm, in writing, who in the MSP relationship actually has the authority to authorize a simulation – technical access to the account is not the same as that authority. Any shared infrastructure the MSP uses for other customers has to stay out of scope unless those customers’ owners approve it too.