Cloud Penetration Testing Rules: AWS, Azure and Google Cloud

Whether you need permission to run a penetration test in the cloud depends on whose cloud it is. AWS, Microsoft Azure and Google Cloud each publish their own testing policy, and the three do not say the same thing. Testing your own resources is broadly allowed on all of them, but what counts as “your own resources”, what is prohibited outright, and what needs a form submitted in advance differ by provider.

This is the three current positions side by side, as of October 2026, with the key points you carry into an engagement. Provider policies change, so treat this as a map rather than the territory: always read the live policy for the provider in scope, and keep a dated copy. The primary sources are the AWS penetration testing policy, the Microsoft security testing rules of engagement and the Google Cloud security FAQ.

Do you need permission?

The headline answer for each provider, for a customer testing resources in its own account:

So the common thread is that your own resources are fair game without asking, and the moment testing could reach the provider’s own systems, other customers, or certain high-risk activities, the rules tighten. The differences are in where each provider draws those lines.

Which services the policy covers

AWS is the most explicit: it lists the services you may test without approval, and tells you to work with AWS Support for anything not on the list.

Microsoft frames it the other way round, by ownership rather than by service list. Its rules cover all products, services and infrastructure owned or managed by Microsoft, and the encouraged activities are the ones you perform within your own tenant and assets: fuzzing and vulnerability assessment on your own Azure virtual machines, testing your own tenant’s monitoring and detection, evaluating conditional access and Intune policies, and generating traffic to test surge capacity within your own applications.

Google is briefer still: the permission is to evaluate the security of your own Cloud Platform infrastructure, bounded by the Acceptable Use Policy and the requirement that tests affect only your projects.

What each provider prohibits

The prohibitions overlap on the big items and differ in the detail. In every case these are policy limits to respect, carried into your out-of-scope clause.

Shared services you cannot test

The principle that runs through all three policies, and the one that matters most for authorisation, is that you can only test what the customer controls. Shared provider infrastructure, the control plane, and managed services the customer cannot configure are the provider’s responsibility, not the customer’s to authorise. This is the cloud face of the point made in the authorisation letter guide: a client cannot grant permission over something it does not own or control.

In practice this means the target of a cloud test is the customer’s own configuration, identities, data stores, network rules and workloads, not the underlying platform. A configuration review of the customer’s own account is often the higher-value work anyway, because that is where the customer’s own mistakes live.

Denial of service and load testing

This is the area where the three differ most, and where getting it wrong does real damage, so it is worth stating each position plainly.

The safe default across all three is simple: no denial of service, and nothing with a volumetric profile, unless it runs through the provider’s named simulation route against a target you have proven you own. Any automated tool capable of generating load should have that behaviour switched off before it is pointed at a cloud asset.

How to notify for simulated events

Where a provider asks to be told in advance, the mechanism is specific:

• AWS uses a Simulated Events form for activities such as simulated phishing, malware testing, red team and purple team exercises, and command and control. The request names dates, account identifiers, assets and a contact, and must be submitted at least two weeks before the start date; AWS aims to acknowledge within two business days. DDoS simulation goes through the pre-approved partner route instead.
• Microsoft Azure sets no notification step for testing your own assets, so there is nothing to file for ordinary work. DDoS simulation is the exception, arranged through an approved partner who confirms ownership of the target before anything runs.
• Google Cloud asks for no advance notice to test your own projects. Vulnerabilities you find in Google Cloud itself are reported through its Vulnerability Reward Programme rather than to a testing contact.

Reporting a flaw in the provider’s own platform is a separate obligation on all three: AWS asks for prompt notification of any issue found in an AWS service, Microsoft routes it through its Security Response Centre, and Google through its reward programme. A finding about the provider is never something you simply write into the client’s report.

Putting provider rules in your rules of engagement

Everything above has to land somewhere a tester will see it. That place is the rules of engagement. Before a cloud engagement starts, work through this short list:

1. Identify every cloud asset in scope and the provider and account, subscription or project it sits in.
2. Read the provider’s current testing policy and record whether any activity needs prior approval or notification.
3. Complete any required notification or partner arrangement, and keep the confirmation.
4. Carry the provider’s prohibitions into your out-of-scope and safeguards clauses, denial of service and testing the platform itself included.
5. Confirm the client owns or controls every target, and exclude shared provider services the client cannot authorise.
6. Note the provider route for reporting any flaw found in the platform, separate from the client’s findings.

Evidence from cloud environments

Cloud evidence carries the same data-handling duty as any other, with one extra wrinkle: a configuration export or an identity listing can contain more than you expect, including real account identifiers and, sometimes, personal data. Capture the minimum needed to prove a finding, redact identifiers at the point of capture, and store it under the access controls set out in the statement of work. The security page covers where engagement evidence should live and who can read it.

Keep a dated copy

Provider policies are updated without notice, and “the policy allowed it” is only a defence if you can show which version you relied on. Save a dated copy, or a timestamped capture, of each provider policy you worked to, alongside the authorisation letter for that engagement. If a provider later changes its position, the copy shows what the rules were on the day you tested.