Client Sign-Off Isn't Enough: Cloud Pentest Rules for AWS, Azure and GCP

A signed scope from your client lets you test their cloud resources. It doesn't let you test AWS, Microsoft or Google themselves, and it never covers the other customers sharing the same hardware.

Each provider has its own rules, and they bind you directly, whoever's paying. Keep this cheat sheet open while you scope: what needs no notice, what needs a form and how early, what's banned, who you report to, and the 3 commands that tie your scope to real account IDs. If the service names don't line up yet, start with the cloud name map.

Cloud pentest rules at a glance

Here's the short version for all 3 providers, checked against their own policy pages on 1 Nov 2026.

Microsoft rules of engagement for Azure, M365 and AI

No advance notice, but you must follow the Microsoft Security Testing Rules of Engagement. They cover every product, service and piece of infrastructure Microsoft owns or manages (LinkedIn, GitHub and Activision Blizzard have their own processes), and they apply to consultancies exactly as they do to the resource owner.

You can: scan and fuzz the client's own Azure VMs, build trial tenants for cross-tenant tests (with MSOBB in the name where you can), test the tenant's monitoring, and probe AI boundaries and prompt restrictions, much like system prompt leaking. All of it inside assets you're cleared for.

You can't: run DoS or traffic-heavy fuzzing, touch another customer's data or storage, use credentials that aren't yours (leaked ones included), phish Microsoft staff, or pull out model weights or training data. And once you've proven a bug in a Microsoft service, stop: no secret dumping, lateral movement or pivoting past that first proof of concept. Hit data you shouldn't see? Stop, tell MSRC and delete it.

AWS penetration testing policy: permitted services and banned attacks

AWS lets you test these services without approval. Anything else, ask AWS Support or the account rep first. You can't test AWS's own infrastructure or the services themselves.

Watch the direction: API Gateway and Bedrock AgentCore are also on AWS's list of services you can't use for outbound testing. Test them, but don't launch testing from them.

Banned: DoS and DDoS, real or simulated (DDoS simulations have their own policy); port, protocol and request flooding; Route 53 zone walking, hijacking and pharming; S3 bucket takeover; and subdomain takeover.

Needs approval first: anything with command and control (C2). Covert red, blue or purple team work, simulated phishing, malware and iPerf testing need a Simulated Events form at least 2 weeks before you start.

Allowed: banner grabbing to compare a version against known DoS-vulnerable ones, and crashing a process your exploit needs to crash, as long as nothing floods. After testing: issues caused directly by AWS services go to AWS Security within 24 hours, and the client carries any damage to AWS or other customers, so write that into the contract.

Google Cloud: no notice, but only your projects

You don't need to contact Google first. You do need to follow its Acceptable Use Policy and Terms of Service, and your tests must only affect the projects you're cleared for: IAM, service accounts, firewall rules, open ports, VM config and storage inside them. For C2, DoS simulation, phishing or anything that could knock over a shared service, check the terms and get written sign-off. Bugs in Google's own services go to its Vulnerability Reward Program.

Record the cloud scope before you send a packet

When you juggle several clients' credentials, it's easy to test from the wrong account. Run one command per provider with the credentials you'll test with, and compare the IDs with the signed scope.

aws sts get-caller-identity
az account show --query "{tenant:tenantId, subscription:id, name:name}" -o table
gcloud config list --format="value(core.account,core.project)"

If an account, subscription or project ID isn't in the signed scope, stop and fix your credentials before anything else. Write the IDs and regions into your notes so your report and the client's logs can be matched later.

Cloud pentest pre-engagement checklist

Common mistakes

Reading "no notice" as "no rules". None of the 3 asks for a heads-up on normal testing, but DoS, other tenants and provider infrastructure stay off-limits whatever the client signs.

Forgetting the 2-week clock. Phishing, malware, covert red teaming or iPerf on AWS means a Simulated Events form 2 weeks before day one. Spot it at scoping.

Testing a hostname you don't control. A client domain can point at a CDN, a SaaS app or someone else's bucket. Check who owns each target first. Subdomain takeover is banned on AWS even if the client asks.

Pushing past the proof of concept. On a Microsoft service, one working PoC is the finish line.

Prove you stayed in scope

If something breaks during your window, you'll want proof of what you did. Log your source IPs and times, test from named identities (an MSOBB tenant on Microsoft, a dedicated IAM user on AWS), and ask the client to keep CloudTrail, the Azure Activity Log or Cloud Audit Logs for the test window. Those logs show which identity did what, and let the client tell you apart from a real attacker. The cloud pentest notes have the scoping checks as a tickable list.

Quick recap

• Client sign-off covers the client's resources. The provider's rules bind you too.
• AWS: the 16 entries on its permitted list need no approval, C2 does, covert work needs a form 2 weeks ahead, and provider bugs go to AWS Security within 24 hours.
• Microsoft and Google: no notice, but no DoS, no other tenants, and on Microsoft nothing past your first PoC.
• Match aws sts get-caller-identity, az account show and gcloud config list output to the scope before testing.

Go deeper

These policies change, and a cheat sheet can't keep up with every edit. Before each cloud job, read the 3 primary pages in the references: the AWS Penetration Testing policy (watch the permitted list), the Microsoft Security Testing Rules of Engagement (including its AI section) and the Google Cloud Security FAQ. Your contract leans on whatever they say on the day you scope.

If you scope cloud tests and have handled a provider approval differently, I'd like to hear how it went. Come and compare notes on LinkedIn.

References

• AWS Penetration Testing policy - permitted services, prohibited activities, Simulated Events and the 24-hour rule.
• Microsoft Security Testing Rules of Engagement - Microsoft Online Assets, allowed and prohibited testing.
• Google Cloud Security FAQ - no notice needed, AUP, ToS and the VRP.

FAQ

Do I need to tell AWS before a penetration test?

Not for the 16 entries on AWS's permitted list, such as EC2, RDS, Lambda and CloudFront. Anything outside that list goes through AWS Support or your account rep. Command and control needs prior approval, and covert red team work, phishing, malware and iPerf testing need a Simulated Events form at least 2 weeks ahead.

Do I need to notify Microsoft before testing Azure?

No. Microsoft doesn't ask for advance notice, but everyone testing its services, including consultancies working for the resource owner, must follow the Microsoft Security Testing Rules of Engagement. They ban DoS, touching other customers' data, and any action beyond your first proof of concept on a Microsoft service.

Can I run DoS tests in AWS, Azure or Google Cloud?

Not under the normal pentest rules. AWS bans real and simulated DoS and DDoS, plus port, protocol and request flooding, and handles DDoS simulations under a separate policy. Microsoft bans DoS and says DDoS is prohibited under all circumstances. Google expects you to follow its Acceptable Use Policy, so get explicit sign-off first.

What do I do if I find a bug in the cloud provider's own service?

Report it to the provider. AWS wants issues caused directly by its tools or services sent to AWS Security within 24 hours of finishing your testing. Microsoft wants findings reported through MSRC, and Google asks you to report through its Vulnerability Reward Program. Stop at the proof of concept.

Related reading

• Blob Is S3 Is Cloud Storage: The Cloud Name Map for Pentesters (the service names behind every scope)
• Least Privilege, Two Ways: Cloud IAM and a Host Firewall (cloud IAM roles in practice)
• Browse the whole Cloud Journey