# Guidelines for optimizing AWS EC2 instances

This page provides a list of best practices when optimizing applications on AWS EC2 instances with Akamas.

## Environment setup <a href="#environment-setup" id="environment-setup"></a>

Before planning out an AWS study you must first ensure you have all the rights to effectively launch it.\
This means you have to:

1. Check your [policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)
2. Check your [security groups](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html)

### Policies <a href="#policies" id="policies"></a>

Policies allow instance manipulation and access by being attached to users, group or AWS resources.

The suggested best practice to avoid impacting other critical environments, like production, is to [create multiple accounts](https://aws.amazon.com/it/organizations/getting-started/best-practices/) in order to isolate the Akamas instance and the tested resources.

Whether the case, you’re also required to comply with the [AWS Policies](#aws-policies) for instance manipulation. In the following, we show a standard, tag and resource-based policy.

[Tags](https://aws.amazon.com/it/premiumsupport/knowledge-center/iam-ec2-resource-tags/) are indeed a robust way to scope your Akamas optimizations: you can invariantly refer to instances and sets of instances across generations and stack them for more elaborate conditions.

[Tailoring your policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonec2.html) on your EC2 resources neatly avoids collateral effects during your experiments.

#### AWS Policies

In order to correctly enable the provisioning and manipulation of EC2 instances you have to set the correct [AWS policies](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policies-for-amazon-ec2.html). Notice that AWS offers several [pre-made policies](https://awspolicygen.s3.amazonaws.com/policygen.html).

Here we provide some basic resource-based permissions required in our scope:

* EC2 instance start
* EC2 instance stop
* EC2 instance reboot
* EC2 instance termination
* EC2 instance description
* EC2 instance manipulation

```json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances",
                "ec2:RebootInstances",
                "ec2:TerminateInstances",
                "ec2:ModifyInstanceAttribute"
            ],
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "StringEquals": {
                    "ec2:ResourceTag/Owner": "${aws:username}"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "ec2:DescribeInstances",
            "Resource": "*"
        }
    ]
}

```

Consider using [tags](https://aws.amazon.com/it/premiumsupport/knowledge-center/iam-ec2-resource-tags/) in order to enforce finer access control for the automation tools, as shown in the example above.

Refer to the [official reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonec2.html) for a complete list of AWS EC2 policies.

### Security Groups <a href="#security-groups" id="security-groups"></a>

Security groups control inbound and outbound traffic to and from your AWS instances.\
In your typical optimization scenario, the security group should allow inbound connections on SSH and any other relevant port, including the ones used to gather the telemetry, from the Akamas instance to the ones in the tuned system.

## Workflows setup <a href="#workflows-setup" id="workflows-setup"></a>

Akamas workflows managing EC2 instances usually expect you to either create throwaway instances or resize already existing ones. This [page](https://docs.akamas.io/akamas-docs/3.6/knowledge-base/leveraging-ansible-to-automate-aws-instance-management) provides an example for both cases: all you need to do is to apply the [FileConfigurator operator](https://docs.akamas.io/akamas-docs/3.6/reference/workflow-operators/fileconfigurator-operator) by making the *instance type* and *instance size* parameters tunable.

Notice that:

* The [Sleep operator](https://docs.akamas.io/akamas-docs/3.6/reference/workflow-operators/sleep-operator) comes in handy in between instance provisioning. Creating an instance and more so waiting for its DNS to come up may take a while, so forcing a few minutes to wait is usually worth it. This operator is a viable option if you can’t force it through an automation tool.
* The [Executor operator](https://docs.akamas.io/akamas-docs/3.6/reference/workflow-operators/executor-operator) is better suited for launching benchmarks and applications rather than for setting up your instance. It’s better to use automation tools or ready-to-use AMIs to set up all required packages and dependencies, as the workflow should cover your actual study case.
* The study environment has to be restored to its original configuration between experiments. While that is quite simple to achieve when creating and terminating instances, this may require additional steps in a resizing scenario.
* The deletion and creation of new instances determine changes in ECDSA host keys.\
  This may be interpreted as DNS spoofing from the Akamas instance, so consider overriding the default settings in such contexts.

## Telemetry setup <a href="#telemetry-setup" id="telemetry-setup"></a>

While the CloudWatch Exporter is a natural choice for EC2 instance monitoring, EC2 instances are often Linux instances, so it’s useful to use the [Linux optimization pack](https://docs.akamas.io/akamas-docs/3.6/reference/optimization-packs/linux-pack) through the [Prometheus provider](https://docs.akamas.io/akamas-docs/3.6/integrating/integrating-telemetry-providers/prometheus-provider) paired with the Node exporter every time you can directly access the instance.