Does AWS Allow Penetration Testing? AWS, Azure and Google Cloud Rules

Yes, AWS allows penetration testing. AWS customers can test their own resources on a published list of permitted services, including EC2, RDS, Aurora, CloudFront, API Gateway, Lambda, Lightsail, Elastic Beanstalk, ECS and Fargate, without asking for approval first. Microsoft Azure and Google Cloud take the same approach: no pre-approval for your own resources. All three prohibit denial-of-service testing and any testing of other customers or of the provider’s own infrastructure.

This guide sets out each provider’s rules, what is prohibited, and how to scope a cloud test so it stays inside them. Provider policies change, so your tester should always check the current version during scoping.

Key takeaways

• AWS, Azure and Google Cloud do not require pre-approval to test your own resources.
• Every provider bans denial-of-service testing under its standard rules, and testing anything you do not own.
• AWS lists the services you can test freely; anything outside that list needs a request.
• SaaS platforms are different: you need the vendor’s permission to test them.
• You still need written authorisation from whoever owns each account, subscription or project in scope.

Do AWS, Azure and Google Cloud allow penetration testing?

Yes, all three allow customers to test their own resources without prior approval, within published rules.

We last checked all three official pages on 13 October 2026.

Does AWS allow penetration testing, and what does its policy ban?

Yes. The AWS penetration testing policy lets customers test their own AWS infrastructure without prior approval, as long as the target is on its list of permitted services. At the time of writing that list includes Amazon EC2 instances, WAF, NAT gateways and Elastic Load Balancers, Amazon RDS and Aurora, CloudFront, API Gateway, AWS AppSync, AWS Lambda, Lightsail, Elastic Beanstalk, Amazon ECS, AWS Fargate, Amazon OpenSearch Service, Amazon FSx, Transit Gateway and AWS Global Accelerator, among others.

The policy prohibits:

• DNS zone walking, hijacking and pharming through Route 53.
• Denial of service and simulated denial of service.
• Port, protocol and request flooding, such as flooding login or API endpoints.
• S3 bucket takeover and subdomain takeover.

Denial-of-service simulation is handled under a separate AWS DDoS simulation testing policy. Red team exercises and other simulated events that could look like a real incident to AWS, such as phishing or malware tests, must be requested through AWS’s simulated events form at least two weeks before they start. To test a service that is not on the permitted list, work with AWS Support or your account representative first.

What are the Azure penetration testing rules?

Microsoft has not required pre-approval or notice for penetration tests of your own Azure resources since 2017, but you must follow its Unified Penetration Testing Rules of Engagement, which apply across Microsoft’s cloud services. A third party testing for you needs your explicit written authorisation; Microsoft does not grant it on your behalf.

The rules prohibit:

• Scanning or testing assets that belong to other Microsoft cloud customers.
• Accessing any data that is not wholly your own.
• Using credentials or other secrets that are not your own, including ones leaked publicly.
• Denial-of-service testing of any kind.
• Network-intensive fuzzing, or automated testing that generates excessive traffic.
• Phishing or other social engineering against Microsoft employees, or using Microsoft services to phish others.
• Any action beyond the initial proof of concept when a flaw affects Microsoft’s services, such as lateral movement or pivoting.

The rules permit, for example, port scanning, fuzzing and vulnerability assessment of your own virtual machines, creating test accounts or trial tenants to check that tenants are properly isolated, generating traffic to test the surge capacity of your own applications, and generating test events to check your security monitoring.

If testing reveals a vulnerability in a Microsoft service itself, stop and report it to the Microsoft Security Response Center immediately.

What are the Google Cloud rules?

Google states that you do not need to contact it before penetration testing your Google Cloud infrastructure. Testing must comply with the Google Cloud Acceptable Use Policy and Terms of Service, and must affect only your own projects, not other customers’ applications.

Can you test SaaS platforms and Microsoft 365?

Only within the vendor’s rules. You cannot attack a SaaS platform such as a CRM or HR system without the provider’s written permission, even though your data is in it. What you can usually do is review your own configuration: who has administrative rights, whether MFA and conditional access are enforced, how data is shared externally, and whether audit logging is switched on. For Microsoft 365, that configuration review sits within Microsoft’s rules of engagement.

What authorisation do you need before a cloud test?

The provider’s rules are only half of it. Under the Computer Misuse Act 1990, the tester needs authorisation from the owner of each system. Before testing starts, confirm in writing:

• Every account, subscription, project and region in scope, with its owner.
• Sign-off from any managed service provider that runs the environment for you.
• Testing windows, rate limits and stop conditions.
• Which activities are excluded, including anything the provider prohibits.
• Named contacts on both sides who can pause testing.

Our checklist on how to prepare for a penetration test covers the rest of the preparation.

What should a cloud penetration test cover?

Within those rules, a useful cloud test combines a configuration review with hands-on testing of the parts you control:

• Identity and access management: users, roles, keys and trust relationships.
• The management plane: who can change what, and whether MFA protects administrators.
• Network controls: security groups, exposed services and private endpoints.
• Workloads: virtual machines, containers, Kubernetes and serverless functions.
• Data stores, snapshots and backups, including whether backups are protected from deletion.
• Logging and detection: whether your monitoring would notice the test.

In the cloud, identity and configuration usually matter more than the network perimeter, so a test that only scans IP addresses misses most of the risk. Our cloud penetration testing services cover AWS, Azure and Google Cloud on that basis; see AWS penetration testing and Azure penetration testing for what each platform test includes.

What do PCI DSS, UK GDPR and ISO 27001 expect?

• PCI DSS v4.0.1. If any part of your cardholder data environment runs in the cloud, Requirement 11.4 applies: internal and external testing at least every 12 months and after significant change, plus segmentation testing where segmentation reduces scope. Requirement 11.4.7 requires multi-tenant service providers to support their customers’ external testing. PCI penetration testing should be scoped with those rules in mind. If your card data runs in AWS, our guide to AWS PCI compliance explains which PCI DSS controls AWS covers and which stay with you.
• UK GDPR. Article 32(1)(d) requires a process for regularly testing the effectiveness of your security measures.
• ISO/IEC 27001:2022. Test results support Annex A controls 8.8 (technical vulnerabilities) and 5.23 (information security for use of cloud services). See ISO 27001 penetration testing.
• Cyber Essentials. Cloud services are in scope, and the scheme requires MFA on cloud service accounts wherever the service offers it. The Cyber Essentials Plus requirements explain what the audit checks.

Why Sovereign Secure

Sovereign Secure is a PCI SSC Qualified Security Assessor (QSA) company, an IASME-licensed Cyber Essentials certification body and ISO 27001 certified. We check the current provider rules during scoping, record every account and subscription in the authorisation, and write the report so it can be used as PCI DSS or ISO 27001 evidence.

Next step

List the accounts, subscriptions and projects you want tested and the platforms they run on. Our penetration testing quote form uses that to scope a cloud test that stays inside AWS, Azure and Google Cloud rules.