What cloud penetration testing actually tests

Cloud pentesting for AWS, Azure, and GCP tests three different things under one label. Each platform uses a distinct IAM model, a different metadata service, and its own authorization rules. A methodology built for AWS will miss the highest-value attack paths on Azure. A GCP-focused test will not find the IMDS SSRF chain that dominates AWS breaches. Treating cloud pentesting aws azure gcp as one skill produces reports that miss the exploitable paths.

Key Takeaways

• AWS, Azure, and GCP each use different IAM models, metadata endpoints, and authorization rules, so one pentest methodology cannot cover all three properly.

• AWS pentests center on IMDS exploitation and IAM privilege escalation; the 2019 Capital One breach used exactly this path to reach 100 million records.

• Azure pentests target Managed Identity token theft that pivots through Entra ID into Microsoft 365, Graph API, and Key Vault across a single tenant.

• GCP pentests focus on downloadable JSON service account keys, a structural problem AWS and Azure mostly avoid through short-lived credentials.

• Every cloud test requires two permissions: one from the account owner, one from the provider, with rules that differ across AWS, Azure, and GCP.

Cloud pentesting targets the control plane, not just cloud-hosted virtual machines. The high-value surface is IAM roles, service identities, metadata APIs, and cross-service trust relationships. Scanning VMs for open ports misses the misconfigured role that lets an attacker escalate to admin without touching a single server.

Under the AWS Shared Responsibility Model, the provider secures the underlying infrastructure. You configure the identities, policies, and network paths on top of it. Every AWS, Azure, and GCP breach we have seen in audits traces back to something the customer configured, not to a hypervisor failure.

According to IBM's 2024 Cost of a Data Breach Report, the global average cost of a data breach reached $4.88 million, the highest figure IBM has recorded. Breaches involving cloud environments consistently drive the most damage because a single compromised identity can access data across regions, services, and accounts before anyone notices.

A "cloud pentest" that runs Nessus against an EC2 fleet is a network pentest with a cloud-shaped price tag. It is not the test you need.

How does AWS pentesting differ from other platforms?

AWS pentests center on two things: IAM policy misconfigurations and the Instance Metadata Service (IMDS) at 169.254.169.254. An attacker who reaches the IMDS endpoint retrieves temporary STS credentials for the attached IAM role. No authentication required.

The 2019 Capital One breach followed this path exactly. Paige Thompson used an SSRF vulnerability in a misconfigured WAF to hit the IMDS, extracted IAM credentials, and accessed over 100 million customer records stored in S3. AWS later introduced IMDSv2, which requires a session token, but IMDSv1 remains enabled on a large share of production accounts we audit.

Three IAM privilege escalation paths appear most often in real engagements: iam:PassRole combined with a permissive target role, iam:CreatePolicyVersion on an existing policy, and iam:AttachUserPolicy against a lightly-privileged user. Cross-account AssumeRole trust policies extend lateral movement into other AWS accounts inside the same organization, often silently.

Gartner has forecast that through 2025, 99% of cloud security failures will be the customer's fault, meaning IAM configuration, not platform vulnerability. That prediction matches what we see. The AWS platform is not broken. The way teams configure it is. We covered specific incidents in AWS misconfigurations that killed real companies.

What makes Azure pentesting structurally different?

Azure pentests revolve around Managed Identities and the token endpoint exposed via the Azure IMDS. Unlike AWS, Azure uses a unified identity layer through Entra ID (formerly Azure AD). A compromised Managed Identity can pivot into Microsoft 365, Azure DevOps, Key Vault, and other Microsoft services in the same tenant.

Token-based lateral movement across services is the defining shape of an Azure engagement. Once a tester extracts an OAuth token from the metadata endpoint of a compromised VM or container, the question is not "what can this token do in Azure" but "what can it reach through Microsoft Graph."

User-assigned Managed Identities create shared identity surface across every resource attached to them. System-assigned identities are scoped to a single resource. Most Azure environments we audit mix both, with the user-assigned type over-permissioned and reused across environments that should be isolated.

The Microsoft penetration testing rules of engagement permit testing your own tenant without prior approval, but Owner and Contributor roles assigned to automation service principals show up in nearly every Entra ID audit we run. A single stolen automation token can rewrite RBAC across the tenant before detection tools notice.

Why is GCP pentesting a different problem?

GCP pentests focus on service account keys and OAuth 2.0 scope abuse. GCP still permits users to create and download long-lived JSON key files for service accounts. Those keys do not expire unless someone manually rotates them, and they appear regularly in GitHub repositories, CI/CD configs, and container images.

The structural difference matters. AWS uses short-lived STS credentials by default. Azure hands out short-lived JWTs. GCP hands out both short-lived tokens through metadata.google.internal and, if you ask for one, a permanent JSON file that lives forever in someone's Downloads folder.

The cloud-platform OAuth scope is the second GCP-specific problem. A service account granted this single scope has full API access to the project, regardless of what the workload actually needs. Google's testing guidelines point to Workload Identity Federation as the intended replacement for downloadable keys, but adoption in existing GCP estates is slow.

IAM Recommender surfaces excessive permissions using ninety-day access data. It is a useful tool. It is not a substitute for someone testing whether a JSON key from a public repo actually works against your production project.

Do you need permission to pentest cloud accounts?

You need two levels of permission before any cloud test starts: authorization from the account owner (always required) and compliance with the cloud provider's rules of engagement (varies by platform).

AWS does not require prior notification for permitted services. It publishes a prohibited list covering DNS zone walking, DDoS simulation, and port flooding, but IAM analysis, EC2 exploitation, and S3 testing proceed without a form. Azure requires you to acknowledge the Microsoft rules of engagement and stay within the tenant you own. GCP requires that you review Google's testing scope guidance before assessing anything beyond your own resources.

"I own the account, so I can test whatever I want" is legally incorrect in all three cases. Testing infrastructure that shares a hypervisor with other tenants can trigger provider incident response, void support agreements, or expose the tester to CFAA-style liability in the US and equivalent statutes across the EU.

We wrote more on scoping and paperwork in how to survive your first pentest and the 7 pentesting mistakes that make reports useless.

AWS vs Azure vs GCP: the attack path comparison

If your provider runs the same playbook across all three columns, they are running an AWS test on Azure and calling it complete.

Frequently Asked Questions

Can you pentest AWS infrastructure?

Yes. AWS explicitly permits security testing within accounts you own or have written authorization to test. The AWS penetration testing policy defines prohibited actions (DDoS simulation, DNS zone walking, port flooding) but does not require prior approval for IAM analysis, EC2 exploitation, or S3 bucket testing. The account owner must authorize all tests in writing before any activity begins.

Do you need permission to pentest cloud accounts?

You need two permissions. First, from the account owner, always required regardless of platform. Second, from the cloud provider, with rules that vary. AWS requires no prior notification for permitted services. Azure requires you to follow the Microsoft rules of engagement. GCP requires reviewing Google's testing scope guidance. Testing without account-owner consent is illegal under computer fraud laws in every major jurisdiction, independent of provider policy.

How does an AWS pentest differ from an Azure pentest?

AWS pentests center on IAM role misconfigurations and IMDS exploitation, with SSRF vulnerabilities as the most common entry path to credentials. Azure pentests focus on Managed Identity token theft and lateral movement through Entra ID into the broader Microsoft ecosystem, including Graph API, Exchange, and Key Vault. The objective is the same. The technical execution and the crown-jewel targets differ substantially.

What is cloud penetration testing?

Cloud penetration testing simulates real-world attacks against cloud-hosted infrastructure to find exploitable misconfigurations before adversaries do. It targets the control plane (IAM, service identities, metadata endpoints, cross-account trust) rather than only the operating system or application layer. That is what distinguishes it from a traditional network pentest, where the primary attack surface is open ports and vulnerable services.

The three-platform reality

If your pentest provider runs an identical methodology across AWS, Azure, and GCP, they are missing platform-specific attack paths. The IMDS token endpoint behaves differently on each platform. IAM privilege escalation chains are AWS-specific. JSON key sprawl is a GCP problem Azure structurally avoids. A useful cloud engagement treats these as three environments, not three flavors of the same product.

For companies preparing for NIS2 compliance, the shift is already binding. Regulators expect cloud-specific testing evidence, not generic vulnerability scans against public IPs.

Most B2B cloud estates we audit have 4-6 exploitable identity findings sitting in plain sight, and none of them show up in a Nessus report. If you want to know what's actually exploitable in your stack, book a scoping call through Gravidy's security services. Thirty minutes, findings mapped to your platform, no slide decks.