Cloud penetration testing companies for AWS, Azure, GCP

Cloud penetration testing companies test your own cloud accounts for weaknesses an attacker could use: identity roles, storage, network paths and managed services on AWS, Azure or Google Cloud. This page is for buyers who must pick a provider and write a scope. The table lists every provider in our dataset whose record includes cloud testing, in A to Z order. It is not a ranking, and nobody pays for position.

The table shows what each provider says on its own pages, with the date we checked. "Not published" means we found no statement.

What does a cloud penetration test cover?#

A cloud penetration test covers the resources that you own in a cloud account and the paths between them. Typical items are identity and access roles, storage buckets, serverless functions, container platforms, network rules, secrets stores and the build pipeline that deploys to the cloud.

Providers name these areas differently. Ask for a list, not a label. This checklist turns "cloud testing" into items you can accept or remove.

What do AWS, Microsoft and Google allow?#

Each cloud provider publishes its own testing rules, and they differ. The rules apply to the tester, so read them before you sign the scope.

AWS says customers may test their AWS infrastructure without prior approval for the services on its Permitted Services list. All security testing that includes command and control (C2) requires prior approval, and AWS asks customers who want covert adversarial simulations to submit a Simulated Events form. AWS also states that customers may not assess AWS infrastructure or the AWS services themselves (AWS policy, checked 9 November 2026).

Google Cloud says you are not required to contact it. You must follow the Acceptable Use Policy and Terms of Service, and your tests may only affect your own projects (Google Cloud FAQ, checked 9 November 2026).

Microsoft's rules of engagement apply to the resource owner and to authorized agents such as consultancies. They prohibit denial-of-service testing, DDoS, network-intensive fuzzing, and testing a tenant you do not own (Microsoft rules, checked 9 November 2026).

Who needs it and when?#

Teams need a cloud test when a cloud account holds production data and the last review of its roles is old. Common triggers are a first move to the cloud, a new multi-account setup, a merger that joins two accounts, and a customer or auditor request for evidence.

A test of the application alone does not show a role that lets an attacker move from a low-privilege function to a storage bucket. If your risk sits in the account, scope the account.

What to ask providers#

Send every provider the same questions, and compare the written answers.

1. Which clouds and which services will you test? Ask for the list in the quote.
2. Do you test from outside only, or with credentials for a low-privilege role and an admin-read role?
3. Which cloud provider policies apply, and who checks them before the test starts?
4. Will you run command and control tools, load tests or fuzzing? Each can need approval or be banned.
5. How do you protect the access keys we give you, and when do you delete them?
6. Does the report show attack paths with evidence, or a list of misconfigurations?
7. Is a retest included? If yes, for how long, and for which findings?
8. Can we see a sample report? The table shows which providers publish one.

Price drivers#

Cloud test price depends on the size of the environment and the depth of access. Most providers in the dataset publish no price, so you will get a quote. Compare quotes on the same inputs.

• Number of accounts, subscriptions or projects in scope
• Number of distinct services and regions
• Whether the test includes the applications that run in the cloud
• Credentialed access (more depth) or external only
• Report type and retest terms

For published prices and the units they use, read penetration testing cost.

How to read the table#

Read the Cloud column first: "yes" means the provider's own pages state cloud testing. "Unknown" means we found no statement either way. Then read Type and Delivery. A PTaaS platform, an autonomous platform and a consultancy run cloud tests in different ways, and the Delivery column shows who does the testing.

Next, check Published price, Turnaround and Retest. Each cell reflects the provider's own wording, and units differ. A turnaround claim can describe the start time, the test window or time to first results. Open the provider profile for the source link on each claim.

The table does not show cloud-specific proof. A "yes" in the Cloud column is a stated service, not evidence of AWS, Azure or GCP depth. Ask for a sample report or a named cloud certification, and check it yourself.

Common scoping mistakes#

• Listing "the cloud" as one asset. Name accounts, subscriptions or projects.
• Leaving identity out. Role and trust paths cause many cloud findings.
• Forgetting provider rules. A load test or C2 tool can need approval or be banned.
• Giving the tester admin keys with no expiry. Use short-lived credentials and delete them after the test.
• Testing production with no rollback plan for changes the tester makes.
• Skipping the retest. A fix to one role can open another path.

Where to go next#

Compare providers across all services in the provider directory or the services index. Before you request quotes, read questions to ask a pentest provider.