AWS lets you penetration test your own resources across eight service categories with no advance notice to AWS, a policy in place since 2019. That changed cloud pentesting from a paperwork exercise into something you can start the same day, as long as you stay inside the shared-responsibility line and avoid the still-restricted tests like DDoS and stress simulations.
This guide covers what AWS permits and prohibits, the metadata and IAM attack paths that produce the most findings, and the toolchain (Prowler, ScoutSuite, Pacu, pmapper) that experienced testers actually use. It assumes you have written authorization from the account owner.
AWS permits customer-initiated penetration testing of eight service categories without requesting approval: EC2 instances, NAT gateways, and Elastic Load Balancers; RDS; CloudFront; Aurora; API Gateway; Lambda and Lambda Edge functions; Lightsail resources; and Elastic Beanstalk environments. You test the resources you own and the configurations you control, not the underlying AWS infrastructure.
The line follows the shared responsibility model. You own security in the cloud (your IAM policies, security groups, S3 ACLs, application code); AWS owns security of the cloud (hypervisor, physical hosts, the service control plane). Anything that probes AWS's own infrastructure or another tenant is out of bounds. Cloud testing differs from a traditional engagement in important ways, which we cover in what to expect from a cloud penetration test.
Even with the open policy, several activities are flat-out prohibited or require a separate request. DNS zone walking of Route 53 hosted zones, port flooding, protocol flooding, and request flooding (login or API request floods) are prohibited. Any high-volume test that resembles a denial-of-service attack falls here.
Simulated events that mimic real attacks, including DDoS simulations, stress testing, and red team exercises against AWS-managed control planes, require prior authorization through the AWS Simulated Events form. Pinging or scanning AWS-owned IP space outside your assets is also off limits. When in doubt, request approval; the form turnaround is usually a few business days.
Server-side request forgery against the EC2 metadata endpoint at 169.254.169.254 is the single most impactful AWS attack path. If an application on an instance can be coerced into fetching an attacker-controlled URL, you point it at http://169.254.169.254/latest/meta-data/iam/security-credentials/<role> and receive temporary IAM credentials for the instance role. From there you assume that role and pivot into the account.
IMDSv2 mitigates this. It requires a PUT request to /latest/api/token to obtain a session token, which is then sent in the X-aws-ec2-metadata-token header on every metadata call. Most SSRF primitives only issue GET requests, so IMDSv2 enforcement (via HttpTokens: required) breaks the attack. Always check whether the instance enforces v2 or still allows v1. The SSRF mechanics carry over from web testing, covered in our SSRF testing guide.
S3 and IAM are where most AWS findings live. On S3, look for public bucket policies and ACLs, buckets with ListBucket open to AllUsers or AuthenticatedUsers, predictable bucket names you can enumerate, and write access that lets you tamper with hosted assets. Block Public Access settings at the account level override permissive bucket policies, so confirm whether they're on.
IAM privilege escalation is subtler. Permissions like iam:CreatePolicyVersion, iam:PassRole combined with a service that assumes roles, iam:AttachUserPolicy, lambda:CreateFunction plus iam:PassRole, and sts:AssumeRole on over-permissive trust policies each form a known escalation chain. There are roughly two dozen documented paths; map them rather than guessing.
enumerate-iam against found keys.pmapper.Run posture and misconfiguration discovery first, then targeted exploitation. Prowler runs hundreds of checks mapped to CIS, NIST, and PCI and is the fastest way to surface public buckets, disabled logging, and weak IAM. ScoutSuite gives a multi-service HTML report of the same surface. CloudSploit covers similar ground if you want a second opinion.
For active work, Pacu is the AWS exploitation framework: enumeration, persistence, privilege escalation, and data exfiltration modules. Cartography ingests your AWS assets into a Neo4j graph so you can query relationships across accounts. Methodology-wise, follow recon (enumerate keys, regions, services), assess (posture scan), exploit (metadata SSRF, IAM escalation, S3 access), and pivot (cross-account role assumption). Running this on a schedule instead of once a year is the argument for agentic, continuous pentesting. For broader hygiene, pair findings with our cloud security posture checklist.