Cloud penetration testing guide for AWS, Azure and GCP

Cloud penetration testing for AWS, Azure or GCP must assess customer configuration, identity, service relationships and application layers while respecting provider policy. Paying for a resource does not authorise testing shared infrastructure, other tenants or provider staff.

A strong scope separates provider responsibility from customer-controlled assets and identifies actions requiring additional approval.

Read the provider policy first

AWS, Microsoft Azure and Google Cloud publish testing and prohibited-use rules. Save the current policy at engagement start because terms can change.

Testing your own instances and applications is commonly allowed, while DoS, interference with other customers, heavy load against managed services, social engineering of provider staff and attempts to leave the assigned tenant remain prohibited.

Cloud pentest scope

Identity and IAM

Review roles, trust policies, service principals, managed identities, access keys, MFA and role assumption. Focus on chains: a modest permission combined with PassRole, function deployment or policy changes can become administration.

Storage and data

Test public access, bucket policy, signed URLs, encryption, backups, snapshots and cross-account paths. A “private” label does not prove that every identity has appropriate access.

Network and edge

Assess security groups, NSGs, firewalls, load balancers, private endpoints, DNS and administration. Map paths from the internet and from a compromised workload towards management services.

Containers, serverless and CI/CD

Examine pod/function roles, secrets, registries, metadata services, deployment pipelines and artefact replacement. A user who can modify function code may inherit its broader runtime role.

Logging and detection

Verify CloudTrail, Azure Activity Logs, GCP Audit Logs, data events and retention. Execute agreed techniques and confirm that they create actionable alerts, not only raw records.

Rules of engagement

List accounts, subscriptions, projects, regions, source addresses, hours, API limits, test data, prohibited actions and emergency contacts. Separate read from write. Deletion, production shutdown, real-data access and costly load require additional approval.

Use a dedicated tester identity rather than a shared administrator. Logs should clearly attribute exercise activity.

Grey-box testing provides deeper coverage

Architecture, account inventory, Terraform and role information allow faster discovery of complex paths. Black box is useful for public exposure but cannot efficiently cover thousands of IAM relationships.

Combine external perspective, ordinary-user access, a constrained workload role and configuration review. Use our penetration-test preparation guide for evidence and access planning.

Reporting and retesting

Every finding identifies asset, condition, permission path, evidence, impact and an IaC or policy fix. Include ARN/resource ID, region and affected environment.

Retest alternative paths. Removing one policy is inadequate when the same permission returns through a group, role or deployment pipeline.

---

Evidence and a safe test identity

Create a separate tester identity with time-bound access and complete logging instead of sharing a standing administrator key. Scope names accounts, subscriptions, projects, regions, managed services and SaaS components the cloud customer does not control. Confirm current provider rules before testing; they vary by service and can change.

The report reconstructs a path from exposure or low privilege to data and resource control. Record policy IDs, roles, trust policies and audit events without extracting more data than the proof requires. Remove test resources, tokens and network exceptions afterwards, then confirm that state in logs and IaC.

Sources: AWS Penetration Testing, Microsoft Cloud Penetration Testing Rules, Google Cloud AUP.