Cloud penetration testing: AWS, Azure, GCP
Most of what is sold as a cloud penetration test is a configuration and identity review, and that is the right product. The part people skip is reading what the provider actually permits you to do inside their platform.
Cloud penetration testing in Canada costs $8,000 to $25,000 CAD for a single production account or subscription, and the engagement is mostly not what the name suggests. You are not attacking Amazon, Microsoft or Google. You are being tested on the half of the platform you configured: identity and access policies, storage exposure, network rules, secrets handling, and the privilege paths between your own workloads. The exploitation half exists, but it lives in the applications and APIs you deployed, not in the platform underneath them.
Where the test boundary sits
Every provider publishes a shared responsibility model, and it is the scoping document for this engagement. The provider owns the hypervisor, the physical facility, the managed service internals and the control plane software. You own identity, configuration, network policy, data, and everything you deployed. A cloud penetration test covers your side only. A firm offering to test the other side is misdescribing what they do or breaking a contract you signed.
| In scope for you | Not yours to test |
|---|---|
| Identity policies, roles, trust relationships, federation | The provider identity service itself |
| Storage bucket and container permissions, public exposure | The storage platform implementation |
| Security groups, network access rules, peering and exposure | The physical and virtual network fabric |
| Serverless function permissions and code | The function runtime and the isolation between tenants |
| Managed database configuration, encryption, access | The managed database engine itself |
| Container images, orchestration settings, node configuration | The managed control plane |
| Secrets handling and key management usage | The key management hardware |
What each provider permits, which nobody explains well
All three major providers publish terms covering customer security testing, and the shape is the same: testing your own resources is allowed without asking permission, and anything that generates volumetric load or touches another tenant is not. The documents change, so read the current version before the engagement starts. Put the link and the date you read it in the rules of engagement document. That is the artifact that protects you if a test triggers an abuse report.
| Provider | Pre-approval | Where the line sits |
|---|---|---|
| Amazon Web Services | Not required for the services named in their customer support policy for penetration testing | Denial-of-service and any load-generating simulation need a separate request under their simulated events process. Testing resources you do not own is prohibited outright |
| Microsoft Azure | Not required for your own subscriptions, under their published rules of engagement | No denial-of-service, no testing of other tenants or of shared infrastructure, and phishing against Microsoft staff is out |
| Google Cloud | No notification required, but the acceptable use policy and terms of service still bind you | Stay inside your own projects, and nothing that degrades service for anyone else |
The clause people miss
Permission from your cloud provider is not permission from your software vendors. If your product depends on a payment processor, an identity provider or a data platform running as a hosted service, testing that service is covered by its own terms, and several of them prohibit it without written consent. The same applies in reverse when you are the vendor: your customers will eventually want to test you, so decide your answer before the first one asks.
Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.
What a cloud test actually finds
The finding classes are stable across providers because the mistakes are architectural rather than product-specific.
| Finding | Where it leads |
|---|---|
| An over-permissioned role attached to a compute instance | One compromised application becomes account-wide access |
| A trust policy that allows assumption from too broad a principal | Cross-account access, sometimes from outside your organization |
| Storage readable by any authenticated user of the platform | Data exposure that a public-access check does not catch |
| Secrets in environment variables, build logs or user data | Credentials recoverable by anyone who can read metadata |
| Instance metadata reachable through a request-forgery flaw in the app | Application vulnerability turned into cloud credentials |
| Management interfaces reachable from the internet | Direct administrative exposure, usually from a temporary rule |
| Logging disabled or writable by the identities being logged | No usable evidence after an incident |
The most valuable output is not the list. It is the privilege graph: which identity can become which other identity, and the shortest path from a low-privilege starting point to your data. That is the reason to pay a person rather than run a posture management tool. A tool cannot judge it, because it depends on knowing which data matters.
Scoping a cloud engagement
Scope by account or subscription, by environment, and by whether the application layer is included. Those three decisions move the price more than anything else.
| Engagement | Tester days | Typical range |
|---|---|---|
| Configuration and identity review, one production account | 4 to 7 | $8,000 to $18,000 |
| Multi-account or multi-subscription organization | 7 to 12 | $15,000 to $28,000 |
| Kubernetes cluster review added | 3 to 5 | $6,000 to $13,000 |
| Cloud review plus the application on top of it | 10 to 18 | $20,000 to $45,000 |
Give the tester read-only access with the ability to enumerate policy. A cloud review conducted from outside is guesswork: it reports what is publicly visible, not how your account is put together. This is the grey box argument from test types compared, and it applies more strongly here. Nothing about identity configuration is discoverable from the internet.
What this does not replace
A cloud review does not test your application logic and does not test your API authorization. Those are separate surfaces with separate methods, covered on web application security testing and API penetration testing. It also does not replace a posture management tool running continuously. The tool catches the drift that happens on a Tuesday afternoon; the review catches the design decision that made the drift possible.
For a company whose entire estate is a cloud account, the sensible annual package is an authenticated application test plus a cloud configuration and identity review, quoted as one engagement with one report. That combination satisfies what auditors ask for under SOC 2 and ISO 27001 without paying for an internal network test of a network that does not exist.
Scope a cloud engagement
Tell us which provider, how many accounts, and whether the application is included, and we will put one scope in front of Canadian firms.
Get matchedCommon questions
Do we need permission from AWS, Azure or Google to run a penetration test?
Generally no for testing your own resources, under each provider's published customer testing terms. The exceptions are load-generating activity, denial-of-service simulation and anything that reaches beyond your own account, which are either prohibited or need a separate request. Read the current version of the provider's document during scoping and attach it to the rules of engagement, because the terms have changed before and the copy in a blog post from three years ago is not a defence.
Is a cloud posture management tool enough for our auditor?
For continuous monitoring evidence, often yes. For the annual independent testing expectation, usually not, because a tool your own team runs is not independent and does not produce the exploitation evidence an auditor associates with a penetration test. The practical arrangement is the tool for continuous coverage and an independent review once a year that checks the things the tool cannot judge, starting with whether the roles make sense.
Can the tester work from a read-only role?
For the review portion, yes, and that is the normal arrangement. Some exploitation steps need more, for example demonstrating that a privilege path is real rather than theoretical. Agree in advance which demonstrations are permitted and in which environment, and expect the report to distinguish between paths that were proven and paths that were identified from configuration and not exercised.
What about testing a SaaS product we buy rather than build?
You almost certainly cannot test it, because their terms prohibit it and the environment is shared with other customers. What you do instead is vendor due diligence: ask for their most recent test report or summary letter, ask what was in scope, and check the date. That is a vendor-management control rather than a testing activity, and your auditor treats it as one.
Does Canadian privacy law affect a cloud test?
It affects the contract more than the testing. If the account holds personal information about people in Canada, the testing firm is handling that information on your behalf, so accountability under PIPEDA and under Quebec's Law 25 stays with you and has to be reflected in the agreement: what they may access, where it is stored, how long they keep it and how it is destroyed. Ask for evidence of destruction after the report is accepted.