AWS Penetration Testing: Scope, Rules, and What Gets Tested

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 actually happen.

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, the underlying service infrastructure. You cannot test it, and you have no reason to.
• Your responsibility , IAM policies and roles, security groups and NACLs, S3 bucket policies, Lambda functions and their execution roles, EC2 operating systems and applications, RDS configuration, secrets management, and logging.

Effectively everything worth testing in your AWS account is on your side of the line.

AWS’s testing policy: what’s permitted

AWS permits customers to perform security assessments against their own resources for a defined list of services without prior approval , including EC2, RDS, CloudFront, Aurora, API Gateway, Lambda, Lightsail, and Elastic Beanstalk. That covers the overwhelming majority of real engagements.

Some activities still require explicit authorization from AWS, most notably simulated denial-of-service testing, DNS zone walking of Route 53 hosted zones, and port flooding. Those fall outside a standard penetration test anyway.

Two practical implications: confirm the resources in scope are genuinely yours (a shared or vendor-managed account needs that vendor’s written permission), and always check AWS’s current customer support policy for penetration testing before an engagement, since the permitted-services list is updated over time. A competent testing partner does both during scoping.

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, lambda:UpdateFunctionCode, or ec2:RunInstances can often bootstrap itself to full admin. There are dozens of documented escalation chains, and finding them requires reading policy graphs, not running a scanner.
• Unused and stale credentials , long-lived access keys, users who left, roles created for a migration two years ago.
• Cross-account trust relationships , third-party roles trusted more broadly than intended.
• Missing MFA on privileged principals.

S3 and data storage

Public buckets remain a leading cause of cloud data exposure, but the subtler issues matter more: bucket policies granting access to AllAuthenticatedUsers (every AWS account in the world, not just yours), missing encryption, disabled versioning and logging, and pre-signed URL patterns that expose more than intended.

Network and compute

Security groups exposing management ports (SSH, RDP, database ports) to 0.0.0.0/0, unpatched EC2 instances, exposed container registries and Kubernetes/EKS control planes, and Lambda functions with excessive execution-role permissions or secrets baked into environment variables.

The metadata service (SSRF’s cloud payoff)

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’s role 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 together , the vulnerability is in the app, the impact is in the cloud.

Secrets and CI/CD

Hardcoded keys in code, images, or environment variables; over-privileged CI/CD roles; and the supply-chain path from a compromised pipeline into production infrastructure.

Black box, or credentialed?

Most AWS engagements should be credentialed (grey or white box). A black box test of a cloud environment mostly proves what’s publicly exposed , useful, but a small slice of your real risk. Giving testers read-only access plus a low-privilege role lets them map the IAM graph and answer the question that matters: if an attacker phished one developer, or exploited one app, how far could they get?

A typical setup provides a SecurityAudit or ReadOnlyAccess role for configuration review, plus a standard user role to model realistic escalation.

Automated cloud scanning is necessary but not sufficient

Tools like ScoutSuite, Prowler, and Pacu (and AWS’s own Config, Security Hub, and Access Analyzer) are genuinely useful , they enumerate misconfigurations at a scale no human can match. Every good engagement uses them for coverage.

What they don’t do is chain. 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 escalate an ordinary developer account to administrator, and proves it. That gap is the entire value of manual cloud penetration testing over a configuration scan.

Compliance and AWS

Running in AWS doesn’t remove your testing obligations , it relocates them. PCI DSS requires testing of the cardholder data environment wherever it runs, including cloud-hosted segments and segmentation controls. SOC 2 auditors expect testing that covers your cloud infrastructure, not just the application. HIPAA requires evaluation of safeguards for systems processing ePHI, including S3 buckets and RDS instances holding it. AWS’s own compliance certifications cover their infrastructure, never your configuration of it , a distinction auditors are explicit about.

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/Control Tower in use)?
2. Which regions hold in-scope resources?
3. Rough resource counts , EC2 instances, S3 buckets, Lambda functions, RDS instances, EKS clusters.
4. Which applications are hosted there, and should they be tested too?
5. Access model , what roles can you provide for credentialed testing?
6. Multi-cloud? Azure or GCP alongside AWS changes the scope.
7. Compliance driver, if any , it determines what the report must map to.

The short version

AWS penetration testing is primarily an identity and configuration exercise, not a network one. The findings that matter are IAM escalation chains, storage exposure, and the bridge between an application flaw and cloud credentials. Automated tooling gives you breadth; a human proving an escalation path from developer to admin gives you the finding that changes what you fix first.

If you’re running on AWS and want to know what an attacker could actually reach, scope a cloud assessment and we’ll test your account, your applications, and the paths between them, or read our overview of cloud security best practices first.