Cloud Penetration Testing Checklist for AWS, Azure and GCP

Cloud penetration tests have a reputation for being slow to start. Access requests stall, the wrong accounts get scoped, and testers spend the first days waiting for permissions. Almost all of that is avoidable. This checklist covers what to settle before testing, what a good engagement should examine on AWS, Azure and Google Cloud, and what you should expect at the end.

Before testing: provider policy and permissions

AWS, Microsoft Azure and Google Cloud each publish their own rules for penetration testing on their platforms. In recent years, most common services have stopped requiring pre-approval, but each policy still lists prohibited activities, such as denial-of-service testing, and some services carry special conditions. Policies change, so read the current version for each provider you use and keep a copy with your engagement records.

Provider permission is not the same as your own authorisation. You still need written approval from whoever owns each account in scope. If any workload belongs to a third party, such as a managed service or a SaaS integration, get their permission too or leave it out.

Pre-engagement checklist

• Inventory every AWS account, Azure subscription and GCP project in scope, with an owner for each
• Note the organisation structure: management accounts, management groups or folders
• Create a dedicated tester identity with read-only security review permissions
• Decide whether testers may deploy small test resources, and in which account
• List production workloads that must not be disrupted
• Share infrastructure-as-code repositories if a white box review is wanted
• Confirm tester source IPs and notify your monitoring team, unless detection is being tested
• Agree how critical findings will be escalated during testing

Our general scoping guide covers rules of engagement in more detail.

What the test should cover

A cloud pentest goes beyond a configuration benchmark. It asks how weaknesses combine. The table lists the main areas and their equivalents across the three major providers.

Multi-account and multi-cloud estates

Large estates rarely live in one account. Production, staging, shared services and logging often sit in separate accounts, subscriptions or projects, sometimes across more than one provider. Effort grows with the number of distinct environments rather than raw resource count, because each one has its own identities, network rules and owners.

If the estate is large, consider testing a representative sample in depth this round and reviewing the organisation-wide guardrails that apply to everything. Rotate the remaining environments into later rounds. Testers should always check cross-account trust, since a weak link between staging and production can undo good controls in both.

Identity is usually the centre of gravity

In cloud environments, identity often matters more than network position. A single over-permissive role attached to a function, or an access key committed to a repository, can open more than any exposed port. Testers trace which identities can assume or impersonate others, which can modify policies, and which can read secrets. The most serious findings are often chains: a readable storage bucket holds a key, the key belongs to a role, the role can change policies.

If your cloud identity is linked to an on-premises directory, include that link in scope. Our Active Directory assessment guide covers the on-premises side.

Workloads running in the cloud

Applications hosted in the cloud still need application testing. A web application or API pentest can be combined with a cloud review so testers can follow a finding from the application into the platform underneath, for example from a server-side request flaw to instance credentials.

Sizing a cloud engagement

Providers usually size cloud work by the number of accounts or subscriptions, the main services in use and whether hands-on workload testing is included alongside configuration review. A single account with a handful of services may need a few tester-days; a multi-account organisation with containers and serverless workloads needs considerably more. The cost calculator gives a first estimate.

During testing

1. Kick-off call. Confirm access works, review scope and agree escalation contacts.
2. Configuration review. Testers enumerate settings across accounts and compare against good practice such as the CIS Benchmarks for each provider.
3. Attack path analysis. Findings are combined to see what a realistic attacker could reach.
4. Targeted testing. Exposed services and workloads are tested hands-on within the agreed rules.
5. Interim updates. Critical issues are reported as soon as they are confirmed.

After testing: what to expect

• An executive summary of the most important risks
• Findings with evidence, severity and provider-specific remediation steps
• Attack path diagrams showing how issues chain together
• Recommendations for guardrails that prevent the same issues returning, such as organisation-level policies
• A retest of fixed findings; see the remediation and retesting guide

Cloud estates change quickly. Pair the pentest with continuous configuration monitoring, and revisit the test when you add accounts, regions or major services. Our guide on testing frequency helps set the rhythm.

Frequently asked questions

Planning a cloud review? See our cloud pentest service, estimate effort with the cost calculator, or request a quote.