None of the three major clouds require prior approval to penetration test your own resources. AWS permits testing a defined Permitted Services list without approval, but requires the Simulated Events form for C2, phishing and malware, and treats DDoS as a separate sanctioned track. Azure dropped notification entirely on 15 June 2017 — but prohibits exploiting a discovered vulnerability beyond initial identification. GCP requires no contact at all, only compliance with its Acceptable Use Policy. All three ban DDoS, testing other tenants, and testing the provider's shared infrastructure — you test in the cloud, never of it. We cover the attack surface in our AWS, Azure and GCP testing services.
// 01 The rule behind all the rules: shared responsibility
Every cloud provider's testing policy flows from one principle: the shared responsibility model. You are responsible for security in the cloud — your configuration, identities, applications, data and workloads — and the provider is responsible for security of the cloud — the hypervisor, control plane, physical estate and managed-service backends. A cloud penetration test therefore targets your side of the line. Testing the provider's underlying infrastructure is out of scope on every platform, no exceptions. Get that boundary right and the rest of the rules follow logically.
// 02 The three clouds at a glance
| AWS | Azure | GCP | |
|---|---|---|---|
| Prior approval to test own resources? | No (Permitted Services) | No | No |
| Notification required? | No (except special activities) | No (dropped June 2017) | No |
| Special-activity form? | Simulated Events form (C2, phishing, malware) | None | None |
| DDoS testing | Separate track / approved partner | Strictly prohibited | Prohibited (AUP) |
| Exploit beyond identification? | Allowed (own scope) | Prohibited | Allowed (own scope, AUP) |
| Governing document | AWS Pentest Policy | Microsoft Cloud RoE | GCP support / AUP |
// 03 AWS — permitted services, and what needs a form
AWS is explicit: customers "are welcome to carry out security assessments or penetration tests of their AWS infrastructure without prior approval" for the services on the Permitted Services list — which covers most of what you actually run: EC2, ELB, RDS and Aurora, CloudFront, API Gateway, AppSync, Lambda and Lambda@Edge, Lightsail, Elastic Beanstalk, ECS and Fargate, OpenSearch, and more. Three categories change the rules:
- Simulated Events form (submit ahead of time) for covert red/blue/purple simulations, all command-and-control (C2) hosting, iPerf network testing, simulated phishing and malware testing.
- DDoS is a separate track — prohibited under the general policy and governed instead by the DDoS Simulation Testing policy, using an AWS-approved DDoS Test Partner.
- Always prohibited: protocol/request flooding, Route 53 DNS zone walking, and S3 or subdomain takeover.
The signature AWS attack surface — IAM privilege escalation, over-permissive roles, S3 misconfiguration, and IMDS SSRF-to-credentials — all sits comfortably inside the no-approval zone.
// 04 Azure — no notification since 2017, but no exploitation
The most misunderstood policy of the three. Microsoft retired the notification requirement on 15 June 2017; testing your own tenant and authorised assets needs no form and no notice, governed by the Microsoft Cloud Unified Penetration Testing Rules of Engagement. Many competitor pages still tell you to notify Microsoft — that is simply out of date. What Azure does restrict is how far you go: "Any action that leverages a discovered vulnerability beyond initial identification and reporting is prohibited." In practice that constrains post-exploitation — you identify and report the weakness rather than fully weaponising lateral movement or privilege escalation. Permitted activities include fuzzing, port scanning and vulnerability assessment on your own VMs, testing Conditional Access, and container breakout on App Service or Functions (ceasing on success). DDoS is "strictly prohibited under all circumstances." The Azure attack surface centres on Entra ID, RBAC and Managed Identity abuse.
// 05 GCP — no contact required
Google is the most permissive on process: "If you plan to evaluate the security of your Cloud Platform infrastructure with penetration testing, you are not required to contact us." The conditions are the standard ones — comply with the Acceptable Use Policy and Terms of Service, ensure your tests only affect your projects and not other customers' applications, and report any vulnerability you find in Google's own infrastructure through the Vulnerability Reward Program. No DoS/DDoS, and no testing of shared or multi-tenant infrastructure. The dominant GCP attack path is service-account impersonation and privilege escalation via IAM.
// 06 The prohibitions common to all three
Whatever the cloud, four lines are never crossed:
- No denial-of-service or DDoS outside each provider's specific sanctioned programme.
- No testing other customers' tenants, data or resources — scope is strictly your own.
- No testing the provider's shared infrastructure — hypervisor, control plane, managed-service backends.
- No accessing or using other parties' credentials or data encountered during testing.
Beyond the provider rules, your engagement should still map to a recognised standard — the CIS Foundations Benchmarks for each cloud, the MITRE ATT&CK Cloud matrix, and our own methodology — and, for regulated GCC workloads, to frameworks like the NCA cloud controls.
// 07 Frequently asked questions
Do you need permission to pentest AWS?
Not for most testing. AWS permits testing your own infrastructure without prior approval for a defined Permitted Services list (EC2, RDS, CloudFront, API Gateway, Lambda and more). C2 hosting, simulated phishing and malware testing require the Simulated Events form, and DDoS is a separate track. You only test your own resources.
Do you have to notify Microsoft before pentesting Azure?
No. Microsoft retired notification on 15 June 2017. Testing your own tenant is governed by the Microsoft Cloud Unified Penetration Testing Rules of Engagement, with no form or notice. Outdated pages still say otherwise. Azure does prohibit exploiting a discovered vulnerability beyond initial identification.
Do you need to contact Google before pentesting GCP?
No. Google states you're not required to contact them to test your own Cloud infrastructure. You must comply with the Acceptable Use Policy and Terms of Service, only affect your own projects, and report vulnerabilities in Google's own infrastructure via the Vulnerability Reward Program.
What's prohibited on any cloud?
DoS/DDoS outside sanctioned programmes, testing other customers' tenants or data, and testing the provider's shared infrastructure (hypervisor, control plane, managed-service backends). You test security "in" the cloud — your config, identities, apps and data — never "of" the cloud.
// 08 References & sources
- AWS, Penetration Testing Policy and DDoS Simulation Testing Policy.
- Microsoft, Cloud Penetration Testing Rules of Engagement (notification retired 15 June 2017).
- Google Cloud, Penetration testing support article.
- CIS, Foundations Benchmarks for AWS, Azure and GCP.