Cloud Penetration Testing: AWS, Azure & GCP

Cloud penetration testing for AWS, Azure, and GCP is not simply a traditional network test moved into someone else's data center. It examines the identity, permissions, storage, workloads, APIs, and provider-specific controls that determine how far an attacker could move after gaining an initial foothold. For teams building a defensible program, this guide explains what a cloud assessment should cover and how it fits alongside penetration testing and vulnerability scanning.

Explore Ayewo for cloud security assessments

Why Cloud Infrastructure Needs Penetration Testing

Cloud providers secure the underlying facilities, hardware, and managed platform components. The customer still owns important decisions about identities, configurations, applications, data, network boundaries, secrets, and monitoring. A secure provider therefore does not make an incorrectly scoped role, public storage bucket, exposed API, or over-privileged service account safe.

Cloud environments also change faster than most traditional infrastructure. A new workload, federated identity, temporary role, infrastructure-as-code change, or third-party integration can create a path that was not present during the last annual review. A cloud penetration test gives a tester permission to examine those relationships as an attacker would, within a controlled scope.

The objective is not to prove that every cloud control is perfect. It is to answer practical questions:

• Can a low-privilege identity reach sensitive data or assume a more powerful role?
• Can an exposed workload use its service identity to move into another account, subscription, or project?
• Are storage, secrets, APIs, and management interfaces protected from the starting position defined in the rules of engagement?
• Would the security team see and respond to the techniques used during the assessment?

AWS Shared Responsibility: What AWS Does Not Secure for You

AWS secures the infrastructure it operates, while customers remain responsible for security in the cloud. The boundary depends on the service. With an infrastructure service such as EC2, the customer carries more responsibility for the operating system and workload. With a managed service, AWS operates more of the platform, but the customer still controls access, data, configuration, and how the service is used.

For an AWS assessment, that means reviewing the customer-controlled layer rather than testing AWS itself. Typical scope can include IAM users, roles, trust policies, permission boundaries, VPC routing, security groups, network ACLs, S3 controls, RDS exposure, Lambda and container permissions, API Gateway configuration, CloudFront behavior, secrets, keys, and logging. Cross-account access deserves specific attention because a trust relationship can turn a narrow compromise into access across an entire environment.

AWS permits security assessments of customer infrastructure for listed services without prior approval, but its current penetration testing policy sets important boundaries. Do not treat a provider policy as a substitute for customer authorization. Activities such as denial-of-service testing, certain Route 53 actions, and some simulated events have additional restrictions or are prohibited. The tester and asset owner should confirm the current policy before the statement of work is signed.

What Does a Cloud Penetration Test Cover?

A useful assessment combines automated coverage with human analysis. The exact test cases depend on the provider, workload architecture, access level, and business risk, but most mature scopes include the following areas.

Identity, access, and privilege escalation

Identity is the cloud control plane. Testers review users, groups, roles, service accounts, managed identities, federation, multi-factor authentication, access keys, permission boundaries, and trust relationships. They look for combinations of permissions that allow an attacker to become more privileged, access another workload, or bypass the intended separation between environments.

In AWS, this may involve IAM roles, STS trust, instance profiles, and permissions such as passing a role to a service. In Azure, the assessment may examine Entra ID, Azure RBAC, managed identities, app registrations, and tenant relationships. In GCP, testers examine IAM bindings, service accounts, project and organization inheritance, and workload identity paths. The finding is not merely that a permission exists. The meaningful question is whether it creates an exploitable path from an in-scope starting identity.

Network boundaries and management surfaces

Cloud networks are software-defined, so segmentation must be tested as configuration and behavior. Scope can include VPC or virtual network peering, security groups, firewall rules, private endpoints, load balancers, exposed management ports, administrative APIs, and paths between production, development, and shared services.

The test should distinguish an intentionally public service from an accidental exposure. It should also evaluate whether a public entry point can reach internal services, whether egress controls limit unexpected destinations, and whether network boundaries still hold when a workload identity is compromised.

Storage, secrets, and data paths

Assessors check whether object storage, databases, snapshots, queues, registries, and backups are reachable from the wrong identity or network location. They review public access, policy inheritance, access control lists, encryption configuration, key use, and the presence of sensitive data in locations that were not included in the original design.

Secrets in build logs, image layers, environment variables, serverless configuration, or source repositories can provide a faster path than a software exploit. The assessment should document the access path and demonstrate only the minimum necessary proof, without copying sensitive data or disrupting the workload.

Workloads, APIs, and cloud-native services

Cloud assessments often overlap with application, API, container, and serverless testing, but the cloud context adds a second question: what can the compromised component do next? The tester may assess API authorization, serverless event triggers, container registries, Kubernetes or managed container controls, image provenance, metadata access, and the permissions attached to runtime identities.

This is where a web application test and a cloud test diverge. A web test may prove that an endpoint accepts an unauthorized action. A cloud assessment traces the resulting identity and service permissions to determine whether that action exposes a broader account, subscription, or project compromise. Teams that need both scopes should define them separately so neither is assumed to cover the other.

Logging, detection, and response

A cloud penetration test should assess more than prevention. It should record whether relevant administrative actions are logged, whether logs are protected from alteration, whether detections alert the right team, and whether responders can reconstruct the activity. AWS CloudTrail, Azure Monitor and activity logs, and Google Cloud Audit Logs are examples of provider services that may be reviewed, but the test should follow the customer's actual detection architecture.

The result is an operational finding when a technically exploitable path is invisible to the security team or lacks an owner. That evidence can support security operations, incident response, and compliance work, including controls mapped to NIST, SOC 2, HIPAA, PCI-DSS, or CMMC where applicable.

AWS, Azure, and GCP: How the Assessment Focus Changes

The core questions are shared across providers, but their identity models, services, logging, and policy language differ. A single generic checklist is not enough.

• AWS: focus on IAM and STS relationships, account and organization boundaries, VPC controls, S3 and database exposure, instance and workload roles, Lambda and container permissions, and CloudTrail coverage.
• Azure: focus on Entra ID and tenant configuration, Azure RBAC, managed identities, app registrations, subscriptions and management groups, NSGs, storage, Key Vault, App Service, Functions, and activity logging.
• GCP: focus on organization and project inheritance, IAM bindings, service accounts, VPC firewall rules, Cloud Storage, GKE or serverless workloads, service perimeters where used, Secret Manager, and Cloud Audit Logs.

The assessment should also account for hybrid and multi-cloud trust. An Azure identity that can reach an AWS role, a CI/CD pipeline that deploys to all three providers, or a shared secrets platform can create a cross-provider path that no single-provider checklist will capture.

Hudson Infosec's Ayewo platform is positioned for automated vulnerability scanning, AI-powered penetration testing, and compliance reporting. Its AWS-ready virtual deployment can run in a customer VPC. For a mixed environment, use the provider-specific scope and confirm the assessment method and deployment path for each cloud before work begins.

Cloud Pentest Tools: Automated Versus Manual Approaches

Automation is valuable for breadth and repeatability. It can inventory resources, identify common configuration issues, compare permissions against policy, check exposed services, and support compliance-oriented evidence collection. It is particularly useful after infrastructure-as-code changes and during recurring validation.

Automation does not, by itself, establish exploitability. A posture check may report a broad permission, but it may not understand the trust relationship, compensating control, or realistic attack path. It may also miss a chain that requires several individually ordinary permissions.

Manual testing adds that context. A human tester validates the starting position, follows the path between services, confirms business impact, limits proof to what is necessary, and separates a theoretical exposure from a practical compromise. The strongest cloud program uses both approaches:

1. Inventory and baseline the environment with repeatable automated checks.
2. Use a human-led assessment to validate high-risk paths and provider-specific controls.
3. Retest fixes and keep automated checks running as the environment changes.

For MSPs, MSSPs, and small security teams, this hybrid model is also a capacity decision. Automated coverage reduces repetitive work, while manual review concentrates scarce expertise on identity paths, business-critical data, and meaningful attack chains.

How to Get Permission to Test Cloud Environments

Cloud-provider permission and asset-owner permission are different. Even when AWS, Azure, or GCP does not require advance notice for a standard test of customer-owned resources, a third-party tester still needs written authorization from the resource owner. That authorization should identify the legal entity, accounts or subscriptions, projects, domains, IP ranges, applications, test window, source addresses, and named contacts.

Before testing begins, document:

• The exact in-scope assets and excluded accounts, tenants, projects, regions, and third-party services.
• Permitted techniques, test credentials, rate limits, maintenance windows, and a stop condition.
• Whether production testing is allowed and which actions require prior approval from the customer.
• How sensitive data, credentials, logs, proof artifacts, and findings will be handled and deleted.
• The escalation path for an unexpected outage, suspected real compromise, or provider abuse alert.

Microsoft's Azure penetration testing guidance says pre-approval is not required for Azure resources, but customers and authorized third parties must follow the Microsoft Cloud Unified Rules of Engagement. Google's Cloud Security FAQ likewise says customers do not need to contact Google to test their own projects, provided the test affects only their projects and follows the applicable policies. AWS has a defined permitted-services policy and more specific restrictions, so verify its current page rather than relying on a general cloud-testing assumption.

Never start from a vague instruction such as "test our cloud." A precise scope protects the customer, the tester, neighboring tenants, and the continuity of the business.

What a Cloud Penetration Test Report Should Deliver

A useful report helps an engineering team decide what to fix first. It should include an executive summary that explains business impact without hiding technical detail, a clear scope and limitations section, the testing dates and access levels, and a method statement grounded in an established framework such as NIST SP 800-115.

Each finding should identify the affected resource, the starting position, the attack path, evidence, severity, likelihood, business consequence, and a practical remediation owner. Cloud findings should name the provider control or configuration involved, such as an IAM binding, trust policy, firewall rule, storage policy, runtime identity, or logging control. Where compliance matters, map the result to the customer's selected framework without implying that a penetration test alone creates compliance.

The engagement is not complete when the report is delivered. The team should prioritize remediation, confirm the change in the cloud environment, and retest the original path. The final record should show what was fixed, what risk was accepted, what remains outside scope, and when the environment needs another assessment.

View Ayewo's security assessment capabilities

Frequently Asked Questions

Is cloud penetration testing different from a web application test?

Yes. A web application test focuses on application behavior and authorization. A cloud assessment also examines identity, service permissions, storage, network boundaries, runtime identities, provider configuration, and how far an attacker could move after compromising a component. The two scopes can overlap at APIs and workloads, but neither should be assumed to replace the other.

Do AWS, Azure, and GCP require permission before a penetration test?

For standard testing of customer-owned resources, the major providers generally allow testing without the provider's advance approval, subject to their current policies. AWS has a defined permitted-services list and restricted activities. Azure requires compliance with its Rules of Engagement, and GCP requires tests to affect only the customer's projects and follow its applicable policies. The asset owner must still authorize the tester in writing.

How often should a cloud environment be tested?

Run a full assessment when a cloud environment is introduced, materially redesigned, acquired, or exposed to a new trust relationship. Add targeted validation after significant identity, network, application, or CI/CD changes, and keep automated checks running between manual assessments. The right cadence depends on change velocity, exposure, risk tolerance, and compliance obligations.

Can automated scanning replace a cloud penetration test?

No. Automated scanning provides breadth and repeatability, while a penetration test validates exploitability and attack paths in context. A practical program combines both, then retests the specific paths that were remediated.