Penetration Testing
AWS Customer Support Policy for Penetration Testing
AWS customers are welcome to carry out security assessments or penetration tests of their AWS infrastructure without prior approval for the services listed in the next section under “Permitted Services.” Additionally, AWS permits customers to host their security assessment tooling within the AWS IP space or other cloud provider for on-prem, in AWS, or third party contracted testing. All security testing that includes Command and Control (C2) requires prior approval.
Please ensure that these activities are aligned with the policy set out below. Note: Customers are not permitted to conduct any security assessments of AWS infrastructure or the AWS services themselves. If you discover a security issue within any of the AWS services observed in your security assessment, please contact AWS Security immediately.
If AWS receives an abuse report for activities related to your security testing, we will forward it to you. When responding, please provide us with approved language detailing your use case, including a point of contact that we can share with any third party reporters. Learn more here.
Resellers of AWS services are responsible for their customers’ security testing activity.
Customer Service Policy for Penetration Testing
Permitted Services
- Amazon EC2 instances, WAF, NAT Gateways, and Elastic Load Balancers
- Amazon RDS
- Amazon CloudFront
- Amazon Aurora
- Amazon API Gateways
- AWS AppSync
- AWS Lambda and Lambda Edge functions
- Amazon Lightsail resources
- Amazon Elastic Beanstalk environments
- Amazon Elastic Container Service
- AWS Fargate
- Amazon Elasticsearch
- Amazon FSx
- Amazon Transit Gateway
- S3 hosted applications (targeting S3 buckets is strictly prohibited)
Customers seeking to test non approved services will need to work directly with AWS Support or your account representative.
Prohibited Activities
- DNS zone walking via Amazon Route 53 Hosted Zones
- DNS hijacking via Route 53
- DNS Pharming via Route 53
- Denial of Service (DoS), Distributed Denial of Service (DDoS), Simulated DoS, Simulated DDoS (These are subject to the DDoS Simulation Testing policy Port flooding
- Protocol flooding
- Request flooding (login request flooding, API request flooding)
Other Simulated Events
Red/Blue/Purple Team Testing
Red/Blue/Purple Team tests are adversarial security simulations designed to test an organization’s security awareness and response times
Customers seeking to perform covert adversarial security simulations and/or hosting Command and Control (C2) must submit a Simulated Events form for review.
Network Stress Testing
Stress Testing is a performance test that sends a large volume of legitimate or test traffic to a specific intended target application to ensure efficient operational capacity. The endpoint application is expected to perform its intended function as part of the test. Any attempt to overwhelm the target is considered a denial of service (DoS).
Customers wishing to perform a Network Stress Test should review our Stress Test policy.
iPerf Testing
iPerf is a tool for network performance measurement and tuning. It is a cross-platform tool that can produce standardized performance measurements for any network.
Customers seeking to perform iPerf testing must submit a Simulated Events form for review.
DDoS Simulation Testing
Distributed Denial of Service (DDoS) attacks occur when attackers use a flood of traffic from multiple sources to attempt to impact the availability of a targeted application. DDoS simulation testing uses a controlled DDoS attack to enable the owner of an application to evaluate the resiliency of the application and to practice event response.
Customers wishing to perform a DDoS simulation test should review our DDoS Simulation Testing policy.
Simulated Phishing
Simulated Phishing is the simulation of an attempted social engineering attack which tries to obtain sensitive information from users. The goal is to identify users and educate them on the difference between valid emails and phishing emails to increase organizational security.
Customers seeking to perform Simulated Phishing campaigns must submit a Simulated Events form for review.
Malware Testing
Malware Testing is the practice of subjecting malicious files or programs to applications or antivirus programs to improve security features.
Customers seeking to perform Malware Testing must submit a Simulated Events form for review.
Requesting Authorization for Other Simulated Events
AWS is committed to being responsive and keeping you informed of our progress. Please submit a Simulated Events form to contact us directly. (For customers operating in the AWS China (Ningxia & Beijing) Region, please use this Simulated Events form.)
Be sure to include dates, account ID’s involved, assets involved, and contact information, including phone number and detailed description of planned events. You should expect to receive a non-automated response to your initial contact within 2 business days confirming receipt of your request.
All Simulated Event requests must be submitted to AWS at least two (2) weeks in advance of the start date.
Testing Conclusion
No further action on your part is required after you receive our authorization. You may conduct your testing through the conclusion of the period you indicated.
Terms and Conditions
All Security Testing must be in line with these AWS Security Testing Terms and Conditions.
Security Testing:
- Will be limited to the services, network bandwidth, requests per minute, and instance type.
- Is subject to the terms of the Amazon Web Services Customer Agreement between you and AWS
- Will abide by AWS’s policy regarding the use of security assessment tools and services, included in the next section
Any discoveries of vulnerabilities or other issues that are the direct result of AWS’s tools or services must be conveyed to AWS Security within 24 hours of completion of testing.
AWS Policy Regarding the Use of Security Assessment Tools and Services
AWS's policy regarding the use of security assessment tools and services allows significant flexibility for performing security assessments of your AWS assets while protecting other AWS customers and ensuring quality-of-service across AWS.
AWS understands there are a variety of public, private, commercial, and/or open-source tools and services to choose from for the purposes of performing a security assessment of your AWS assets. The term "security assessment" refers to all activity engaged in for the purposes of determining the efficacy or existence of security controls amongst your AWS assets, e.g., port-scanning, vulnerability scanning/checks, penetration testing, exploitation, web application scanning, as well as any injection, forgery, or fuzzing activity, either performed remotely against your AWS assets, amongst/between your AWS assets, or locally within the virtualized assets themselves.
You are NOT limited in your selection of tools or services to perform a security assessment of your AWS assets. However, you ARE prohibited from utilizing any tools or services in a manner that perform Denial-of-Service (DoS) attacks or simulations of such against ANY AWS asset, yours or otherwise. Customers wishing to perform a DDoS simulation test should review our DDoS Simulation Testing policy.
A security tool that solely performs a remote query of your AWS asset to determine a software name and version, such as "banner grabbing," for the purpose of comparison to a list of versions known to be vulnerable to DoS, is NOT in violation of this policy.
Additionally, a security tool or service that solely crashes a running process on your AWS asset, temporary or otherwise, as necessary for remote or local exploitation as part of the security assessment, is NOT in violation of this policy. However, this tool may NOT engage in protocol flooding or resource request flooding, as mentioned above.
A security tool or service that creates, determines the existence of, or demonstrates a DoS condition in ANY other manner, actual or simulated, is expressly forbidden.
Some tools or services include actual DoS capabilities as described, either silently/inherently if used inappropriately or as an explicit test/check or feature of the tool or service. Any security tool or service that has such a DoS capability, must have the explicit ability to DISABLE, DISARM, or otherwise render HARMLESS, that DoS capability. Otherwise, that tool or service may NOT be employed for ANY facet of the security assessment.
It is the sole responsibility of the AWS customer to: (1) ensure the tools and services employed for performing a security assessment are properly configured and successfully operate in a manner that does not perform DoS attacks or simulations of such, and (2) independently validate that the tool or service employed does not perform DoS attacks, or simulations of such, PRIOR to security assessment of any AWS assets. This AWS customer responsibility includes ensuring contracted third-parties perform security assessments in a manner that does not violate this policy.
Furthermore, you are responsible for any damages to AWS or other AWS customers that are caused by your testing or security assessment activities.
