Service
Cloud penetration testing that follows the identity paths
Cloud penetration testing checks how one mistake in AWS, Azure or Google Cloud could turn into full access. The weak point is rarely the provider, because it is usually a role, a key or a bucket configured in a hurry.
- Named tester before day one
- One retest within 30 days
- OWASP WSTG and NIST SP 800-115
What cloud penetration testing actually tests
Providers secure their own hardware and platform. You, however, own the configuration, and that is what we test. So most serious cloud findings come from identity, not from software bugs.
- Roles and policies that grant far more than they need
- Storage buckets and snapshots reachable from the internet
- Keys left in code, build pipelines or instance metadata
- Network rules that expose internal services
- Paths from a low-privilege identity to an administrator
Configuration review and attack paths
A cloud test has two parts. First, a read-only review of the configuration with an account you provide. Then, a hands-on attempt to chain what we found into real access, because isolated settings rarely tell the whole story. The second part is what separates cloud penetration testing from a configuration checklist, because it shows which weaknesses actually connect.
Is your estate ready for cloud penetration testing?
Tick what is in place. Each item makes the scope faster and the result sharper.
Your result appears here as you tick, so you can see what is still open.
Cloud penetration testing and provider rules
Each provider publishes what customers may test without asking. For instance, AWS, Azure and Google Cloud all allow testing of your own resources but forbid attacks on the shared platform itself. So we scope inside those rules and also name them in the authorisation you sign.
| Provider | What you may test | Where to read it |
|---|---|---|
| AWS | Your own accounts and listed services. | AWS penetration testing policy. |
| Azure | Your own tenants and subscriptions. | Microsoft Cloud penetration testing rules of engagement. |
| Google Cloud | Your own projects. | Google Cloud guidance on penetration testing. |
What the cloud penetration testing report shows
Each finding shows the identity or resource involved, the path we took, and the change that closes it. In addition, we list the quick wins first, because a single policy fix often removes several paths at once. One retest inside 30 days is included.
Price range and drivers
Our published range for cloud work is $10,000 to $50,000. The number of accounts or subscriptions drives it most, followed by how many services are in use. A single account running a few services sits low, while an organisation with dozens of accounts and shared identity sits high.
Cloud penetration testing questions
Do we need to ask AWS, Azure or Google before cloud penetration testing?
For most services, no, because each provider publishes a policy listing what customers may test. We scope inside it and also record it in your authorisation.
Will cloud penetration testing affect production?
The review is read-only, so any active step against production is agreed separately and in writing.
Is this the same as a cloud security posture tool?
No. A tool lists settings, but a tester proves which settings combine into real access.
Which providers do you cover?
AWS, Azure and Google Cloud. Each has its own guide on this site.
Related guides
Scope your cloud penetration testing
Tell us the provider and the number of accounts. We reply with a written scope and a fixed fee, then start after you sign.
Get my estimate