Amazon Web Services hosts a disproportionate share of the internet's regulated data — SaaS control planes, healthcare APIs, fintech ledgers, federal workloads, and the S3 buckets that quietly back every “we use the cloud” architecture diagram. That market share attracts the best cloud attackers, which is exactly why generic web application testing leaves so many AWS-specific findings on the table. An AWS penetration test is a specialized engagement that targets IAM, resources, and network boundaries the way a real adversary would, while staying inside Amazon's acceptable use rules and the customer's operational guardrails.
This guide walks through what AWS penetration testing looks like in 2026: Amazon's current rules of engagement, the attack paths we see most often, the tooling experienced testers actually use, and how to scope an engagement that produces findings your engineers can remediate. If you're still shortlisting vendors, our guide on how to choose a penetration testing vendor covers the certifications and methodology questions worth asking.
What Is AWS Penetration Testing?
AWS penetration testing is an authorized, goal-oriented security assessment of an AWS account or Organization. The scope typically spans IAM (users, roles, policies, identity providers, SSO), resources (EC2, Lambda, S3, RDS, DynamoDB, EKS, ECS, API Gateway), and network boundaries (VPCs, security groups, NACLs, Transit Gateways, PrivateLink, CloudFront, Route 53). The goal isn't to produce a vulnerability list — it's to prove which misconfigurations chain together into attack paths that meaningfully impact confidentiality, integrity, or availability.
A well-run AWS pentest treats the cloud environment as a single interconnected system. An externally exposed application may be low risk on its own, but becomes catastrophic when combined with an over-permissioned execution role that can read from a customer data bucket. This is the kind of finding that shows up in an AWS engagement and rarely shows up in a traditional web app test.
AWS's Rules of Engagement for Pentesting
Amazon publishes a Customer Support Policy for Penetration Testing that spells out what you can and cannot do against your own AWS resources. Since 2019, customers have not needed prior approval for most common testing activities — you can run vulnerability scans, port scans, authenticated application testing, and cloud-service abuse chains against your own resources without filing a request. Amazon only requires pre-authorization for specific high-risk activities.
Activities that are allowed without prior notice include port scanning and vulnerability testing of EC2, NAT gateways, ELB, and CloudFront resources you own; authenticated application testing of your deployed apps and APIs; fuzzing of your own API Gateway endpoints; exploit testing against your own resources; and red-team or social engineering exercises targeting your own employees and infrastructure. Activities that are prohibited without explicit approval include DNS zone walking through Route 53 hosted zones; denial-of-service (DoS) or distributed DoS (DDoS) testing, including simulated DoS; protocol flooding and resource-request flooding; and any testing that impacts other AWS customers or Amazon's underlying infrastructure.
There is a separate pre-authorization process for simulated DDoS testing, which requires an approved partner and a submitted test plan. For a standard penetration test staying within the allowed scope, there is no Amazon approval step — the engagement is a matter between the customer and the pentest vendor.
IAM: Where Most AWS Compromises Start and End
IAM is the beating heart of an AWS account, and it is almost always where real incidents either start or end. A good portion of a pentester's time goes into enumerating the IAM graph, mapping trust relationships, and walking the edges looking for escalation paths. The classic Rhino Security Labs research on AWS privilege escalation still describes the underlying primitives, but modern tenants produce far richer attack graphs than those canonical examples.
IAM user credentials in code and CI. Long-lived access keys still end up committed to repositories, baked into container images, and stored in unencrypted CI variables. A pentest that includes any code review or CI inspection routinely finds credentials with direct access to production.
Over-broad AssumeRole trust policies. Roles with a principal of * (even gated by an external ID) or a trust relationship to an entire AWS account instead of a specific role are common. Testers check every role's trust document, not just its permissions, because a misconfigured trust is often the foothold that gets them in.
iam:PassRole abuse. A user with iam:PassRole plus lambda:CreateFunction can spin up a Lambda that assumes a high-privilege role and exfiltrate credentials. The same pattern works with EC2 instance profiles, Glue jobs, Step Functions, and SageMaker notebooks. Testers systematically search for these combinations using tools like PMapper and CloudSpec.
Resource-based policy drift. S3 bucket policies, KMS key policies, SQS queue policies, and Lambda resource policies drift independently of IAM. A bucket policy granting read access to AROA... account principals can give an attacker data access that no IAM policy would allow.
SSO and IdP weaknesses. Organizations using IAM Identity Center (formerly AWS SSO) with SAML or OIDC federation are only as strong as their IdP. Pentesters look at how permission sets are assigned, how session durations are configured, and whether break-glass root credentials are stored safely.
Tooling that shows up in almost every AWS engagement: aws-cli with scoped test credentials, Pacu, PMapper, ScoutSuite, Prowler, CloudGoat for training benchmarks, and Cartography or CloudSpec for graph analysis. Experienced testers use these to enumerate, then confirm exploitability manually rather than stopping at tool output.
S3, RDS, and the Data Layer
Amazon's data services are where most breaches end. Even when an attacker breaks in through a web app or a leaked access key, the payoff is almost always an S3 bucket or a database. A credible AWS pentest spends significant effort here.
S3 misconfigurations. Public ACLs, overly broad bucket policies, and unintentionally disabled Block Public Access settings still show up in real engagements, especially on legacy buckets. Testers also look at server-side encryption modes, object-ownership configuration, and whether sensitive buckets have S3 Access Logging and server-access events flowing into a SIEM.
RDS and Aurora exposure. Databases in publicly accessible subnets with permissive security groups, missing IAM database authentication, and unused but credentialed master passwords are common. Testers check whether RDS snapshots are being exported to S3 or copied cross-account, because snapshot sharing is a high-impact data-exfiltration primitive if it isn't audited.
DynamoDB and Kinesis. NoSQL and streaming services tend to get less scrutiny than S3 but often contain equally sensitive data. Pentesters enumerate table and stream access via IAM and look for tables accessible from every Lambda in the account via a broad managed policy.
KMS key policies. A permissive KMS key policy can undo strict IAM policy restrictions entirely. Testers review key policies alongside IAM to find encrypted data that, in practice, any principal can decrypt.
EC2, Lambda, and Compute
The compute layer is where testers translate footholds into privileged access. EC2, Lambda, ECS, EKS, and Batch all present their own instance metadata or credential exposure surfaces.
Typical compute-layer findings include EC2 instances with IMDSv1 still enabled and SSRF-vulnerable applications on them (a combination that reliably yields IAM role credentials); Lambda functions with environment variables containing secrets in plaintext; ECS task definitions that mount the host filesystem or grant privileged mode to containers; and EKS clusters where pods run with the node's IAM role instead of using IRSA or Pod Identity. Our container and Kubernetes penetration testing guide walks through the EKS-specific testing in more depth.
A subtle but impactful finding is CloudFormation or CDK drift — where the deployed resource has additional permissions that the code doesn't show, because someone patched it in the console during an incident. Testers cross-reference deployed state with the source code repository and flag drift where it matters.
AWS Network Attack Surface
AWS networking is a fully virtualized L2/L3 stack with its own footguns. Pentesters evaluate public and private topology together because attackers don't respect the boundary that architecture diagrams imply.
Common network-layer findings include EC2 security groups with 0.0.0.0/0 allowed on management ports (SSH, RDP, WinRM) for instances that should sit behind Session Manager or a bastion; security-group references that inadvertently bridge dev and prod VPCs through peered connections; NACLs that allow ephemeral port ranges to bypass subnet-level intent; CloudFront distributions with Origin Access controls that still allow direct S3 access, letting an attacker bypass the WAF by hitting the origin URL; and API Gateway endpoints with custom domain names but no resource policy limiting source IPs or VPC endpoints.
Amazon's own management plane runs over a small set of public endpoints that cannot be blocked (*.amazonaws.com), so defense here is IAM policy and credential hygiene rather than network controls — reinforcing the point that the IAM phase of an AWS pentest is not optional.
Methodology: How an AWS Pentest Typically Runs
An AWS penetration test usually takes two to five weeks depending on account count, Organization complexity, and whether identity federation is in scope. The phases follow a familiar pattern with cloud-specific tools at each step.
Scoping and planning. The engagement starts with a review of accounts, Organizations structure, SSO configuration, and the applications hosted in scope. The customer provides a scoped IAM principal — typically a low-privilege user or federated identity — or the tester operates black-box using open-source reconnaissance.
Reconnaissance and enumeration. Testers enumerate the account via the AWS API using tools like Pacu and Prowler, build a permissions graph with PMapper, and identify attack candidates. This is where most initial attack hypotheses form.
Initial access simulation. Depending on scope, testers may simulate phishing against developers with AWS access, exploit externally exposed applications, or start from a leaked credential scenario. Our guide to social engineering penetration testing explains how this phase is typically scoped and authorized.
Privilege escalation. Starting from the initial foothold, testers chain IAM misconfigurations, resource policies, and compute access to reach privileged positions. AWS privilege escalation almost always looks like a graph traversal rather than a single exploit.
Lateral movement. Testers pivot between accounts in the Organization, between VPCs, and between services, often using AWS's own services (Lambda, EventBridge, SSM) as attack infrastructure that blends with normal activity.
Impact demonstration. Rather than exfiltrating real data, testers demonstrate impact with placeholder files, read-only proofs, or annotated API calls. The goal is to prove the path without creating risk.
Reporting and remediation. The deliverable ties each finding to remediation steps, maps findings to frameworks like CIS AWS Benchmark, AWS Foundational Security Best Practices, and MITRE ATT&CK for Cloud, and provides a prioritized action list.
Logging, Detection, and Purple Teaming
A good AWS pentest tells you what your detection stack saw and what it missed. Testers run noisy and stealthy variants of each attack and record which actions generated alerts in CloudTrail, GuardDuty, Security Hub, Detective, and the customer's SIEM.
Common detection gaps in AWS environments include no alerting on iam:CreateAccessKey for IAM users (a classic persistence technique); no alerting on sts:GetFederationToken or long sts:AssumeRole sessions; CloudTrail not delivered to a separate security account, so an attacker with account-level privileges can disable logging; and no GuardDuty coverage in regions the organization “doesn't use” — which is exactly where attackers spin up resources to hide.
Scoping: What to Include and Exclude
A few scoping decisions make a disproportionate difference. We recommend scoping by trust boundary rather than by specific resource lists, because resource inventories go stale between scope signing and test kickoff.
Questions worth answering before the engagement: Which accounts and Organization OUs are in scope? Is IAM Identity Center and the federating IdP in scope or out? Is the tester allowed to use destructive primitives like iam:PutUserPolicy to simulate an attacker's persistence technique, or are changes read-only? Are production workloads fair game, or restricted to non-production accounts? What is the on-call path if testing inadvertently triggers GuardDuty or an on-call page?
If you're working toward a compliance framework — SOC 2, ISO 27001, HIPAA, FedRAMP — make sure the AWS pentest is scoped to produce the evidence the auditor actually needs. Our overview of penetration testing for compliance walks through how to align scope with each major framework.
What an AWS Pentest Report Should Contain
An AWS pentest report should be usable by both engineers and auditors. At a minimum it should include an executive summary with overall risk rating and themes, a narrative attack-path section that walks through the kill chain, individual findings with tenant-weighted severity and CVSS where applicable, reproduction steps, evidence (API call examples, screenshots, log excerpts), affected resources listed by ARN so engineers can locate them, and remediation guidance specific enough that the team doesn't need to research the fix.
The best AWS pentest reports include IaC snippets — Terraform or CloudFormation — where remediation involves code changes, and map findings back to SOC 2 CC7.1/CC6.6, ISO 27001 Annex A.8, or HIPAA §164.312 controls so that auditors can take the report as evidence without additional translation work.
Cost and Timeline
A focused AWS penetration test for a single-account, small-to-mid-size environment (one account, a handful of services, no heavy Organization structure) typically runs $15,000–$35,000 and takes two to three weeks end-to-end including reporting. Larger multi-account Organizations with federated identity, dozens of services, and multiple regions in scope can run $40,000–$100,000+ over four to eight weeks. Retesting after remediation is usually included or offered as a fixed-fee add-on.
Our full breakdown of penetration testing cost covers the variables that drive pricing across engagement types.
Getting Started
If your organization runs regulated workloads on AWS, a dedicated AWS pentest isn't a nice-to-have — it's the minimum bar for demonstrating that the account you've built matches the account you think you've built. Start with a scoped engagement covering IAM, the accounts with your most sensitive data, and the network edges where those accounts talk to the internet. Fix what you find, then expand scope on the next engagement.
Penetration Testing Vendor runs AWS-specialized engagements with testers holding OSCP, AWS Security Specialty, and GCSA certifications who do this work every day. If you're ready to scope an AWS pentest, request a quote and we'll come back with a scoped proposal within one business day.