Cloud penetration testing: what we actually test in your AWS

The boundary is described by the shared responsibility model, and AWS names it with two phrases. “Security of the cloud” belongs to AWS: the hardware, software, networks, and facilities the services run on. “Security in the cloud” belongs to the customer: the data, permissions, configuration, and applications. A penetration test concerns only that second half.

That boundary isn’t fixed, and for scoping that matters more than the definition itself. The shared responsibility model says the extent of the customer’s responsibility depends on the services the customer chose. With virtual machines, the customer keeps operating system updates, application security, and the security group settings. With managed services like S3, AWS runs the infrastructure and the platform, and the customer is left with data, encryption, and permissions.

AWS divides controls into inherited, shared, and customer-specific. The middle group includes patching the hosted operating system and applications, and that is a control on the customer’s side, not on AWS’s. That’s why scoping a cloud test starts with a list of services, not a list of IP addresses.

In the cloud the weight of the flaws shifts from versions to permissions. This is our experience from tests, not a measured fact: with managed services the customer has nothing to patch, while every application and every person adds another role, policy, and key to the account.

Specifically, we test IAM roles and their real reach, that is, what an identity is actually allowed to do, not what its description says. Then access keys and application tokens, where they’re stored and how long they’re valid, and the conditions in policies, that is, under what circumstances an identity may perform a given action. The goal is to find out whether a limited identity can reach account administrator rights.

In the account we start from four things. Who may assume which role, that is, role trust policies and the sts:AssumeRole call. The iam:PassRole permission, which lets a role be attached to a service during its setup so the service can then assume it. And the age of access keys, along with when and against which service they were last used, which we read from the IAM credential report.

The fourth, on EC2 instances, is the instance metadata service (IMDS), which issues temporary credentials for the role the instance carries. We want to know whether IMDSv2 with a token is enforced, because without it a single request from an application running on the instance is enough to read those credentials.

Escalation through passed roles is flagged by the AWS documentation on the PassRole permission itself: anyone who may pass a role with higher rights than their own opens a way forward. When such an attempt succeeds, we look for the specific call behind it in CloudTrail. What is visible there depends on your setup: routine administrative operations are traceable in the account for 90 days even without configuration, whereas reads of data from storage are logged only if you turn that on.

There’s only partial external support for this view, and it’s fair to say so. The Cloud Security Alliance’s Top Threats to Cloud Computing 2024 ranks misconfiguration first and identity and access management second, while system vulnerabilities come only eighth. But it’s a survey of perceived severity among professionals, not a measurement of how often incidents happen, and it says nothing about change over time.

For S3 storage the test looks at three things: who reaches the content, whether it’s encrypted, and what happens when someone deletes or overwrites an object. We check the Block Public Access setting at the organization, account, and individual bucket level, bucket policies against IAM policies, encryption at rest, and the versioning setting.

But a bucket’s own setting can’t be judged without identities. An application meant to have the right to read one bucket may hold a role that lets it list them all, and the storage configuration won’t show it. That’s why storage and permissions are tested together, not as two separate chapters.

One thing the test deliberately doesn’t do: bucket takeover. AWS lists it among prohibited activities, so a finding like that is documented with the configuration and a description of the impact, not by carrying it out.

AWS names the services you may test on your own infrastructure without prior approval. They’re listed in the AWS Customer Support Policy for Penetration Testing, and for services off the list it points to AWS Support or your account representative. That is the state as of August 19, 2026.

Some scenarios must be reported in advance. Red team, blue team, and purple team testing, volumetric tests, simulated phishing, and malware testing are submitted through the Simulated Events form, at least two weeks before the start.

Some are prohibited entirely. That covers denial of service, including simulated denial of service, flooding of ports, protocols, and requests, S3 bucket takeover, subdomain takeover, and interference with DNS through Route 53, zone walking included. A simulated DDoS has its own route outside the penetration testing rules: only a pre-approved partner may run it, and the target must be covered by AWS Shield Advanced. So it isn’t part of an ordinary cloud engagement.

AWS doesn’t give a last-updated date for these rules, so we verify them again before every engagement and adjust the scope to them. For cloud testing, our team holds the CCPenX-AWS certification, Certified Cloud Pentesting eXpert-AWS from The SecOps Group. It’s a hands-on, CTF-style exam lasting seven hours.

The effort rests on four variables: the number of AWS accounts, the number of regions, the number of services actually running in the account, and the number of identities, that is, users, roles, and machine accounts. In calendar time it’s two weeks from the start to report delivery.

The number of servers is a weak guide in the cloud. An account with two instances and forty roles is more work than an account with twenty instances and a single role, because what’s tested is the relationships between identities, not the machines. So we break down what the cloud effort is calculated from.

An application running in the account is a separate test target. We test an application running on that infrastructure separately, because its flaws are in the code and in the authorization inside the application, not in the account configuration. The two can be combined into one engagement, and the effort is then added up.

You want a cloud test when your data and services run in AWS and you need to know what someone with a stolen key or a supplier’s account can do with them. The network and domain environment you run yourself is a separate service and is tested with different techniques.

From a cloud security audit the test differs in what it does with a finding. An audit or posture review compares the configuration with a recommended state and lists deviations, which a tool can do. The test tries to exploit the deviation and documents the chain of steps that led there. Both make sense side by side: the audit covers the breadth of the account, the test the depth of one path.

Where the cloud fits in the breakdown by test target is described by the glossary entry on the types of tests. Scoping, the process, and the retest are no different for a cloud engagement than for the others: we’ve written up what every engagement of ours has in common once for all services. For the cloud, the target, the techniques, and the provider’s rules change.