AWS Security Testing: What Needs Prior Approval and What Does Not

When you run a vulnerability assessment or penetration test against systems on AWS, where the line falls between what needs prior approval and what does not is easy to get wrong. This article sets out what AWS's official policy page said when it was checked on 4 August 2026. The policy is revised over time, so always read the current official version yourself before testing.

What exactly does "no prior approval" cover?

The opening of the official page states that customers may carry out security assessments or penetration tests of their own AWS infrastructure without prior approval for the services listed under "Permitted Services". In other words, the request form that used to be required is no longer needed for those services.

That exemption is not unconditional. At the time of checking, the page carried at least three accompanying constraints.

• Your own assets only. The page states plainly: "Customers are not permitted to conduct any security assessments of AWS infrastructure or the AWS services themselves."
• Anything involving C2 needs prior approval. "All security testing that includes Command and Control (C2) requires prior approval."
• Prohibited activities are listed separately. Even on a permitted service, the activities listed below are not allowed.

Services listed as testable without prior approval

At the time of checking, the "Permitted Services" list read as follows, in the page's own order.

For anything not on the list, the page states: "Customers seeking to test non approved services will need to work directly with AWS Support or your account representative." So services absent from the list are handled by talking to AWS directly. The list is added to and revised, so always check the live page before testing.

Activities listed as prohibited

The "Prohibited Activities" section listed the following at the time of checking.

• 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 (subject to the DDoS Simulation Testing policy)
• Port flooding
• Protocol flooding
• Request flooding (login request flooding, API request flooding)
• S3 bucket takeover
• Subdomain Takeover

A further sub-list, "Prohibited Services for Outbound Penetration Testing", named Amazon API Gateway and Amazon Bedrock AgentCore. Note that API Gateway appears both among the permitted services and in this outbound prohibition, so take care not to conflate the two.

The policy also drew some related distinctions.

• A tool that merely performs a remote query to obtain a software name and version, such as banner grabbing, in order to compare against a list of versions known to be vulnerable, is stated not to violate the policy.
• A tool or service that crashes a running process as a necessary part of remote or local exploitation is stated not to violate the policy, but that tool may not engage in protocol flooding or resource request flooding.
• A tool or service that creates, determines the existence of, or demonstrates a DoS condition in any other manner, actual or simulated, is expressly forbidden.
• Any tool with such a DoS capability must have an explicit way to disable, disarm or render it harmless; otherwise it may not be used for any part of the assessment.

What the page says needs a form submitted in advance

Under "Other Simulated Events", the page stated that a Simulated Events form must be submitted for the following.

The submission is expected to include dates, the account IDs involved, the assets involved, contact information including a phone number, and a detailed description of the planned events. A non-automated acknowledgement is said to arrive within two business days, and "All Simulated Event requests must be submitted to AWS at least two (2) weeks in advance of the start date." After authorisation, the page states that no further action is required and testing may run through the end of the period indicated.

Requests go through a Support console form, not email. The link targets at the time of checking were:

• Simulated Events form: https://console.aws.amazon.com/support/contacts#/simulated-events
• For the AWS China (Ningxia and Beijing) Regions: https://console.amazonaws.cn/support/contacts#/simulated-events
• Stress Test policy: https://aws.amazon.com/ec2/testing/
• DDoS Simulation Testing policy: https://aws.amazon.com/security/ddos-simulation-testing/

Responsibilities the page places on the tester

• Testing is subject to the terms of the AWS Customer Agreement.
• It is limited to the services, network bandwidth, requests per minute and instance type indicated.
• Any vulnerabilities or issues found that are a direct result of AWS's own tools or services must be conveyed to AWS Security within 24 hours of completing testing. The address given is aws-security@amazon.com.
• The tester is responsible for any damage to AWS or to other AWS customers caused by the testing.
• If AWS receives an abuse report relating to the testing, it is forwarded to the tester, who is asked to supply approved language describing the use case and a point of contact that can be shared with third-party reporters.
• Resellers of AWS services are responsible for their customers' security testing activity.

A checklist to use while reading the official page

Do not launch tests against production on the strength of this article. With that said, here are the questions worth answering against the live policy.

1. Is the target service on the current Permitted Services list?
2. Is the scope strictly your own assets, with no multi-tenant neighbours or third-party-managed assets mixed in?
3. Do your tools include any DoS-equivalent capability, and if so can it be reliably disabled?
4. Does the plan involve C2, simulated phishing, malware testing or load testing? If so the page states a form is required at least two weeks in advance.
5. Do you have internal approval, sign-off from the system owner and a record-keeping plan? (These sit outside the AWS policy but are still necessary.)