There is additional setup required when running CloudTest within a custom VPC, this article will dig into what those are and what settings are needed for the product to function correctly. If you use the default VPC and default security group there are no extra steps that need to be taken. The following assumes you have a VPC created, or you can create one specifically for CloudTest. It's also a good idea to have a naming convention. You'll see in the example below we use cloudtest-*** as our convention.
If you use the default VPC and default security group you don't need to continue. Other than to open ports on the security group as described below. If you use the default VPC (one that was created when the account was created, not one from a converted Classic account) and a custom security group, again, in AWS you need only open ports on that security group and you can skip to the ports section below. However, this will require an extra step in CloudTest when creating grids.
If you are going to use a custom VPC and it's not already set up you'll need to do so once you've logged into AWS with the appropriate permissions. Name the VPC, create the CIDR block, and configure to any other required specifications. You will only want to create one VPC for CloudTest per region, and will need a VPC in each region you expect to use for load generation. You can use the same name in each region.
The CloudTest instance needs to be able to talk to itself using the instance hostname.
- Navigate to VPC > Your VPCs
- Right click on the VPC and click Edit DNS Hostnames
- Set the radio button to Yes
- Click Save
- Right click on the VPC and click Edit DNS Resolution to make sure that is also set to Yes. By default it should be. If not, select Yes and Save.
You will either need to create a new Subnet or use a previously created one and associate it with your VPC. We'll create one from scratch. Assuming you're still in the VPC Dashboard:
- Select Subnets > Create Subnet
- In the dialog box, select the above VPC, an Availability Zone, CIDR range, and click Yes, Create. In most cases you'll want to select a newer AZ. The CIDR range is a subset of your VPC's range.
- You can create Subnets in each availability zone to get more bandwidth and/or decrease the chances you'll run into an availability issue in a zone. As with the VPCs, you will need to create at least one Subnet in each region from which you want to generate load.
You will either need to create a new Internet Gateway or use a previously created one and associate it with your VPC. There is a one to one relationship between a VPC and an Internet Gateway. Assuming you're still in the VPC Dashboard:
- Select Internet Gateways > Create Internet Gateway
- Name your Internet Gateway and click Yes, Create
- Right-click the Internet Gateway and select Attach to VPC. You can also select it and choose Attach to VPC in the button above.
- Select your VPC from the list and click Yes, Attach
You can use the route table that greats created when you created the VPC. In that case, you would then right click on the route table and rename it. You would then skip the first two steps below.
- Select Route Tables > Create Route Table
- Give your Route Table a name, select your VPC and click Yes, Create
- Select your newly created Route Table, click on the Routes tab, click Edit and then Add another route
- Under Destination enter 0.0.0.0/0 and under Target select the Internet Gateway you created then click Save
- Select the Subnet Associations tab and click Edit
- In the Associate column click the box next to your subnet, then click Save
You can use the default security group that greats created when you created the VPC. If you use the default security group, when you create a grid in CloudTest you only need to enter the Subnet ID for the region.
You can also create your own security group. Whether you use the default security group or a custom security group you need to set the inbound rules as described below. To create a custom security group (you can do this from within the VPC Dashboard or the EC2 Dashboard):
- Select Security Groups > Create Security Group
- Enter a Name tag, Group name, Description and choose the VPC, click on Yes, Create
- Select the security group you just created, click on the Inbound Rules tab and click on Edit
- Enter the rules as shown below, the Source on the line for All Traffic is the security group itself, which will be selectable.
- This will look slightly different if entered in the EC2 Dashboard. See below:
The SSH port is for Akamai's VPN access. You don't need to open that port but it's helpful if you want Akamai to troubleshoot any issues. The port is 188.8.131.52/32.
DHCP Options Sets
This section is more just to verify things are configured correctly, you should not need to create a new DHCP Options Set to see if it's set to the defaults. CloudTest requires that the hostname given to an instance is resolvable within the instance, and if you are using a custom DHCP server or you do not set the "domain-name" setting correctly then the CloudTest instances will fail to launch correctly. If you are using a custom DHCP configuration and are sure it the instances will be provided a resolvable hostname you can skip this.
- Select Your VPCs
- Select the VPC that will be used by CloudTest, and in the Summary click the DHCP options set.
- Look for the option domain-name. It should be set to either ec2.internal for a VPC in us-east-1 or <region>.compute.internal for other regions. For example, if you are setting this VPC up in AWS Frankfurt you would use eu-central-1.compute.internal, or if in AWS Oregon it would be us-west-2.compute.internal.
- The option domain-name-servers must be AmazonProvidedDNS. If not you will need to recreate the DHCP Options Set to use those values and associate this new DHCP Option Set with the VPC.
When you build you CTM Environment and are using a custom VPC and custom security group you will need to specify both the Security Group and the Subnet ID in your Environment Configuration. Similarly, when you are launching a grid you must use the Security Group (assuming you didn't use the default for that VPC) and Subnet ID for each region.