AWS Penetration Testing: Rules, Scope, Attack Paths and How to Prepare

Cloud breaches rarely start with a kernel exploit. They start with an over-permissive IAM role, a public S3 bucket, a leaked access key in a repository, or a metadata service reachable from a vulnerable application. AWS penetration testing targets exactly those paths: the configuration and identity layer where real cloud compromises happen, plus, since 2025, the unpatched third-party software running on the instances.

What changed in 2026

The entry point moved. Exploitation of vulnerabilities in third-party software was the primary entry vector in 44.5% of cloud intrusions in the second half of 2025, up from 2.9% in the first half, overtaking weak or absent credentials (down from 47.1% to 27.2%) for the first time since Google began publishing the report. The window from a vulnerability's disclosure to mass exploitation shrank from weeks to days; React2Shell (CVE-2025-55182) was being exploited within 48 hours. (Google Cloud Threat Horizons Report, H1 2026)

Cloud-conscious intrusions rose 37% in 2025 and the average time from initial access to lateral movement fell to 29 minutes. (CrowdStrike 2026 Global Threat Report) And 27% of breaches that targeted AI models or applications came through cloud misconfigurations affecting AI workloads. (IBM Cost of a Data Breach Report 2026)

The practical consequence for an AWS test: identity and configuration review is still the core, but every internet-facing workload and the software version on it is now in scope from the first day. Our cloud security statistics page has the full set of figures.

The shared responsibility model decides what you can test

AWS secures the cloud; you secure what you run in it. That line determines your entire scope.

• AWS's responsibility: the hypervisor, physical hardware, and the underlying service infrastructure. You cannot test it, and you have no reason to.
• Your responsibility: IAM policies and roles, security groups and network ACLs, S3 bucket policies, Lambda functions and their execution roles, EC2 operating systems and the applications on them, RDS configuration, EKS and ECS workloads, secrets management, and logging.

Effectively everything worth testing in your AWS account is on your side of the line. AWS's own compliance reports (SOC, PCI, ISO) cover their infrastructure, never your configuration of it, and auditors are explicit about the distinction.

AWS's penetration testing policy, as published

AWS publishes a customer support policy for penetration testing. The current version says the following; check the page before every engagement, because the lists change.

Permitted without prior approval, against your own resources: Amazon EC2 instances, WAF, NAT Gateways and Elastic Load Balancers; Amazon RDS; Amazon CloudFront; Amazon Aurora; Amazon API Gateways; AWS AppSync; AWS Lambda and Lambda Edge functions; Amazon Lightsail resources; Amazon Elastic Beanstalk environments; Amazon Elastic Container Service; AWS Fargate; Amazon OpenSearch Service; Amazon FSx; Amazon Transit Gateway; Amazon Bedrock AgentCore; AWS Global Accelerator.

Prohibited: DNS zone walking via Amazon Route 53 hosted zones; denial of service and distributed denial of service; port flooding; protocol flooding; request flooding (including login and API request flooding); S3 bucket takeover; subdomain takeover.

Requires a Simulated Events request, at least two weeks in advance: command and control (C2) infrastructure, DDoS simulations, red, blue and purple team exercises, network stress testing, iPerf testing, phishing simulations, and malware testing. That covers a red team engagement and a phishing test that touches AWS-hosted mail or infrastructure, so those are scheduled with the form in mind.

If the test finds a vulnerability in AWS itself: the policy asks you to contact AWS Security immediately and report it within 24 hours of completing the test.

Two liability points: you are responsible for any damage your testing causes to AWS or to other customers, and resellers are responsible for their customers' testing. If a vendor manages the account, their written permission is part of the scope.

What actually gets tested

IAM, the highest-value target

IAM is where cloud compromises escalate. Testing looks for:

• Over-permissive policies: wildcard actions and resources ("Action": "*"), or AdministratorAccess attached to roles that need three permissions.
• Privilege escalation paths: a role that can call iam:PassRole, iam:CreatePolicyVersion, iam:AttachUserPolicy, lambda:UpdateFunctionCode, or ec2:RunInstances with a privileged instance profile can often bootstrap itself to full administrator. There are dozens of documented chains, and finding them means reading the policy graph, not running a scanner.
• Unused and stale credentials: long-lived access keys, users who left, roles created for a migration two years ago, keys with no rotation.
• Cross-account trust: roles trusted by third-party accounts more broadly than intended, or trust policies without an external ID.
• Missing MFA on privileged principals, and root account usage.

The 2026 identity data is why this section comes first: 79% of ransomware attacks began with an identity-based approach and 97% of victims whose credentials were stolen had MFA enabled somewhere, just not on the account that was used. (Sophos State of Ransomware 2026)

Compute and the software on it

This is the part that grew in 2026. EC2 instances, containers on ECS and EKS, and Lambda functions run third-party software: web frameworks, application servers, admin consoles, agents. The test inventories what is reachable from the internet, fingerprints versions, and checks them against known exploited vulnerabilities before anything else, because that is now the leading way in. Security groups exposing management ports (SSH, RDP, database ports) to 0.0.0.0/0, exposed container registries, and Kubernetes control planes reachable from the internet belong in the same pass.

S3 and data storage

Public buckets remain a leading cause of data exposure, but the subtler issues matter more: bucket policies granting access to AllAuthenticatedUsers (every AWS account in the world, not just yours), missing default encryption, disabled versioning and access logging, and pre-signed URL patterns that expose more than intended. Only about half of sensitive data stored in the cloud is encrypted, 47%, and only 34% of organizations say they know where all their data resides. (Thales 2026 Data Threat Report) The test finds the buckets nobody remembered.

The metadata service: where an application flaw becomes an account compromise

A server-side request forgery flaw in an application becomes a full account compromise when it can reach 169.254.169.254 and retrieve the instance role's credentials. IMDSv2 mitigates this by requiring a session token; instances still allowing IMDSv1 are a standing risk. This is the clearest example of why cloud testing and web application penetration testing belong in one engagement: the vulnerability is in the application, the impact is in the cloud.

Lambda, API Gateway and the serverless surface

Execution roles with more permissions than the function uses, secrets in environment variables, event sources anyone can trigger, and API Gateway stages without authorizers. Serverless removes the server from scope and adds the permission model in its place. An API penetration test covers the gateway itself.

Secrets and CI/CD

Hard-coded keys in code, container images or environment variables; over-privileged CI/CD roles; and the supply-chain path from a compromised pipeline into production. 48% of breaches involved a third party in 2025, including cloud platforms and OAuth integrations. (Verizon 2026 Data Breach Investigations Report)

Logging and detection

The test records whether CloudTrail, GuardDuty and Config would have caught each step. A finding that says "we reached the database" is less useful than one that says "we reached the database and nothing fired."

The two halves of a good AWS engagement

Half one: configuration review against the CIS AWS Foundations Benchmark. Identity and access management, logging, monitoring, networking and storage, checked against the benchmark with a read-only role. This is where the tooling earns its keep: Prowler, ScoutSuite, and AWS's own Config, Security Hub and IAM Access Analyzer enumerate misconfigurations at a scale no human can match.

Half two: exploitation from a realistic starting point. A compromised developer credential, an over-permissive role, or a foothold on one instance, then an attempt to escalate, move and reach data, with every action logged for your defenders. This is where a tester earns their keep. A scanner reports "role X can pass role Y" and "Lambda Z is invokable" as two separate medium findings; a tester recognizes that together they take an ordinary developer account to administrator, and proves it.

Most AWS engagements should be credentialed. A black box test of a cloud environment mostly proves what is publicly exposed, which is useful but a small slice of the risk. A typical setup provides a SecurityAudit or ReadOnlyAccess role for the configuration review, plus a standard user role that models the realistic starting point.

Compliance and AWS

Running in AWS does not remove your testing obligations; it relocates them.

• PCI DSS requires penetration testing of the cardholder data environment wherever it runs, including cloud-hosted segments and the segmentation controls between them. See PCI DSS penetration testing.
• SOC 2 auditors expect testing that covers the infrastructure the service runs on, not only the application. See SOC 2 penetration testing.
• HIPAA requires an evaluation of safeguards for systems that process electronic protected health information, including the S3 buckets and RDS instances that hold it. See HIPAA penetration testing.
• NYDFS Part 500 requires annual penetration testing of the covered entity's information systems, which for most New York financial firms now means their cloud accounts. See NYDFS penetration testing.

How to scope an AWS engagement

Have these ready and scoping takes one conversation:

1. How many AWS accounts are in scope, and is Organizations or Control Tower in use?
2. Which regions hold in-scope resources?
3. Rough resource counts: EC2 instances, S3 buckets, Lambda functions, RDS instances, EKS or ECS clusters.
4. Which applications are hosted there, and should they be tested in the same engagement?
5. Access model: what roles can you provide for the credentialed halves?
6. Multi-cloud? Azure or GCP alongside AWS changes the scope and the price.
7. Compliance driver, if any; it determines what the report must map to.
8. Anything that needs the Simulated Events form (red team, phishing), so the two-week lead time is built into the schedule.

Fixed prices for the standard scopes are on the cloud penetration testing pricing page; a typical engagement is five to ten testing days plus a free retest.

Frequently asked questions

Do I need AWS's permission to run a penetration test? Not for the services on the permitted list, tested against your own resources. Red team exercises, phishing simulations, stress testing and anything involving C2 infrastructure need a Simulated Events request at least two weeks ahead.

Can the test include S3? Yes, testing the security of your buckets and their policies is normal. S3 bucket takeover and subdomain takeover as techniques are on AWS's prohibited list.

Is a cloud configuration scan a penetration test? No. The scan is half one. Without half two, nobody has shown what an attacker can reach, and SOC 2 and PCI DSS assessors know the difference.

How long does it take? Five to ten testing days for a single organization's accounts, plus the retest. Multi-account, multi-region estates take longer; see how long a penetration test takes.

Will the test affect production? Configuration review is read-only. Exploitation is scoped to agreed accounts and hours, avoids anything on the prohibited list, and leaves nothing persistent behind; every action is logged with timestamps for your team.

The short version

AWS penetration testing is an identity and configuration exercise with, as of 2026, a software-inventory exercise bolted to the front. The findings that matter are IAM escalation chains, exposed workloads running exploitable software, storage exposure, and the bridge between an application flaw and cloud credentials. Tooling gives you breadth; a human proving the path from one developer credential to the data gives you the finding that changes what you fix first.

If you run on AWS and want to know what an attacker could reach, scope a cloud assessment, or read our overview of cloud security best practices first.

Updated September 14, 2026 with AWS's current testing policy and the 2026 threat data. The canonical version of this article lives on invadel.com.