SSH keys#

Amazon EC2 uses public–key cryptography to encrypt and decrypt login information. Public–key cryptography uses a public key to encrypt a piece of data, such as a password, then the recipient uses the private key to decrypt the data. Together, the public and private keys are known as a key pair.

To log into your instance where Presto is installed, you must: (1) create a key pair; (2) specify the name of the key pair when you launch the instance or invoke the CloudFormation template; and (3) provide the private key when you connect to the instance. This enables you to securely access your instance using the private key pair instead of a password.


Amazon EC2 stores only the public key and you are responsible for storing the private key. Take action to safeguard your keys, as anyone who possesses your private key can decrypt your login information.

You can find more information about key pair usage with EC2 in the documentation.

VPC and VPC subnets#

Amazon Virtual Private Cloud (VPC) lets you provision a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define. You are given complete control over your virtual networking environment, including the selection of your IP address range, the creation of subnets, and network gateways.

A VPC spans all the availability zones in the region. After creating a VPC, you can add one or more subnets in each availability zone. A subnet is a range of IP addresses in your VPC for which you can launch AWS resources. You can use public subnets for resources that must be connected to the internet, and private subnets for resources that won’t be connected to the internet.

When using Starburst’s CloudFormation template for Presto, you must specify which existing VPC and subnets to deploy to.

You can find more information about VPCs and subnets in the documentation.

Security groups#

A security group acts as a virtual firewall that controls the traffic allowed to reach one or more of your EC2 instances. When you deploy an instance, you are responsible for associating it with one or more security groups. You add rules to each security group that allow traffic to or from its associated instances on specified ports. Furthermore, you can modify the rules for a security group at any time. Once modified, the new rules are automatically applied to all instances that are associated with the security group.

It’s recommended that ports 8080 and 8088 are accessible in order to access the Presto Web UI, submit queries from outside the cluster, and access Apache Superset. Additionally, it’s recommended that port 22 is accessible for SSH access.

You can find more information about security groups in the documentation.

IAM permissions#

AWS Identity and Access Management (IAM) is a web service that helps you securely control access to your AWS resources. You use IAM to control who is authenticated and authorized to use resources. Principally, it helps you to define what a user or other entity is allowed to do in an account. Authorizations are granted through policies that, when attached to an identity or AWS resource, define their permissions.

There are various features under the IAM umbrella, spanning from granular permissions and shared account access to secure access to AWS resources for applications that run on Amazon EC2.

Instance profiles#

An instance profile is a container for an IAM role that you can use to pass role information to an EC2 instance when the instance starts. An IAM role is an IAM entity that defines a set of permissions for making AWS service requests.

If you use the AWS Management Console to create a role for Amazon EC2, the console automatically creates an instance profile and gives it the same name as the role. When you then use the Amazon EC2 console to launch an instance with an IAM role, you can select a role to associate with the instance. In the console, the list that’s displayed is actually a list of instance profile names.

However, if you manage your roles from the AWS CLI or the AWS API, you create roles and instance profiles as separate actions. Because roles and instance profiles can have different names, you must know the names of your instance profiles as well as the names of roles they contain. That way you can choose the correct instance profile when you launch an EC2 instance.

When using Starburst’s CloudFormation template for Presto, you can specify the instance profile to associate with the EC2 instances. For example, this may be useful to provide the EC2 instance the appropriate privileges to access data in S3.

You can find more information about instance profiles.

AWS security prerequisites#

IAM role Permissions for Presto cluster nodes#

Below is a JSON segment for the IAM role automatically created by the Starburst CloudFormation template. The role is used by the Presto cluster nodes that are created on the stack. The permissions set below are a minimal subset of IAM permissions:

    "Statement": [
            "Action": [
            "Effect": "Allow",
            "Resource": [
    "Version": "2012-10-17"

In the above:

  • AutoScaling, EC2 and SQS permissions are needed for Graceful scaledown of workers to work, when autoscaling kicks in, or reshaping the cluster via the stack modification.

  • CloudWatch Logs permissions are needed to enable logging to AWS CloudWatch Logs

  • CloudFormation permission is needed to report startup progress back to CloudFormation

  • CloudWatch permissions are needed to run the coordinator high availability features.

  • Glue access is needed to leverage the Glue catalog.

  • S3 permissions are needed for the Hive connector to actually access (read/write) the data on S3.

If a user wants to have a more precise control over the permissions, and for example limit S3 access to a specific bucket, then a custom IAM Instance Profile can be provided and passed to the CloudFormation template during stack creation (IamInstanceProfile field in the stack creation form). It is then used instead and the IAM Role and Instance Profile are not created.

Caution should be taken though to make sure that all the other permissions regarding AutoScaling, SQS, EC2, CloudFormation, CloudWatch and Glue are given to this custom role, otherwise the cluster either fails to start or does not function as documented.

Additionally the role needs to have a trust relationship to EC2 established, so that EC2 can use this role on the user’s behalf. Below is a minimal trust relationship document:

  "Version": "2012-10-17",
  "Statement": [
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": ""
      "Action": "sts:AssumeRole"

IAM role permissions for CloudFormation#

The user who launches the CloudFormation template needs to have specific permissions to issue all necessary actions in AWS during stack creation. In particular, before proceeding make sure your IAM user/role has a policy with permissions to manage all of the following:

    "Statement": [
            "Action": [
            "Effect": "Allow",
            "Resource": [
    "Version": "2012-10-17"

The role needs to have a trust relationship to CloudFormation established, so that CloudFormation can use this role on the user’s behalf. Below is a minimal trust relationship document:

  "Version": "2012-10-17",
  "Statement": [
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": ""
      "Action": "sts:AssumeRole"

Presto license#

To enable additional enterprise features, you need to configure the License S3 URI in the CloudFormation template. This is required when using Starburst’s CloudFormation template and a privately shared Presto AMI.

Refer to Starburst Enterprise Presto license for information on how to obtain this license. You do not need to configure the license this way when you have subscribed to the software in AWS Marketplace.