Cloud penetration testing rules: what AWS, Azure and Google Cloud allow

Three positions, and why they differ

A cloud provider runs one estate for every customer. That single fact produces every rule below. A test that only touches your own account is a customer matter; a test that consumes shared capacity, reaches another tenant, or probes the platform itself is not. Each provider has drawn that boundary in its own way, and the wording is worth reading rather than summarising, because the wording is what an abuse team will quote back at you.

Amazon Web Services takes a service-scoped approach: it publishes a list of services you may assess without advance permission, a list of activities that are prohibited outright, and a category of “simulated events” that need a form filed two weeks in advance. Microsoft takes a rulebook approach: no pre-approval for Azure since 15 June 2017, but a single Unified Penetration Testing Rules of Engagement document that binds every test and every tester. Google Cloud takes a boundary approach: no notification at all, provided you stay inside your own projects and comply with the Acceptable Use Policy and the Terms of Service.

The practical consequence is that the same engagement can need paperwork on one provider and none on another, and that a multi-cloud assessment has to be scoped against three documents rather than one.

The three published positions at a glance

	AWS	Microsoft Azure	Google Cloud
Pre-approval for an ordinary test	Not required for the listed services	Not required since 15 June 2017	Not required
Notification	Not required for permitted services	Explicitly not required	Not required
Prior approval needed for	Simulated events, two weeks in advance	DDoS only, and only via approved partners	Nothing, but terms still bind
Denial of service	Prohibited	Prohibited under all circumstances	Must not affect other customers
Third-party tester	Account owner authorises	Explicit written authorization from the resource owner	Must stay inside your projects
Authoritative document	Customer Support Policy for Penetration Testing	Microsoft Cloud Unified Penetration Testing Rules of Engagement	Acceptable Use Policy and Terms of Service

AWS: a named list, a hard no, and a form

AWS is the only one of the three that enumerates services. Customers may carry out security assessment or penetration testing against the following, without advance permission: Amazon EC2 instances, WAF, NAT Gateways and Elastic Load Balancers; Amazon RDS; Amazon CloudFront; Amazon Aurora; Amazon API Gateways; AWS AppSync; AWS Lambda and Lambda Edge functions; Amazon Lightsail resources; Amazon Elastic Beanstalk environments; Amazon Elastic Container Service; AWS Fargate; Amazon OpenSearch Service; Amazon FSx; Amazon Transit Gateway; Amazon Bedrock AgentCore; and AWS Global Accelerator.

The prohibited list is short and absolute. It covers DNS zone walking via Amazon Route 53; DNS hijacking via Route 53; denial of service and distributed denial of service; port flooding; protocol flooding; request flooding, which AWS spells out as login request flooding and API request flooding; S3 bucket takeover; and subdomain takeover. None of these becomes permissible because the account owner asked for it. They are platform-level prohibitions, not client-level ones.

Between the two lists sits the simulated-events category. Red, blue or purple team testing with command and control, DDoS simulation testing, iPerf network testing, simulated phishing campaigns and malware testing all require a request submitted through the Simulated Events form. The timing requirement is explicit: all simulated event requests must be submitted to AWS at least two weeks in advance of the start date. A red-team engagement that plans to stand up a C2 channel inside an AWS account therefore has a two-week lead time built into its schedule, and that lead time belongs in the proposal rather than in the week before delivery.

Microsoft Azure: no approval, but a rulebook that binds

Microsoft’s documentation is unusually direct about the change: as of June 15, 2017, Microsoft no longer requires pre-approval to conduct a penetration test against Azure resources, and the process applies only to Microsoft Azure and does not apply to any other Microsoft Cloud Service. Notification is no longer required either. What replaced approval is a single document: customers and authorized third parties must comply with the Microsoft Cloud Unified Penetration Testing Rules of Engagement, and Microsoft is explicit that the rules of engagement are the authoritative source while the documentation article is a summary.

The rules do more than restrict. They name activities Microsoft encourages within your own assets: creating test accounts or trial tenants to evaluate cross-account or cross-tenant security scenarios; performing fuzzing, port scanning or vulnerability assessments on your own Azure virtual machines; generating traffic to test surge capacity within your applications; testing your tenant’s security monitoring and detection systems; evaluating Conditional Access or mobile application management policies; attempting to break out of shared service containers such as Azure Websites or Azure Functions; and attempting to break out of AI system boundaries. For a tester, that list is a scoping aid: it tells you which questions Microsoft considers legitimate to ask of its own platform.

The prohibitions are correspondingly firm. Denial of service testing of any kind is out, including tests that determine, demonstrate or simulate DoS, and Microsoft states that DDoS attacks are strictly prohibited under all circumstances. Accessing, scanning or testing Azure tenants, systems, logs, data or storage accounts you do not own or have explicit permission to test is prohibited. So is using, accessing or retrieving credentials or other secrets that are not your own, and the documentation is careful to include credentials that have leaked publicly. Network-intensive fuzzing or automated testing that generates excessive traffic is prohibited. Phishing and social engineering are prohibited both against Microsoft employees and through Microsoft services against anyone else.

The last prohibition is the one that most often surprises red teams. Post-compromise or post-exploit actions against Microsoft online services beyond an initial proof of concept are prohibited: no enumerating internal networks, no dumping secrets, no executing further code, no lateral movement, no pivoting. If a test finds a genuine flaw in Microsoft’s platform, the correct next step is to stop and report it to the Microsoft Security Response Center. Where a tester accidentally reaches data that is not theirs, the instruction is to stop immediately, notify MSRC with the details and delete the data.

For DDoS resilience there is a sanctioned route rather than a prohibition with no alternative. Microsoft names simulation partners for controlled testing: MazeBolt, Red Button and RedWolf. Any resilience claim that needs load behind it goes through one of them.

Google Cloud: stay inside your own projects

Google’s position is the shortest of the three and the easiest to misread as an absence of rules. No notification to Google is required before conducting penetration testing on your own Cloud Platform infrastructure. Two obligations survive that: you must abide by the Cloud Platform Acceptable Use Policy and Terms of Service, and you must ensure that your tests only affect your projects and not other customers’ applications.

The second obligation is the operative one. A test that reaches a shared service, another project or another customer breaches it regardless of intent, and the phrasing puts the responsibility for ensuring that on the customer rather than on the provider’s controls. Google also asks that vulnerabilities discovered in the platform be reported through the Vulnerability Reward Program rather than explored further, which is the same coordinated-disclosure expectation Microsoft applies through MSRC.

What all three prohibit, whatever your client signs

Three prohibitions recur, and none of them can be authorised away by the account owner, because the harm they cause is not confined to the account.

• Denial of service. AWS prohibits DoS, DDoS, port flooding, protocol flooding and request flooding. Microsoft prohibits DoS testing of any kind and states that DDoS is prohibited under all circumstances. Google’s condition that your tests must only affect your own projects rules out anything that consumes shared capacity. A resilience test that needs load goes through a sanctioned simulation partner or does not happen.
• Reaching what you do not own. Every provider draws this line, and it is the line that produces incident reports. In a shared-tenancy estate, an aggressive scan of an address range you have not verified is not a scoping error, it is an intrusion into somebody else’s environment.
• Using credentials that are not yours. Microsoft states this explicitly and includes publicly leaked credentials. It is worth writing into the rules of engagement even where the provider does not spell it out, because credential-stuffing a client’s tenant with a public breach corpus is a fast way to test someone else’s account by accident.

Third-party testers and the authorization document

A consultancy is not covered by the client’s relationship with the provider by default. Microsoft is the clearest on this point: third parties such as managed security service providers, consulting firms and red teams may test if they have explicit written authorization from the resource owner, that authorization should be documented in the service agreement before any testing begins, and Microsoft does not grant authorization on the customer’s behalf. Treat that as the standard for all three providers.

The document is not a formality. Azure runs automated abuse detection on inbound and outbound traffic, and the rules of engagement note that Microsoft may, at its discretion, interrupt activity in progress regardless of whether it is a valid test. When that happens, the response is to reply to the abuse notification with the customer authorization and a description of the in-scope activity, and Microsoft’s own guidance is that keeping authorization documents readily accessible significantly shortens the process. A tester who has to chase a signature while an engagement is suspended loses days.

Turning three policies into one rules-of-engagement document

Multi-cloud scoping fails when a single document is written to the loosest of the three policies. The practical approach is to write the engagement to the strictest applicable rule and then note the per-provider exceptions, rather than the reverse.

• State denial of service as out of scope for the whole engagement, on every provider, with no exceptions clause. It is prohibited on two of the three by name and impossible to keep inside your own projects on the third.
• Identify every account, subscription and project by identifier, and state that anything not listed is out of scope. This is what protects you when a discovered resource turns out to belong to a different tenant.
• Where the engagement includes command and control, simulated phishing, malware or DDoS simulation on AWS, record the Simulated Events submission date and note the two-week minimum in the schedule.
• Record which provider policy version was read, and on what date. Policies change; an engagement record that names the date you read them is the difference between a defensible decision and an assumption.
• Name the reporting route for a platform vulnerability before you find one: MSRC for Microsoft, the Vulnerability Reward Program for Google, and the AWS security contact for AWS. Deciding this mid-engagement wastes the only window in which the finding is fresh.

None of this slows a competent engagement down. It moves an hour of reading from the middle of the test, where it costs a day, to the scoping call, where it costs an hour. And it is the part of a cloud assessment that a client can check before signing, which is why it belongs in the proposal rather than the appendix.

What the rules do not restrict

It is worth ending on what remains, because the prohibitions can read as though little is left. Everything you configure is testable. Identity and access, network rules, storage exposure, key policies, logging, admission control, workload configuration, metadata service settings, application behaviour and the guest operating system on every instance you run are all yours, on every provider, without a form. The shared responsibility line puts them there, and it is where essentially every real cloud finding comes from. The rules of engagement constrain the noisy tenth of a cloud assessment. They barely touch the part that produces the report.