A frequent request from Operations to QA teams:
If you want to load test I will need the public IP address for your load agents.
It is a fair request from Operations teams, but by default load agents are ephemeral.
Some of the expensive tools provide their own load agents with fixed IPs, which you pay a large premium for.

Check box for “Associate Public IP Address”

Situation: You can whitelist all of EC2 IP ranges, don’t mind changing white list on every test run, or have API to whitelist IPs (ask us about a custom Plugin to support this).

  • This will assign public IP addresses to your load agents, however, you will not know them ahead of time.  This makes it very difficult for your operations team to manage the Security rules they will need to put in place.
  • Once a test is started the public IP addresses of the load agents are displayed.

load-agents-with-public-ip

Using Elastic IP Addresses

Situation:  A simple mechanism with a bit of manual setup in AWS Console.

This is an easy setup for load tests which require a fixed IP, but needs a few manual steps to make work.  We recommend using this in combination with the pro feature for server management will simplify the setup.  For instructions read Assigning Elastic IP to Load Agents.

Using Cross-Account Security Groups

Situation: Both environments are controlled on AWS and using cross account security groups is acceptable.

In the case where both the load agents and the test environment are on AWS, but in different accounts, you can use security groups to allow cross account permissions.

This method has some serious limitations as noted in Classic and VPC Security Group Differences.

  • EC2-Classic – You can reference security groups from other AWS accounts.
    • Many of the new EC2 locations and sizes do not allow the use of EC2-Classic.  If you can stick with the m3 sizes in Virginia this is a good method.
  • EC2-VPC – You can reference security groups from your VPC or from a peer VPC in a VPC peering connection only. The peer VPC can be in a different account.
    • This requires setting up VPC Peering between accounts.  A great method but requires work on the operations teams.

Using Internal Security with Security Groups

Situation:  Both environments are on same AWS account but in different VPCs, probably controlled with internal load balancers.

In many test scenarios, you want to hit an internal application running on a private AWS subnet. The application access is managed by an internal ELB with a distinct security group. We have documented the details load testing internal application using security groups.

Using Private Subnets and NAT Gateways

Situation: Load testing external application and have to supply an IP address to the operations team.
While the most complex in setting up, it also provides the most flexibility.    We have a simple setup guide and an advanced setup guide that covers the case where you want to test internal applications (AWS or not) by setting up a NAT gateway.
  • Once you configure your NAT Gateway just launch your load agents into the proper subnet.
  • You will end up with all load agent traffic within a subnet coming from a single IP traffic