AWS lets customers run security assessments and penetration tests against their own AWS infrastructure without prior approval for 16 named services, under its Customer Support Policy for Penetration Testing. The same policy prohibits denial of service and DNS abuse outright, and it requires a Simulated Events request at least two weeks ahead for anything that looks like a live adversary: covert red teaming, command and control, phishing and malware.
That policy is the starting line, not the scope. An AWS penetration test is worth paying for when it answers a question your scanners cannot: if an attacker gets one foothold in your AWS estate, how far can they go, and would anyone notice? This guide covers what an AWS penetration test is, exactly what AWS's policy allows in 2026, what a good test checks from IAM to EKS, how it differs from Security Hub CSPM, Amazon Inspector and AWS Security Agent, which compliance frameworks drive it, and how to scope and buy one.
What is an AWS penetration test?
An AWS penetration test is an authorized, time-boxed engagement in which penetration testers try to turn weaknesses in your AWS accounts into proven impact: reading data they should not reach, escalating from a low-privilege identity to administrator, moving from one account into another, or switching off the logging that would reveal them. The output is a set of validated attack paths with evidence, not a list of configuration warnings.
It differs from a web application test in where it starts. A web application test starts at the login page and works through the application's own logic. An AWS penetration test also starts at the control plane: the IAM policies, role trust relationships, resource policies, network rules and logging configuration that decide what every identity in the account can do. Most AWS engagements combine three vantage points:
External exposure: what an unauthenticated attacker on the internet can find and reach, such as public endpoints, open security groups, exposed storage and leaked keys.
Assumed breach: what an attacker can do with a realistic foothold, such as a developer's credentials, a compromised container or a server-side request forgery (SSRF) flaw in an application.
Configuration review with intent: read-only access to IAM, resource policies and network configuration, used to find the paths an attacker would chain rather than to tick a benchmark.
For the broader picture across Azure and Google Cloud, see our cloud penetration testing buyer's guide.
The AWS penetration testing policy in 2026
AWS's policy page is short, and the details matter for scope. The figure and the summary below reflect the page as checked on 25 October 2026. AWS updates it, so read the live page before you sign a statement of work.
What you can test without prior approval
AWS says customers "are welcome to carry out security assessments or penetration tests of their AWS infrastructure without prior approval for the services listed" under Permitted Services. The list currently has 16 entries:
Amazon EC2 instances, WAF, NAT Gateways and Elastic Load Balancers
Amazon RDS and Amazon Aurora
Amazon CloudFront
Amazon API Gateway and AWS AppSync
AWS Lambda and Lambda Edge functions
Amazon Lightsail resources and Elastic Beanstalk environments
Amazon Elastic Container Service and AWS Fargate
Amazon OpenSearch Service and Amazon FSx
Amazon Transit Gateway and AWS Global Accelerator
Amazon Bedrock AgentCore
Two newer entries stand out for 2026 scoping: Amazon Bedrock AgentCore and AWS Global Accelerator. If your product runs AI agents on AgentCore, that surface is now explicitly testable. AWS also lets you host security assessment tooling inside AWS or another cloud for on-premises, in-AWS or third-party contracted testing.
Services that are not on the list, such as IAM and S3, are a frequent source of confusion. A configuration review of your own IAM policies, bucket policies and key policies, done through the AWS APIs with credentials you issue, uses those services as designed rather than attacking them. AWS's policy is explicit that customers "are not permitted to conduct any security assessments of AWS infrastructure or the AWS services themselves," and that customers who want to test non-approved services "will need to work directly with AWS Support or your account representative." If a planned activity targets the service rather than your configuration, ask AWS first.
What needs a Simulated Events request
AWS states that "all security testing that includes Command and Control (C2) requires prior approval." The policy routes these activities through its Simulated Events form:
Covert adversarial simulations (red, blue or purple team) and any test that hosts command and control.
Simulated phishing campaigns.
Malware testing.
iPerf network testing.
DDoS simulation and network stress tests fall under AWS's separate DDoS Simulation Testing and Stress Test policies. Requests must reach AWS "at least two (2) weeks in advance of the start date," with dates, account IDs, assets and contacts, and AWS says to expect a non-automated response within 2 business days. Build that lead time into the engagement plan, because a red team scenario cannot start on the day the contract is signed. Customers in the AWS China (Ningxia and Beijing) Regions use a separate form.
What is prohibited
The policy lists these as prohibited activities:
DNS zone walking via Amazon Route 53 hosted zones, DNS hijacking via Route 53 and DNS pharming via Route 53.
Denial of service and distributed denial of service, plus simulated DoS and DDoS, which are subject to the DDoS Simulation Testing policy.
Port flooding, protocol flooding and request flooding (login request flooding and API request flooding).
S3 bucket takeover and subdomain takeover.
AWS also lists Amazon API Gateway and Amazon Bedrock AgentCore under "Prohibited Services for Outbound Penetration Testing." The page does not elaborate, but the plain reading is that neither service may be used as the launch point for tests against other targets.
The tool rules are strict about availability. Any tool with a DoS capability "must have the explicit ability to DISABLE, DISARM, or otherwise render HARMLESS, that DoS capability," and the customer is responsible for making sure contracted third parties follow the policy. Finally, any vulnerability that is "the direct result of AWS's tools or services" must be reported to AWS Security within 24 hours of completion of testing.
AWS's policy is the outer boundary. Your own written authorization to the tester, naming accounts, Regions, assets, time windows and contacts, defines the test inside it. Our cloud penetration testing rules of engagement guide compares AWS's rules with Azure's and Google Cloud's.
Shared responsibility: what you are actually testing
AWS's shared responsibility model splits security into two halves. AWS is "responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud." The customer's half "will be determined by the AWS Cloud services that a customer selects." For an infrastructure service such as EC2, that means the guest operating system and its patches, application software installed on instances and the configuration of security groups. For abstracted services such as S3, it means managing data, including encryption options, and "using IAM tools to apply the appropriate permissions."
That split defines an AWS penetration test. The test never targets AWS's half, which the policy forbids anyway. It targets yours: every permission you granted, every trust you configured, every port you opened and every log you did or did not turn on. That is also why AWS's own compliance reports do not cover it. A provider attestation describes AWS's controls, not the way your account is put together, a gap we cover in CSP compliance reports vs cloud pentest evidence.
What gets tested in an AWS penetration test
The areas below are where real AWS compromises tend to start and spread. For each one, the useful question for a defender is not "is there a finding?" but "does this weakness connect to anything that matters?"
IAM privilege escalation paths
IAM is the core of most AWS attack paths. A tester maps which identities can modify policies, attach roles, pass roles to compute services, or create new credentials, and then checks whether any of those permissions let a low-privilege identity climb to administrator. MITRE ATT&CK tracks the end state as Additional Cloud Roles (T1098.003). Defenders should confirm least-privilege policies, permission boundaries on identities that create other identities, and service control policies that cap what any account can do. Our cloud IAM penetration testing guide goes deeper, and the IAM Identity Center permission set assessment covers the workforce access layer.
Cross-account trust and the confused deputy
Most organizations run many AWS accounts, and roles that trust other accounts, vendors and CI/CD systems are where one compromise becomes several. AWS's own confused deputy guidance describes the risk: "an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action." The test checks every role trust policy for who can assume it, whether third-party roles require an external ID, and whether resource policies that trust AWS service principals use the aws:SourceArn or aws:SourceAccount condition keys. Federated trust from CI systems deserves its own pass; our GitHub Actions OIDC cloud trust test matrix covers that pattern. IAM Access Analyzer flags resources shared outside your zone of trust; the test shows which of those shares an attacker could actually use.
S3 and KMS exposure
AWS's S3 documentation says that "by default, new buckets, access points, and objects don't allow public access," and that S3 Block Public Access settings override policies that would grant it. Exposure still happens through account-level settings that were never turned on, bucket policies that grant access to other accounts, and KMS key policies broad enough that whoever can read the ciphertext can also decrypt it. The test checks what data is reachable from the outside and from each foothold, which ATT&CK records as Data from Cloud Storage (T1530).
EC2 and the instance metadata service
The instance metadata service hands temporary credentials for the instance's IAM role to software running on that instance. AWS's IMDS documentation explains that IMDSv2 uses session-oriented requests with a token, that "by default, you can use either IMDSv1 or IMDSv2, or both," and that you can configure instances to accept IMDSv2 only. The test checks whether an application flaw such as SSRF can reach those credentials (T1552.005) and what the instance role can do once reached. The defensive answer is to require IMDSv2 and keep instance roles minimal, because a role with broad permissions turns a single web bug into an account compromise.
Lambda and serverless
Serverless removes the operating system from scope but not the identity. The test reviews each function's execution role, secrets stored in environment variables, resource-based policies that decide who can invoke the function, and event sources that accept untrusted input. Shared, over-permissioned execution roles are the common finding: one vulnerable function inherits access meant for many. ATT&CK tracks abuse of these services as Serverless Execution (T1648).
EKS and containers
Kubernetes on AWS adds a second identity system on top of IAM. AWS's EKS Pod Identity documentation warns that if access to the instance metadata service is not restricted, a pod's containers "also have access to the Amazon EKS node IAM role and the containers may be able to gain access to credentials of IAM roles of other Pods on the same node." The test checks how pods get AWS credentials (EKS Pod Identity or IAM roles for service accounts), whether pods can reach node credentials, how Kubernetes RBAC maps to IAM, and what a compromised workload can discover (T1613). Our cloud and Kubernetes penetration testing scoping guide covers how cluster count changes scope.
API Gateway and the application edge
API Gateway sits between the internet and your backends, so it is where cloud and application testing meet. The test checks for routes without an authorizer, resource policies that are broader than intended, backend integrations that trust any request the gateway forwards, and stage or route settings that expose internal endpoints. ATT&CK's Exploit Public-Facing Application (T1190) is the entry technique. The business logic of the APIs themselves is usually scoped as a web application and API penetration test alongside the cloud work.
Network exposure
Security groups, network ACLs, VPC peering, Transit Gateway attachments and VPC endpoints decide which services are reachable from where. The test maps internet-facing management ports, databases reachable from the wrong subnets, and peering that flattens environments that should be separate. ATT&CK's Cloud Infrastructure Discovery (T1580) describes how an attacker builds the same map.
Logging and detection
A test that nobody detects is a finding in itself. AWS CloudTrail records actions taken by users, roles and AWS services, but AWS notes that "by default, trails and event data stores do not log data events," so object-level reads in S3 may go unrecorded unless you enable them. Amazon GuardDuty analyzes CloudTrail management events, VPC flow logs and DNS logs, with optional protection plans for S3, EKS, runtime, RDS, Lambda and AI workloads. The test records what each step of the attack path generated, whether an alert reached a human, and whether a compromised identity could disable or redirect logging (T1685.002). Teams that want to exercise their response live can extend this into purple teaming.
AWS penetration testing vs Security Hub CSPM, Inspector and AWS Security Agent
AWS ships strong native security services, and a mature AWS estate should run them. They answer a different question from a penetration test.
AWS Security Hub CSPM runs continuous configuration checks against standards including AWS Foundational Security Best Practices, CIS, PCI DSS and NIST, and aggregates findings from GuardDuty, Inspector, Macie and partner products, per its user guide. It tells you that a control failed; it does not tell you whether three passing-looking controls combine into a path to your customer data.
Amazon Inspector, in AWS's own words, "automatically discovers workloads and continually scans them for software vulnerabilities and unintended network exposure" across EC2 instances, ECR container images and Lambda functions. It finds the vulnerable package; a test shows whether that package is reachable and what the attacker gets.
Amazon GuardDuty and IAM Access Analyzer detect suspicious activity and external or unused access. A test is the controlled way to check whether that detection fires on a realistic path.
AWS Security Agent became generally available on 31 March 2026 as on-demand autonomous testing that combines SAST, DAST and penetration testing of your applications, per the AWS Security Blog. It is a real step forward for release-by-release application coverage. AWS positions it as application security testing; its reports can be exported for compliance documentation, but AWS does not say they replace an independent test, so control-plane and cross-account depth, and the independence that customers and auditors look for, still come from a scoped test. Our analysis of whether AWS Security Agent replaces a cloud penetration test walks through each gap.
The practical model is to run the native services continuously, fix what they flag, and use a periodic AWS penetration test to prove which remaining weaknesses chain together. We cover the same pattern for third-party posture tools in CNAPP blind spots in cloud penetration testing.
Methodology and standards
A credible AWS penetration test names its methodology up front, so the report can be traced back to a recognized framework. The references most AWS engagements draw on are:
CIS Amazon Web Services Foundations Benchmark: CIS lists version 7.1.0 as the current release. It is a configuration baseline for identity, logging, monitoring, storage and networking. A test uses it as a checklist of controls to verify, not as the test itself.
MITRE ATT&CK Cloud matrix: the Enterprise Cloud matrix (content v20) covers IaaS, SaaS, Office Suite and Identity Provider platforms. Mapping each finding to an ATT&CK technique lets your detection team turn results into detection rules.
NIST SP 800-115: the NIST technical guide to information security testing, which the FedRAMP penetration test guidance cites for rules of engagement and test plans. PCI DSS v4.0.1 asks for "industry-accepted penetration testing approaches" and names OSSTMM and OWASP as examples.
OWASP guidance for the application and API layer that sits in front of AWS.
A typical engagement runs in six phases:
Scoping and rules of engagement: accounts, Regions, services, starting positions, testing windows, emergency contacts, and any Simulated Events request that needs its two weeks.
Reconnaissance and exposure mapping: public endpoints, DNS, storage, published keys and internet-reachable services.
Identity and configuration analysis: IAM, trust relationships, resource policies, network rules and logging, read with an attacker's goals in mind.
Attack path validation: carefully controlled, non-destructive proof that a path works, stopping at agreed evidence points rather than touching production data.
Detection review: what CloudTrail, GuardDuty and your alerting saw at each step.
Reporting and retest: each path documented with evidence, impact and remediation, followed by a retest of the fixes.
Compliance drivers for AWS penetration testing
Most AWS penetration tests are bought because a framework, an auditor or an enterprise customer asks for one. What each framework actually says differs more than buyers expect.
SOC 2: the AICPA Trust Services Criteria list penetration testing among the types of ongoing and separate evaluations in the points of focus for CC4.1. The criteria do not set a cadence, so your risk assessment and your auditor decide. For an AWS-hosted SaaS product, the test usually needs to cover the production accounts in the audit scope; our guide to cloud pentest scope for SOC 2 Type II on AWS covers what auditors look for.
PCI DSS v4.0.1: Requirement 11.4 calls for a documented methodology, internal and external penetration testing at least once every 12 months and after significant change, and testing of any segmentation controls used to reduce scope. Service providers must test segmentation at least every six months. The tester must be qualified and organizationally independent, though not necessarily a QSA. The standard is available from the PCI SSC document library.
HIPAA: the Security Rule in force today requires periodic technical and nontechnical evaluation under 45 CFR 164.308(a)(8) but does not name penetration testing. The proposed rule published on 6 January 2025 would require penetration testing by a qualified person "at least once every 12 months" or more often if the risk analysis calls for it. As of October 2026 no final rule has been published, so treat annual testing as good practice rather than a current legal requirement.
FedRAMP: the FedRAMP Penetration Test Guidance (version 3, June 2022) requires the authorization test to be completed by a 3PAO no more than six months before the Security Assessment Report, then at least every 12 months during continuous monitoring, across six mandatory attack vectors that include tenant to tenant and tenant to CSP management system. Independent testing before the 3PAO assessment is readiness work that finds problems early.
Stingrai's penetration testing supports your SOC 2, ISO 27001, PCI DSS, HIPAA and FedRAMP readiness programs with reports written for auditors and customers.
Scoping an AWS penetration test and what drives the cost
AWS penetration testing has no standard price because the scope varies so much between estates. These are the factors that move the effort:
Accounts and organization structure: a single production account is a different job from an AWS Organization with dozens of accounts, delegated administrators and cross-account roles.
Regions and services in use: each additional Region and service family (containers, serverless, managed databases, AI services) adds configuration to review and paths to validate.
Starting positions: external only, assumed breach from one or more footholds, or both. Assumed breach usually finds more because it reflects how real AWS incidents progress.
EKS clusters and serverless footprint: cluster count, node groups and the number of functions with distinct roles.
The application layer: whether the web applications and APIs running on AWS are in the same engagement.
Detection validation: a test that also measures what your monitoring saw takes more coordination than one that only proves exploitability.
Simulated Events: red team, C2 or phishing scenarios add AWS's two-week lead time and more planning.
Retesting and reporting: retests of fixed findings, and report formats mapped to a specific framework.
Stingrai quotes AWS infrastructure engagements after a scoping call; see the cloud penetration testing service for what is covered and the pricing page for the published packages. Where the scope is the application running on AWS, the published prices are US$3,000 (Autonomous) / US$6,800 (Hybrid) per assessment for one web application and associated APIs.
How to choose an AWS penetration testing provider
The questions below separate an AWS-specific engagement from a network scan run against cloud IP addresses:
Is the firm accredited? CREST accreditation at company level shows audited methodology, data handling and tester competence.
Who exactly will test? Ask for named penetration testers and their certifications, and confirm the same people do the work.
Do they work from the control plane? The proposal should mention IAM, trust policies, resource policies and assumed-breach starting points, not only external scanning.
Do they know AWS's policy? They should explain which activities need a Simulated Events request and how they keep tooling clear of DoS behaviour.
Will they prove impact safely? Ask how they validate a path without touching production data or availability.
Do they report detection? A report that says what CloudTrail and GuardDuty saw is worth more to your security team than one that only lists findings.
Is retesting included? Fixes need confirming before the report goes to an auditor or customer.
Does the report fit your framework? For PCI DSS, confirm independence and a documented methodology; for FedRAMP authorization, remember the test itself must come from a 3PAO.
For a shortlist of firms, see our guide to cloud penetration testing companies for AWS and SOC 2.
How Stingrai approaches AWS penetration testing
Stingrai is a global CREST-accredited penetration testing services company founded in Toronto, Canada in 2021, trusted by companies from startups to enterprises to meet audit requirements for SOC 2, ISO 27001, CMMC, PCI DSS and HIPAA. OSCE³, OSWE, OSEP, CREST CRT certified penetration testers, who are also world-class security researchers and bug bounty hunters. Choose from fully human-led or hybrid (AI agents plus human penetration testers) engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements.
For AWS, that means:
Human-led cloud testing: every AWS engagement is run by two named penetration testers from a team holding OSCE³, OSWE, OSEP, CREST CRT and CISSP certifications, with the report reviewed by the team lead and an engagement partner. The team has published 18 CVEs.
Control plane to workload: cross-account role assumption, resource and bucket policies, instance metadata abuse, and Lambda, API Gateway and EKS paths, tested within AWS's policy and your written rules of engagement.
The application layer: web applications and associated APIs running on AWS can be tested by Snipe, Stingrai's autonomous AI penetration testing agent, alone or with penetration testers working alongside it throughout a Hybrid engagement. Snipe's specialist sub-agent covers AI and LLM applications, such as products built on Amazon Bedrock. AWS infrastructure itself is tested by the penetration testers, not by Snipe; for Bedrock IAM and infrastructure, see AWS Bedrock penetration testing and the AI and LLM penetration testing service.
Delivery through the PTaaS portal: findings are posted to the Stingrai PTaaS portal as they are confirmed, each with proof of concept and remediation guidance, alongside live chat with the testers, Jira and Slack integration, retesting of fixed findings, and an attestation letter with human-led and hybrid reports.
One-time or continuous: an annual AWS penetration test for an audit cycle, or a continuous program that retests as the estate changes.
Frequently asked questions
Do you need AWS permission to run a penetration test?
No, not for the 16 services AWS lists as permitted, provided you test only resources you own. AWS's Customer Support Policy for Penetration Testing says customers may test their AWS infrastructure without prior approval for those services. Any testing that includes command and control, covert red teaming, simulated phishing, malware testing or iPerf testing needs a Simulated Events request submitted at least two weeks before the start date.
What is AWS penetration testing?
AWS penetration testing is an authorized engagement in which penetration testers try to turn weaknesses in your AWS accounts into proven impact, such as escalating IAM privileges, assuming roles across accounts, reaching data in S3 or switching off logging. It covers the parts of AWS that the shared responsibility model assigns to you: identities, permissions, network rules, workloads and data.
Which AWS services can you penetration test without approval?
As of October 2026, AWS lists 16 permitted services: EC2 instances, WAF, NAT Gateways and Elastic Load Balancers; RDS; CloudFront; Aurora; API Gateway; AppSync; Lambda and Lambda Edge functions; Lightsail; Elastic Beanstalk; Elastic Container Service; Fargate; OpenSearch Service; FSx; Transit Gateway; Bedrock AgentCore; and Global Accelerator. Testing other services requires working with AWS Support or your account representative.
What does AWS prohibit during a penetration test?
AWS prohibits DNS zone walking, DNS hijacking and DNS pharming via Route 53; DoS and DDoS, including simulated DoS and DDoS outside its DDoS Simulation Testing policy; port, protocol and request flooding; and S3 bucket takeover and subdomain takeover. It also prohibits using API Gateway or Bedrock AgentCore for outbound penetration testing.
How often should you run an AWS penetration test?
At least once a year and after significant changes is the common baseline. PCI DSS v4.0.1 requires internal and external penetration testing at least once every 12 months and after significant change, and FedRAMP requires testing at least every 12 months during continuous monitoring. SOC 2 does not set a cadence, so your risk assessment and auditor decide.
Does Security Hub, Inspector or AWS Security Agent replace an AWS penetration test?
No. Security Hub CSPM checks configuration against standards, Inspector scans for software vulnerabilities and network exposure, and AWS Security Agent tests applications on demand. They flag issues continuously, while a penetration test proves which issues chain into a real attack path across IAM, accounts and workloads, and gives auditors and customers independent evidence. Run both.
How much does an AWS penetration test cost?
The cost depends on the number of accounts, Regions and services, the starting positions, EKS and serverless footprint, whether the application layer is included, and whether detection is validated. Stingrai quotes AWS infrastructure engagements after scoping. For the application running on AWS, Stingrai's published prices are US$3,000 (Autonomous) / US$6,800 (Hybrid) per assessment for one web application and associated APIs.
Does Snipe test AWS infrastructure?
No. Snipe, Stingrai's autonomous AI penetration testing agent, covers web applications and associated APIs, with a specialist sub-agent for AI and LLM applications such as Bedrock-backed products. AWS infrastructure testing, including IAM, cross-account trust, networking and EKS, is human-led by two named Stingrai penetration testers.
Related reading
Sources
AWS, Customer Support Policy for Penetration Testing, checked 25 October 2026.
AWS documentation: Logging data events with CloudTrail, IAM Access Analyzer, The confused deputy problem, S3 Block Public Access, Instance Metadata Service, EKS Pod Identity, AWS CloudTrail, Amazon GuardDuty, AWS Security Hub CSPM, Amazon Inspector.
AWS Security Blog, AWS Security Agent on-demand penetration testing now generally available, 31 March 2026.
Center for Internet Security, CIS Amazon Web Services Benchmarks.
MITRE, ATT&CK Enterprise Cloud matrix.
NIST, SP 800-115, Technical Guide to Information Security Testing and Assessment.
AICPA, 2017 Trust Services Criteria (with revised points of focus, 2022).
PCI Security Standards Council, PCI DSS v4.0.1, document library.
US Code of Federal Regulations, 45 CFR 164.308; Federal Register, HIPAA Security Rule proposed rule, 6 January 2025.
FedRAMP, Penetration Test Guidance, version 3, 30 June 2022.
