Migrating to the cloud does not eliminate security risk — it transforms it. AWS, Azure, and GCP handle infrastructure-level protections, but the responsibility for securing configurations, identities, data, and workloads still falls on your organisation.
Cloud penetration testing is a controlled security assessment that simulates real-world attacks against your cloud environment. Unlike automated scanning, a cloud pentest uses manual techniques to chain together misconfigurations, overly permissive IAM policies, and exposed services into attack paths that actually compromise data.
This guide covers the methodology behind cloud penetration testing across all three major providers, the most common findings our pentesters encounter, and practical steps to harden your environment before an attacker finds what a scanner missed.
What Is Cloud Penetration Testing?
Cloud penetration testing is a specialised form of penetration testing that targets cloud-hosted infrastructure, services, and applications. The goal is to identify vulnerabilities that arise from cloud-specific configurations, shared responsibility gaps, and the unique architecture of platforms like AWS, Azure, and GCP.
Unlike traditional infrastructure pentests that focus on on-premise servers and network devices, cloud pentests must account for:
- Shared responsibility models — The provider secures the physical infrastructure, but customers own the configuration of everything above it.
- Identity-centric security — Cloud environments rely heavily on IAM (Identity and Access Management) policies rather than network perimeters.
- Ephemeral resources — Containers, serverless functions, and auto-scaling groups create dynamic attack surfaces.
- API-driven management — Every cloud resource is managed through APIs, making misconfigured API access a critical risk.
A cloud pentest does not test the provider’s infrastructure. AWS, Azure, and GCP each publish acceptable use policies that define what can and cannot be tested. The focus is entirely on your configuration, your applications, and your data within the provider’s platform.
The Shared Responsibility Model and Why It Matters
Every major cloud provider operates under a shared responsibility model, and misunderstanding it is the single most common source of cloud security failures.
What the provider secures:
- Physical data centres and hardware
- Hypervisor and host operating systems
- Network infrastructure between availability zones
- Core service availability (compute, storage, networking)
What you secure:
- IAM policies and access controls
- Network security groups and firewall rules
- Data encryption (at rest and in transit)
- Operating systems and application patching
- Storage bucket policies and access configuration
- Logging, monitoring, and incident response
Cloud penetration testing focuses entirely on the customer side of this boundary. The majority of cloud breaches — according to Gartner, through 2025 an estimated 99% — result from customer misconfigurations, not provider vulnerabilities.
Cloud Penetration Testing Methodology
Our cloud pentesting methodology follows a structured approach adapted for each provider’s unique architecture. Here is how a typical engagement unfolds.
Phase 1: Scoping and Reconnaissance
Before testing begins, we define the target environment with the client:
- Cloud accounts and subscriptions in scope
- Regions and services to include (or exclude)
- Compliance requirements driving the assessment (SOC 2, ISO 27001, PCI DSS)
- Testing boundaries — production vs. staging, time windows, notification procedures
Reconnaissance then maps the external attack surface: public S3 buckets, exposed storage blobs, open API gateways, DNS records pointing to cloud services, and publicly accessible management consoles.
Phase 2: Identity and Access Assessment
IAM is the backbone of cloud security. This phase evaluates:
- Overly permissive policies — Users or roles with
*:*permissions, admin access where read-only would suffice - Credential hygiene — Long-lived access keys, missing MFA on privileged accounts, unused service accounts
- Cross-account trust — Misconfigured role assumptions that allow lateral movement between accounts
- Privilege escalation paths — Combinations of permissions that allow a low-privilege user to escalate to admin (e.g.,
iam:CreatePolicyVersion,lambda:CreateFunctionwithiam:PassRole)
Phase 3: Network and Service Configuration
This phase tests the network layer and service-specific configurations:
- Security groups and NACLs — Overly permissive inbound rules (0.0.0.0/0 on SSH/RDP)
- VPC architecture — Missing network segmentation, public subnets hosting sensitive workloads
- Exposed services — Databases, caches, or message queues accessible without authentication
- Storage misconfigurations — Public S3 buckets, Azure Blob containers, or GCS objects with anonymous access
Phase 4: Application and Workload Testing
Cloud-native applications introduce unique attack surfaces:
- Serverless functions — Lambda, Azure Functions, and Cloud Functions with injection vulnerabilities, excessive permissions, or leaked environment variables
- Container security — Misconfigured Kubernetes clusters (EKS, AKS, GKE), exposed dashboards, privileged containers, and container escape paths
- API gateways — Missing authentication, broken authorisation, or excessive data exposure on API Gateway, Azure API Management, or Cloud Endpoints
Phase 5: Reporting and Remediation
Every finding is documented with:
- Business impact — What an attacker could actually achieve
- Technical details — Exact steps to reproduce
- Remediation guidance — Specific configuration changes, not generic advice
- Risk rating — Based on exploitability and impact
Provider-Specific Testing: AWS, Azure, and GCP
While the methodology remains consistent, each provider has unique services and attack vectors that require specialised knowledge.
AWS Security Testing
AWS remains the most widely adopted cloud platform, and its breadth of services creates a large configuration surface.
Common findings in AWS pentests:
- S3 bucket misconfigurations — Public read/write access, missing encryption, overly broad bucket policies
- IAM policy abuse — Wildcard permissions, unused access keys older than 90 days, roles assumable from external accounts
- EC2 metadata service exploitation — SSRF vulnerabilities chained with IMDSv1 to steal instance credentials
- Lambda function risks — Environment variables containing secrets, functions running with admin-level execution roles
- CloudTrail gaps — Logging disabled in specific regions, missing data event logging for S3
AWS testing note: AWS no longer requires pre-approval for most penetration testing activities. However, testing must comply with the AWS Customer Support Policy for Penetration Testing, which prohibits DNS zone walking, DoS attacks, and port flooding.
Azure Security Testing
Azure’s deep integration with Active Directory and Microsoft 365 creates unique hybrid attack paths.
Common findings in Azure pentests:
- Azure AD misconfigurations — Overly permissive app registrations, consent grant attacks, stale guest accounts with elevated privileges
- Storage account exposure — Containers set to public access, shared access signatures (SAS) with excessive permissions or no expiry
- Managed identity abuse — Virtual machines or App Services with system-assigned identities that have broader access than needed
- Network security group gaps — Default-allow outbound rules, missing NSGs on subnets, overly broad service tags
- Key Vault access — Applications with direct access to secrets when certificate-based authentication would be more secure
Azure testing note: Microsoft requires notification for penetration testing through the Azure portal. Testing against other Azure tenants or Microsoft services outside your subscription is prohibited.
GCP Security Testing
GCP’s organisation-level policies and resource hierarchy require careful assessment.
Common findings in GCP pentests:
- Service account key sprawl — Downloaded JSON keys in code repositories, keys shared across teams, missing key rotation
- Organisation policy gaps — Missing constraints on public IP assignment, external sharing, or service enablement
- GCS bucket exposure — Uniform bucket-level access not enabled, allUsers or allAuthenticatedUsers grants
- GKE misconfigurations — Clusters running with legacy ABAC enabled, node pools with default service accounts, missing Workload Identity
- VPC firewall rules — Overly broad ingress rules, missing egress filtering, firewall rules applied to all instances via default network tags
GCP testing note: Google Cloud does not require notification for penetration testing of your own projects. However, the Acceptable Use Policy prohibits testing that impacts other customers.
Top 5 Cloud Security Findings Across All Providers
After conducting hundreds of security assessments, these are the most frequent issues we find regardless of cloud provider:
- Overly permissive IAM policies — The most common and highest-impact finding. Principle of least privilege is rarely applied correctly.
- Public storage exposure — S3 buckets, Azure Blob containers, and GCS objects accessible to the internet, often containing sensitive data.
- Missing or inadequate logging — CloudTrail, Azure Monitor, or Cloud Audit Logs not capturing the events needed for detection and forensics.
- Stale credentials and access — Former employees’ access keys active, unused service accounts with elevated permissions, missing MFA enforcement.
- Unpatched or misconfigured workloads — EC2 instances, VMs, or containers running outdated software, exposed management interfaces, or default configurations.
When Should You Conduct a Cloud Penetration Test?
Cloud pentesting is not a one-time activity. Consider scheduling assessments when:
- After major migrations — Moving workloads to the cloud introduces new configuration risks
- Before compliance audits — SOC 2, ISO 27001, and PCI DSS assessments benefit from pre-audit pentesting
- After significant architecture changes — New VPCs, Kubernetes clusters, or serverless deployments shift the attack surface
- On a regular cadence — Quarterly or biannual pentests catch configuration drift and newly introduced risks
- After security incidents — Validate that remediation actually closed the attack path
BSG delivers cloud penetration testing results in 2-3 weeks with compliance-ready reports for technical teams, management, and auditors. Every engagement includes a 90-day free re-test to verify remediation.
Frequently Asked Questions
Is cloud penetration testing different from traditional penetration testing?
Yes. Cloud pentesting focuses on provider-specific misconfigurations, IAM policies, and cloud-native services rather than traditional network devices and on-premise servers. It requires specialised knowledge of AWS, Azure, and GCP architectures and their unique attack vectors.
Do I need permission from my cloud provider to conduct a pentest?
It depends on the provider. AWS no longer requires prior approval for most testing. Azure requires notification through the Azure portal. GCP allows testing of your own projects without notification. All providers prohibit testing that impacts other customers, denial-of-service attacks, and zone walking.
How much does a cloud penetration test cost?
Cloud pentest costs depend on the scope — number of accounts, services, and regions included. A focused assessment of a single AWS account or Azure subscription typically ranges from $5,000 to $15,000. Multi-cloud or enterprise-wide engagements are scoped individually. Contact BSG for a tailored quote.
Conclusion
Cloud environments are complex, dynamic, and unforgiving of misconfiguration. Automated scanners catch low-hanging fruit, but a skilled penetration tester chains together subtle misconfigurations into realistic attack paths that demonstrate actual business impact.
Whether you run workloads on AWS, Azure, GCP, or a combination of all three, regular cloud penetration testing ensures your configurations match your security intentions. The shared responsibility model means the provider will not catch these issues for you.
Ready to assess your cloud security posture? BSG’s OSCP and OSEP-certified pentesters deliver thorough cloud security assessments with actionable findings and compliance-ready reports. Plan your security assessment today.