Penetration testing on AWS is permitted, and importantly, for most customer-owned services, it does not require prior approval from AWS. But the policy has nuances that matter, the shared responsibility model creates a testing scope that is different from on-premises environments, and the 2024 launch of AWS Security Agent has introduced a new option that changes how organisations think about what "AWS penetration testing" means.
This guide explains the AWS penetration testing policy in plain language, maps what testing is permitted without approval, what requires AWS involvement, and what is prohibited. It also covers the AWS-specific attack surfaces that any credible AWS security assessment must address, and the decision between using AWS's own Security Agent versus engaging independent third-party penetration testers.
AWS publishes a penetration testing policy at aws.amazon.com/security/penetration-testing/. The policy is the authoritative reference; this guide explains it in practical terms.
What you can test without prior AWS approval:
AWS allows customers to conduct security testing of their own AWS resources without requesting prior permission for the following services:
This list covers the core compute, database, and delivery services that most production applications use. For standard penetration testing of applications hosted on EC2, API Gateway, Lambda, and RDS, no AWS approval is required.
What is prohibited under any circumstances:
AWS explicitly prohibits the following activities regardless of whether you own the resources:
These prohibitions cover attacks against AWS's shared infrastructure. Testing your own application's rate limiting and DoS resilience is a different matter and generally falls within permitted testing, but directing traffic floods at AWS infrastructure itself is prohibited.
The grey area: activities requiring prior notification or approval
AWS requests notification for certain activities that may trigger automated security responses or affect shared infrastructure:
For anything that does not clearly fall within the approved service list or that involves techniques likely to affect shared infrastructure, contacting AWS security before testing is the appropriate step. The AWS security contact is security-testing@amazon.com, and response times for notification acknowledgement are typically within a few business days.
The AWS shared responsibility model determines what you own and what AWS owns, and therefore what you can test and what you cannot.
AWS is responsible for: the security of the cloud: the physical data centres, hardware, networking infrastructure, hypervisor layer, and managed service software stacks. You cannot test AWS's own infrastructure security; it is not yours to test.
You are responsible for: security in the cloud: your operating systems, applications, data, network configurations, IAM policies, firewall rules, and security controls you implement in your AWS environment.
This boundary defines the scope of a meaningful AWS penetration test. Testing an EC2 instance tests your operating system configuration, your application, your security group rules, your IAM policies, all of which are your responsibility. It does not test the hypervisor underneath, which is AWS's responsibility and which you cannot test.
The practical implication: an AWS penetration test is not primarily a test of AWS's security. It is a test of your configuration and security controls within AWS. A clean result means your resources are well-configured and your applications are secure. It does not mean AWS infrastructure is secure: that is guaranteed by AWS through their own certifications and compliance programmes.
AWS environments have specific attack surfaces and vulnerability classes that differ from on-premises environments. A credible AWS penetration test must address these specifically.
As covered in the cloud security assessment guide, IAM is the most consistently problematic domain in AWS environments. Every AWS penetration test should explicitly assess:
IAM privilege escalation paths. Specific combinations of IAM permissions allow a lower-privilege identity to grant itself higher privileges. An identity with iam:CreateAccessKey on the root account, iam:AttachRolePolicy on an existing role, or lambda:CreateFunction plus iam:PassRole can escalate to permissions far beyond what the original identity was intended to have. Testing enumerates all IAM identities and their permissions, then maps which identities have escalation paths to administrator-level access.
IAM role trust relationships. Cross-account trust relationships and services configured to assume roles may be broader than intended. External ID requirements on cross-account role assumptions prevent confused deputy attacks; testing confirms they are implemented.
Wildcard resource permissions. Policies granting actions against "Resource": "*" are far more permissive than policies scoped to specific resources. Testing identifies all wildcard resource policies and evaluates whether they create exploitable privilege chains.
IMDSv1, the original EC2 instance metadata service, is accessible to any process running on the instance at http://169.254.169.254/latest/meta-data/. This includes the instance role credentials. Any server-side request forgery (SSRF) vulnerability in an application running on an EC2 instance can be used to retrieve the instance role credentials through the metadata endpoint, giving the attacker the permissions of that role in the AWS account.
IMDSv2 requires session tokens, making the metadata endpoint resistant to simple SSRF attacks. AWS encourages migration to IMDSv2 and provides account-level controls to require it. Testing confirms:
HttpTokens: required setting is enforced to prevent new instances from using IMDSv1S3 misconfiguration is one of the most consistently exploited attack vectors in AWS environments. Testing covers:
AuthenticatedUsers principal grants access to any AWS account holder, not authenticated users of your organisation)Lambda introduces a security model where each function has its own IAM execution role, and misconfigured roles create independent attack paths. Testing covers:
API Gateway endpoints expose application functionality to the internet and are the primary application attack surface in serverless architectures. API vulnerabilities standard penetration tests miss covers the specific API vulnerability classes; for AWS specifically, testing also covers:
AWS network security is software-defined through security groups and NACLs. Testing covers:
0.0.0.0/0 source on ports beyond HTTP/HTTPSOrganisations using AWS Organizations and multi-account architectures have additional attack surfaces in the account relationships. Testing covers:
AWS launched the AWS Security Agent as a generally available service in 2024. It allows customers to run on-demand penetration tests of their AWS environments directly through the AWS console, conducted by AWS's own security assessors.
Understanding what AWS Security Agent is and is not helps buyers decide when to use it versus engaging independent third-party testers.
What AWS Security Agent does:
AWS Security Agent conducts automated and human-assisted penetration testing of customer AWS environments, operating within the permissions of the AWS environment being tested. It can identify IAM misconfigurations, exposed resources, network security gaps, and known vulnerability classes in AWS services.
What AWS Security Agent does not replace:
Third-party independence. AWS Security Agent is conducted by AWS: the same company that provides the platform. For compliance frameworks requiring independent third-party testing, AWS Security Agent may not satisfy the independence requirement. A QSA reviewing PCI DSS compliance, an ISO 27001 auditor, or a SOC 2 examiner may expect testing by a firm independent of the cloud provider.
Application-layer testing. AWS Security Agent focuses on AWS configuration and infrastructure. It does not test your application's business logic, authentication implementation, API authorization gaps, or custom code vulnerabilities. Application-layer penetration testing of the software running in your AWS environment requires separate methodology.
Attacker perspective at the application layer. AWS Security Agent operates from inside the AWS environment. A genuine external attacker begins with nothing: no AWS credentials, no account access. Simulating that threat requires testing that starts from an external position without AWS credentials.
Decision framework:
Use AWS Security Agent for: quick configuration review of your AWS environment, initial baseline assessment, ongoing configuration drift detection.
Use independent third-party testing for: compliance evidence requiring tester independence from the cloud provider, application-layer testing of software running in AWS, external attacker simulation starting from zero credentials, and assessments where attacker independence from the platform provider matters.
Most mature AWS security programmes use both: AWS Security Agent or equivalent CSPM tooling for continuous configuration monitoring, and independent third-party testing for application security, compliance evidence, and external threat simulation.
The compliance implications of AWS penetration testing depend on which framework applies.
PCI DSS: Testing of the cardholder data environment in AWS must cover the AWS configuration layer (security groups, IAM, S3 access controls for any CDE data) as well as the application layer. AWS penetration testing policy permits this for customer-owned resources. QSA requirements for tester independence mean AWS Security Agent alone may not satisfy the Requirement 11.4 obligation.
SOC 2: SOC 2 penetration testing: what auditors actually require covers the evidence standard. For SOC 2 Trust Service Criteria CC6, the system in scope must be tested. If the system is AWS-hosted, the AWS infrastructure configuration is in scope alongside the application.
ISO 27001: ISO 27001 penetration testing: what auditors look for covers how AWS testing maps to Annex A 8.8 obligations. The ISMS scope defines what must be tested; AWS-hosted systems within the ISMS scope must be tested.
The penetration testing rules of engagement for an AWS engagement should address several AWS-specific items beyond the standard template:
Cloud provider authorisation confirmation. The engagement authorisation should explicitly confirm that testing is conducted under the AWS penetration testing policy and that all tested services are within the permitted service list.
IAM credentials for testing. White-box or grey-box AWS testing typically uses dedicated IAM accounts with specific permissions for the testing period. These accounts should be deleted at engagement close and should not use the root account or existing production IAM identities.
AWS GuardDuty and security monitoring. Whether the internal security team should be alerted that GuardDuty will generate findings during the testing period is an operational decision to make in advance.
Scope boundary at the shared responsibility line. The scope document should explicitly state that testing covers customer-managed resources and stops at the AWS managed infrastructure boundary.
The penetration testing scope guide covers scope definition broadly; AWS engagements require all standard scope dimensions plus explicit handling of the shared responsibility boundary, the list of permitted AWS services, and the IAM identity used for testing.
For penetration testing services in the US covering AWS environments including application security, IAM, and network layer testing, VAPT services, and agentic penetration testing for continuous application-layer coverage running on AWS infrastructure, the 10x Pentest platform covers the application layer. See pricing or get in touch to discuss structuring an AWS security assessment alongside application penetration testing for your environment. Continuous penetration testing covers the model that keeps pace with AWS deployment velocity. External attack surface management vs traditional pentesting covers how EASM complements AWS penetration testing for discovering the full external-facing AWS surface.
Q1. Do you need AWS permission to conduct penetration testing?
For most customer-owned AWS services, no prior approval from AWS is required. AWS explicitly permits penetration testing of EC2 instances, RDS, Aurora, CloudFront, API Gateway, Lambda, Lightsail, and Elastic Beanstalk resources without prior notification. Certain activities are prohibited regardless of resource ownership, including DNS zone walking of AWS managed zones and any denial-of-service attacks against AWS infrastructure. For activities outside the approved service list or that might affect shared AWS infrastructure, contacting AWS security before testing is appropriate.
Q2. What does the AWS shared responsibility model mean for penetration testing scope?
The shared responsibility model divides security into what AWS manages (the physical data centres, hardware, networking infrastructure, hypervisor layer) and what customers manage (operating systems, applications, data, IAM policies, network configurations). AWS penetration testing covers the customer-managed layer: your application code, your IAM configuration, your security group rules, your S3 access controls. It does not test AWS's own infrastructure, which is not customer-managed and cannot be tested. A clean AWS penetration test result means your configuration and applications are secure, not that AWS infrastructure is secure.
Q3. What is AWS Security Agent and does it replace third-party penetration testing?
AWS Security Agent is a service launched in 2024 that allows customers to run on-demand penetration tests of their AWS environments conducted by AWS security assessors. It identifies IAM misconfigurations, exposed resources, and network security gaps. It does not replace independent third-party penetration testing for several reasons: it does not satisfy compliance requirements that mandate tester independence from the cloud provider, it does not test application-layer vulnerabilities in customer code, and it does not simulate an external attacker starting with no AWS credentials. AWS Security Agent is most useful for configuration review and baseline assessment; independent third-party testing is required for application security, compliance evidence, and external threat simulation.
Q4. What are the most critical AWS-specific attack surfaces to test?
The AWS attack surfaces most consistently producing high-severity findings are: IAM privilege escalation paths (combinations of permissions that allow lower-privilege identities to grant themselves higher-privilege access), EC2 instance metadata service IMDSv1 configuration (which allows any SSRF vulnerability in a running application to retrieve instance role credentials), S3 bucket public access and misconfigured bucket policies, Lambda function execution role over-permission with credentials in environment variables, and security group rules permitting broad inbound access on sensitive ports. These six areas should be explicitly addressed in any AWS penetration test scope.
Q5. How does AWS penetration testing differ from traditional network or application penetration testing?
AWS penetration testing adds a cloud infrastructure configuration layer that traditional network and application testing was not designed to cover. Traditional network testing finds open ports and vulnerable services; AWS penetration testing additionally covers IAM role permissions, S3 access controls, security group configurations, Lambda execution role permissions, and cloud-native misconfigurations that have no on-premises equivalent. Application penetration testing methodology applies to software running in AWS but must be complemented by AWS-specific testing of the infrastructure configuration layer. The most effective AWS security assessments combine application-layer penetration testing with cloud configuration assessment covering the AWS-specific attack surfaces.
Cloud security assessments cover IAM configuration, network controls, storage access, workload security, and logging. This guide maps what each domain tests and what findings look like.
Tejas Dhokane Aug 26, 2026 
Penetration testing without a complete rules of engagement document is a legal and operational risk for both sides. This guide covers every clause and what goes wrong when it is missing.
Tejas Dhokane Aug 26, 2026 
Third-party risk assessment programmes use penetration testing evidence in two ways: requiring it from vendors, and producing it for customers. This guide covers both roles and how to evaluate vendor pentest reports.
Tejas Dhokane Aug 26, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.