Cloud Penetration Testing: What AWS, Azure, and GCP Allow

You do not need pre-approval to penetration test your own cloud resources on any of the three major providers, as of August 2026. AWS states that customers "are welcome to carry out security assessments or penetration tests of their AWS infrastructure without prior approval" for the services on its permitted list, while expressly forbidding denial of service, simulated denial of service and the flooding techniques that resemble it (AWS Customer Support Policy for Penetration Testing). Microsoft's Penetration Testing Rules of Engagement permit testing within your own assets and permissions, and prohibit denial-of-service testing and any post-exploitation activity against resources you do not own. Google's Cloud Security FAQ is the shortest of the three: "you are not required to contact Google" before testing, provided you abide by the Acceptable Use Policy and Terms of Service and your tests affect only your own projects. The permission question has been settled for years. The scoping question has not, and it is the one that decides whether the engagement is worth buying.

What follows: exactly what the three policies permit and prohibit, why a network test pointed at cloud IP addresses is not a cloud test, what a cloud-scoped engagement actually looks for, and when a configuration review is the better purchase.

Key takeaways

• All three major providers permit testing of your own resources without prior approval; AWS additionally requires approval for services outside its published permitted list.
• Denial-of-service testing, in any form including simulated, is prohibited by all three. This is the single most common way a test violates policy.
• The shared responsibility model draws the line: you may test your configuration and your workloads, never the provider's control plane or another tenant.
• A traditional network test aimed at cloud IP addresses will miss identity, storage permissions, secrets handling and metadata-service abuse, which are the cloud-specific risks.
• If nobody has ever reviewed your IAM policies, buy the configuration review first. A penetration test will spend expensive hours discovering what a review would have listed.

What the three providers actually permit

Read the policies rather than a summary, including this one, because they change. As of August 2026 the position is as follows.

AWS publishes a list of permitted services covering the ones most customers care about, including EC2 instances, load balancers, RDS, CloudFront, API Gateway, Lambda, ECS and Fargate, and states that testing those requires no prior approval. Two nuances catch people. Services outside that list still require approval through AWS Support, so an unusual managed service in scope is worth checking before the engagement starts. And AWS treats command-and-control simulation as a separate category requiring authorization, which matters if your engagement includes post-exploitation tooling.

Microsoft frames its rules as an engagement contract rather than a permission list. Testing your own Azure virtual machines, including fuzzing, port scanning and vulnerability assessment, is explicitly permitted. Accessing data or systems you do not own is not, and neither is post-exploitation activity such as enumerating internal networks, dumping credentials or pivoting once a vulnerability is confirmed in a resource that is not yours. The practical reading: prove the flaw, stop, report it.

Google Cloud requires no notification at all and points you to the Acceptable Use Policy and Terms of Service. The binding constraint is that your testing must affect only your own projects.

The common thread is worth stating once: these policies protect other tenants and the provider's own infrastructure. They are not gatekeeping your security program.

What you are never allowed to test

Three prohibitions hold across all three providers, and a firm that proposes any of them is a firm to walk away from.

Denial of service, in every variant. AWS is the most explicit, forbidding DoS, DDoS, simulated DoS, simulated DDoS, port flooding, protocol flooding and request flooding, and adding that any tool or service that "creates, determines the existence of, or demonstrates a DoS condition in ANY other manner, actual or simulated, is expressly forbidden." Microsoft prohibits denial-of-service testing outright. If you genuinely need resilience testing, the providers run separate programs for it with approved partners; that is a different purchase with a different approval path.

Other tenants. Shared infrastructure means an aggressive scan aimed at the wrong address range is someone else's incident. Rules of engagement should pin the exact accounts, subscriptions or projects in scope, and the tester should verify ownership before touching anything.

The provider's control plane. Testing the security of the hypervisor, the managed service internals or the provider's own APIs is out of bounds. That half of the shared responsibility model belongs to the provider, and their assurance reports are how you get comfort about it, not your penetration test.

A network test pointed at cloud IP addresses is not a cloud test

This is the failure mode that wastes the most money, and it is easy to buy by accident.

A traditional external network test enumerates hosts and services, checks for unpatched software and exposed management interfaces, and attempts exploitation. Point it at a cloud environment and it will do exactly that, competently, and it will tell you very little, because in a well-run cloud environment there are few long-lived hosts to find and the interesting attack paths do not run through open ports.

They run through identity. A role that can be assumed by a wider set of principals than anyone intended. A service account key committed to a repository three years ago. A storage bucket policy that grants read access to any authenticated user of the provider, which is not the same thing as any authenticated user of yours. A pipeline that holds deployment credentials and can be triggered by a pull request. An application that accepts a user-supplied URL and can be induced to fetch the instance metadata service, which is server-side request forgery, item seven in the OWASP API Security Top 10, and the mechanism by which a web flaw becomes cloud credentials.

None of those appear in a port scan. All of them are reachable in a cloud-scoped engagement.

What a cloud-scoped engagement looks for

A proposal worth signing will name most of these as objectives rather than leaving them implied.

Identity and access management. Role trust policies, permission boundaries, privilege escalation paths through policy chaining, unused credentials, and whether a low-privileged principal can reach a high-privileged one through any sequence of permitted actions.

Data storage exposure. Object storage permissions, database network exposure, snapshot and backup permissions, and encryption configuration. Snapshots are a recurring find, because they inherit less attention than the volumes they came from.

Secrets handling. Where credentials live, whether they are in environment variables, configuration files or a managed secrets service, and whether anything in the build pipeline logs them.

Workload and container configuration. Over-permissive instance profiles, containers running with more privilege than needed, and the metadata service accessible from workloads that process user input.

Logging and detection coverage. Not whether alerts fire, which is a red team question, but whether the audit trail would let you reconstruct what happened. This is the finding most often ignored and most regretted afterward.

The identity join. In hybrid environments, whether a corporate directory account also grants cloud console access, and what that means for the blast radius of one phished employee. We cover the on-premises half of that question in internal versus external penetration testing.

Configuration review or penetration test?

These are different products and the distinction is worth money.

A cloud configuration review is systematic and largely tool-assisted: every setting in scope compared against a benchmark, with a human triaging results and judging which findings matter in your context. It gives you coverage, and it is the right first purchase for an environment nobody has audited.

A cloud penetration test is objective-driven. A tester takes a starting position, often a low-privileged principal or a compromised application, and tries to reach something valuable. It gives you attack paths, and the chains it finds are usually invisible to a benchmark comparison, because each individual setting looked defensible.

Buy the review first if nobody has ever looked. Buy the test when the review's findings are remediated and you want to know what remains. Buying the test first is not wrong, it is just an expensive way to be told your IAM needs work.

What auditors accept

For SOC 2, the Trust Services Criteria name penetration testing only in a point of focus under CC4.1 that the AICPA says need not be addressed, and CC7.1 concerns monitoring for vulnerabilities and susceptibility to newly discovered ones. A cloud-scoped test on a cloud-native environment is stronger evidence for that criterion than a network test against systems your customers never touch, and auditors are increasingly willing to say so. The report should be readable as evidence, meaning it names the systems in scope, the methodology, and the remediation status.

For ISO 27001, Annex A control 8.8 covers management of technical vulnerabilities, and a cloud test with a tracked remediation trail is ordinary evidence for it. Certification is against the management system; the test is one input, not the thing being certified.

One caution that applies to both: an attestation letter naming "cloud infrastructure" without saying which accounts and which services were tested is weak evidence, and a sharp reviewer will ask. Insist on scope specificity in the letter.

When not to buy this

If your cloud footprint is one account, a handful of managed services and no custom infrastructure, a cloud penetration test is probably premature. Enable the provider's own security tooling, fix what it flags, get multi-factor authentication on every human principal, and remove the long-lived access keys. That work costs nothing but attention, and a tester will bill you to find the same list.

If you have no idea which accounts exist, the answer is an inventory, not a test. And if a firm quotes a cloud penetration test without asking how many accounts, subscriptions or projects are in scope and what runs in each, they are quoting a scan; the same arithmetic we apply to any quote in the penetration testing cost breakdown applies here.

Where Top Floor fits

Our penetration testing practice covers cloud infrastructure as one of seven disciplines, scoped by account and service rather than by IP range, and the rules of engagement name the provider policy the work runs under. Findings come with the attack path, not just the misconfiguration, because the path is what tells you which fix to make first.

Where the engagement supports an audit, our SOC 2 and ISO 27001 teams make sure the report is scoped to what the assessor will examine and written so it can be handed over without a translation layer.

How to decide this week

List every cloud account, subscription and project your company owns, including the ones from abandoned experiments. That list is the scope conversation, and for most companies it is longer than expected.

Then check two things you can check today: whether every human principal has multi-factor authentication, and whether any long-lived access keys exist that have not been used in ninety days. If either answer is unsatisfactory, that is this week's work, and it is worth more than any test you could book.

Then read the relevant provider policy yourself before an engagement starts, and put its name in the rules of engagement document. It takes ten minutes and it is the document your provider will refer to if anything goes sideways.

Frequently asked questions

Do I need permission from AWS to run a penetration test?

Not for the services on the permitted list, which covers most of what customers run, including EC2, load balancers, RDS, CloudFront, API Gateway, Lambda, ECS and Fargate. AWS states that customers are welcome to carry out security assessments or penetration tests of their AWS infrastructure without prior approval for those services. Two exceptions matter: services outside the published list still require approval through AWS Support, and command-and-control simulation is treated separately. Denial-of-service testing in any form, including simulated, is expressly forbidden regardless of the service. Check the current policy before each engagement, because the permitted list changes.

Can I penetration test Azure and Google Cloud without notifying the provider?

Yes, within limits. Microsoft's Penetration Testing Rules of Engagement permit testing within your own assets and permissions, and prohibit denial-of-service testing, accessing data or systems you do not own, and post-exploitation activity such as enumerating internal networks or dumping secrets in resources that are not yours. Google's Cloud Security FAQ states that you are not required to contact Google, provided you comply with the Acceptable Use Policy and Terms of Service and your testing affects only your own projects. In both cases the rules of engagement should name the exact subscriptions or projects in scope so that shared infrastructure is never touched by accident.

What is the difference between a cloud penetration test and a cloud configuration review?

A configuration review is coverage-driven: every setting in scope compared against a benchmark, triaged by a human who judges which deviations matter in your environment. A penetration test is objective-driven: a tester starts from a defined position, such as a low-privileged principal or a compromised web application, and attempts to reach something valuable, reporting the chain rather than the individual settings. The review is the better first purchase for an environment nobody has audited, because it produces a complete list cheaply. The test earns its place afterward, when the obvious findings are closed and the remaining risk lives in combinations that no single-setting check can see.

Will a normal network penetration test cover our cloud environment?

Only partially, and the part it misses is the part that is specifically a cloud risk. A network test enumerates reachable hosts and services and attempts exploitation, which in a modern cloud environment finds relatively little, because there are few long-lived hosts and the interesting paths run through identity rather than through open ports. Over-permissive roles, leaked service account keys, storage permissions granting access to any authenticated provider user, and server-side request forgery reaching the instance metadata service are all invisible to a port-based test. If your infrastructure is cloud-native, ask for a cloud-scoped engagement rather than a network test aimed at cloud addresses.