Amazon EC2 Testing Policy

This policy concerns customers who are planning on running high volume network tests directly from their Amazon EC2 instances to other locations such as other Amazon EC2 instances, AWS properties/services, or external endpoints. These tests are sometimes called stress tests, load tests, or gameday tests. For the sake of this policy we consider a "network stress test" to be when a test sends a large volume of legitimate or test traffic to a specific intended target application. The endpoint and infrastructure are expected to be able to handle this traffic. This policy is not concerned with normal production traffic. Network stress tests are different from normal production because network stress tests often target specific endpoints, have different traffic patterns including the concentration of sources and targets, maintain higher sustained volume than normal traffic, and can accidentally exceed expected limits. During network stress tests, these differences present potential risks for unintended impact to external endpoints, other customers, or AWS services.

Tests that purposefully attempt to overwhelm the target and/or infrastructure with packet or connection flooding attacks, reflection and complexity attacks, or other large volumes of traffic are not considered network stress tests but are considered distributed denial of service (DDoS) tests. Volumetric network-based DDoS simulations are explicitly prohibited from the Amazon EC2 platform and are not covered by this policy. Customers wishing to perform a DDoS simulation test should review our DDoS Simulation Testing policy.

Most customer testing will not fall under this policy. Normally, tasks like customer unit tests simulating large workloads for stress testing do not generate traffic that qualifies as network stress tests. This policy only applies when a customer's network stress test generates traffic from their Amazon EC2 instances which meets one or more of the following criteria: sustains, in aggregate, for more than 1 minute, over 1 Gbps (1 billion bits per second) or 1 Gpps (1 billion packets per second); generates traffic that appears to be abusive or malicious; or generates traffic that has the potential for impact to entities other than the anticipated target of the testing (such as routing or shared service infrastructure). Customers will need to ensure the target endpoint has authorized the testing and understands the expected volumes. Some external endpoints or AWS services may have lower than expected thresholds for certain testing scenarios. We understand that many of our large customers generate more than 1 Gbps or 1 Gpps of traffic in normal production mode regularly, which is completely normal and not under the purview of this policy, unless specifically done for the purpose of network stress testing.

Network stress tests that meet this policy's criteria have risks: the customer may be detected and/or reported as being abusive; the customer might be unintentionally abusive and/or impactful to other entities; and the customer might have mitigations applied to their instances, which can impact their tests as well as their production workloads. If a customer is unsure if their tests meet these criteria, they should follow this policy, and have AWS evaluate the tests. To improve the experience for the customer and other entities that might be impacted by such a test, before these stress tests are performed, the customer must fill out an Amazon EC2 Network Stress Test intake form, which can be obtained by completing the form. If a customer’s network stress tests are performed via means other than directly from their EC2 instances, i.e. via external or other AWS services, they should send an email to determine if they need to submit a form. AWS will generally respond to e-mail inquiries within 48 hours, please feel free to follow up if you have not received a response within that time frame.

Upon receiving the form, AWS will evaluate the test parameters and respond with what steps are needed to help prevent accidental impact. If AWS determines there is not likely to be impact , there will be no steps, but AWS will be ready to respond if needed. For tests that might have impact , steps may include running the network generating tests from a separate AWS account, adjusting the tests to minimize risk, or working with AWS Support closely to understand the scenarios and processes. Even with approval from AWS, the customer is still responsible for any damages to AWS, other AWS customers, or external entities that are caused by testing activities.