Cloud Penetration Testing: AWS, Azure, and GCP

Where the responsibility actually sits

Every cloud provider publishes a shared-responsibility diagram. The honest summary: the provider secures the platform, you secure everything you configure. For pentest scope this matters because the provider side is essentially out of scope (they do their own testing and run a bug bounty), and the customer side is essentially everything else.

What "the customer side" includes:

• Identity and access management. Roles, policies, federation, service accounts, conditional access.
• Network configuration. Security groups, NACLs, VPC peering, transit gateways, private endpoints.
• Data protection. Storage permissions, encryption keys, key rotation, sharing settings.
• Workload security. Compute, containers, serverless, application code running on top.
• Monitoring and logging. Trail completeness, retention, tamper-resistance, alert routing.

What the providers permit

All three major providers permit penetration testing of customer-owned resources without prior approval for most service categories. The exceptions are narrow but real:

• AWS. Customer-permitted services include EC2, RDS, CloudFront, Aurora, API Gateway, Lambda, Elastic Beanstalk, and many others. Activities like DNS-zone-walking against Route 53 or distributed-load testing remain restricted and may need approval.
• Azure. Microsoft permits security testing of your own resources subject to the Microsoft Cloud Unified Penetration Testing Rules of Engagement. Network-stress testing of Azure infrastructure remains out of scope.
• GCP. Google permits testing of your own projects and resources without notification. As with the others, do not test Google's underlying infrastructure or other customers.

For a real engagement, the relevant question is rarely "is testing allowed" — it almost always is. The relevant question is which assessment-access model you will use to give the tester the visibility they need.

The cloud findings we see most

Across engagements, six categories show up disproportionately often:

1. Overly permissive IAM

Wildcards in IAM policies. Roles with *:* permissions. Service accounts with permissions far beyond what they actually use. Trust policies that allow assumption from accounts you do not control. The blast radius of a compromised role correlates almost perfectly with how broad the policy is.

2. Public data that shouldn't be

Public S3 buckets, blob containers, and GCS buckets — usually because of an inherited policy or a temporary share that became permanent. Public RDS or Cosmos DB instances. Public KMS keys. Each provider gives you tooling to detect these; they keep happening anyway.

3. Network exposure

SSH or RDP open to 0.0.0.0/0. Management interfaces of databases, message queues, and cache layers reachable from the public internet. Default-VPC drift. The cloud equivalent of leaving a perimeter port open — same impact, fresher language.

4. Secrets in IaC and CI

Hardcoded credentials in Terraform state, in CI pipelines, in container images. Secrets stored in environment variables that show up in logs. Long-lived API keys that should have been short-lived OIDC tokens.

5. Identity federation paths that bypass MFA

SSO is configured for the console; programmatic access still uses long-lived access keys. Conditional access requires MFA for human roles but waives it for service accounts that can be impersonated. The bypass is usually an oversight, not a decision.

6. Logging gaps

CloudTrail, Activity Log, or Audit Logs not enabled in every region. Logs writeable by the same role being audited. No retention policy. No alerting on critical actions like IAM-policy changes or KMS-key deletion.

How the engagement actually differs across providers

The categories above appear in every cloud, but the testing tooling and the highest-leverage findings shift:

Area	AWS	Azure	GCP
Identity primitives	IAM roles, policies, STS	Entra ID, RBAC, Managed Identities	Service accounts, IAM bindings
Common trap	Wildcard policies, AssumeRole graphs	Owner-role sprawl, overprivileged Service Principals	Project-level Editor role overuse
Network model	VPCs, security groups, NACLs	VNets, NSGs, Application Gateway	VPCs, firewall rules, Private Service Connect
Common finding	0.0.0.0/0 ingress, public S3	Public storage, NSG drift, exposed Service Bus	Public GCS, broad firewall rules, public Cloud SQL
Useful native tools	IAM Access Analyzer, Trusted Advisor, Macie	Defender for Cloud, Entra ID conditional access	Security Command Center, Recommender
Open-source go-to	Prowler, ScoutSuite	ScoutSuite, AzureHound	ScoutSuite, GCPBucketBrute

Containers and serverless

Two surfaces that increasingly belong in cloud pentest scope:

• Kubernetes / containers. RBAC bindings, pod security, secrets in environment, sidecar trust, ingress configuration, image registry permissions. Cloud-managed Kubernetes (EKS, AKS, GKE) layers cloud IAM on top of Kubernetes RBAC, doubling the trust surface to verify.
• Serverless. Lambda / Functions / Cloud Functions inherit cloud IAM. The most common findings are functions that can read secrets they do not need, functions that share execution roles by default, and event-source mappings that allow unauthenticated invocation.

How to scope a cloud engagement honestly

Three inputs determine the right scope:

• The driver. Compliance audit, board concern, post-incident review, or pre-launch hardening. Each shapes the depth differently.
• The blast-radius surfaces. Where would a single compromised role cause the most damage? Production data store, payment processor, customer-data exports, identity provider. Test those first.
• The access model. Read-only assessment access plus time-boxed write where required, with rollback plans documented.