Trino on AWS User Guide

Overview

This image runs Trino, the fast distributed SQL query engine for big data analytics, formerly known as PrestoSQL. Trino lets you run interactive ANSI SQL over data sources of any size and join across many systems in a single query. The image is configured as a single node deployment, where one JVM acts as both the coordinator and the worker, so it runs SQL out of the box on a single instance.

The Trino server is installed under /opt/trino and runs as a dedicated unprivileged trino system account under a systemd service that starts it on boot and restarts it on failure. Trino 481 requires Java 25, so the image bundles an Eclipse Temurin 25 runtime under /opt/trino/jre and pins it to the engine. The engine configuration, the connector catalogs and the node data directory live under /opt/trino-data, which is a dedicated, independently resizable EBS data volume.

Trino's Web UI, REST API and JDBC endpoint have no usable authentication over plain HTTP, so the engine binds to the loopback interface only and is never exposed directly. An nginx reverse proxy publishes the Web UI, the query REST API and the JDBC and CLI endpoint on port 80 behind HTTP Basic authentication. The admin password is generated on the first boot of every deployed instance, so two instances launched from the same Amazon Machine Image never share a password. It is written to /root/trino-credentials.txt with mode 0600 so that only the root user can read it.

Prerequisites

Before you deploy this image you need:

• An Amazon Web Services account where you can launch EC2 instances
• IAM permissions to launch instances, create security groups, and subscribe to AWS Marketplace products
• An EC2 key pair in the target Region for SSH access to the instance
• A VPC and subnet in the target Region, with a security group allowing inbound port 22 from your management network and port 80 for the Web UI, the REST API and JDBC
• The AWS CLI (version 2) installed locally if you plan to deploy from the command line

Step 1: Launch the Instance from the AWS Marketplace

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images choose AWS Marketplace AMIs and search for Trino. Select the cloudimg listing and choose Select, then Continue on the subscription summary.

Pick an instance type of t3.large or larger. Trino is memory hungry, so choose a larger instance for production query workloads. Choose your EC2 key pair under Key pair (login). Under Network settings select your VPC and subnet, and either create or select a security group that opens port 22 from your management network and port 80 for the Web UI and the APIs. Leave the root volume at the default size or larger.

Select Launch instance. First boot initialisation takes a few seconds after the instance state becomes Running and the status checks pass, and the JVM needs a little longer to finish starting the coordinator.

Step 2: Launch the Instance from the AWS CLI

The following block launches an instance from the cloudimg Trino Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing, <key-name> with your EC2 key pair name, <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens ports 22 and 80 as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type t3.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=trino}]'

When the instance reaches the Running state and its status checks pass, note its public IP address or DNS name from the EC2 console or with aws ec2 describe-instances.

Step 3: Connect to Your Instance

Connect over SSH using your key pair and the login user for your operating system variant.

ssh -i <key-name>.pem ubuntu@<public-ip>

Step 4: Retrieve the Admin Password

The Trino admin password is unique to your instance and was generated on first boot. Read it as root:

sudo cat /root/trino-credentials.txt

The file lists the Trino URL, the admin user (admin) and the generated password, along with an example CLI command. Keep this password somewhere safe.

Step 5: Sign In to the Trino Web UI

The Trino Web UI is served on port 80 by nginx behind HTTP Basic authentication. In a browser, go to:

http://<instance-public-ip>/

You are first prompted by the browser for HTTP Basic credentials: sign in as admin with the password from the credentials file. The Trino Web UI then shows its own login form. Enter the username admin and leave the password field blank, because nginx has already authenticated you. The cluster overview opens, showing the running worker, query throughput and the cluster state.

Run a query from the Web UI, the CLI or a SQL tool and it appears in the query list. Select a query to open its detail view, which shows the execution stages, the query plan and live statistics.

The query list shows recently executed queries with their state, the submitting user and the elapsed time, so you can monitor activity across the cluster.

Step 6: Confirm Trino Is Running

Over SSH, confirm the engine and the nginx proxy are active and that the ports are listening:

sudo systemctl is-active trino nginx
sudo ss -tlnp | grep -E ':(80|8080) '

You should see both services reported as active, the engine listening on 127.0.0.1:8080 (loopback only), and nginx listening on port 80. You can check the coordinator has finished starting with the unauthenticated health endpoint:

curl -s http://127.0.0.1:8080/v1/info

A response with "starting":false means the coordinator is ready to accept queries.

Step 7: Run SQL with the Trino CLI

The image installs the Trino command line client at /usr/local/bin/trino. On the instance, query the built in tpch connector, which serves industry standard sample data so SELECT works immediately with no external database:

trino --server http://127.0.0.1:8080 --user admin --catalog tpch --schema tiny \
  --execute 'SELECT count(*) FROM nation'

The tpch connector exposes several scale factor schemas (tiny, sf1, sf100 and larger). Run an aggregate query over the orders table:

trino --server http://127.0.0.1:8080 --user admin --catalog tpch --schema sf1 \
  --execute 'SELECT orderpriority, count(*) AS n FROM orders GROUP BY orderpriority ORDER BY orderpriority'

List the catalogs that are configured on the engine:

trino --server http://127.0.0.1:8080 --user admin --execute 'SHOW CATALOGS'

Step 8: Create Tables with the Memory Connector

The bundled memory connector provides writable, in memory tables that are useful for demos and intermediate results. Create a table, insert into it and read it back:

trino --server http://127.0.0.1:8080 --user admin --catalog memory --schema default \
  --execute "CREATE TABLE IF NOT EXISTS example AS SELECT 1 AS id, 'hello' AS label"
trino --server http://127.0.0.1:8080 --user admin --catalog memory --schema default \
  --execute "SELECT * FROM example"

Memory connector data lives only in the JVM and is cleared when the engine restarts.

Step 9: Connect over JDBC

Trino speaks the standard Trino JDBC protocol over the same port 80 proxy. From a SQL tool or application, use the Trino JDBC driver with a URL of the form jdbc:trino://<instance-public-ip>:80, set the user to admin, and supply the generated password as the HTTP Basic credential (in many tools this is the connection password field, with the SSL option turned off because the bundled proxy serves plain HTTP). You can then browse the tpch and memory catalogs and run SQL from your existing tooling, including BI dashboards and dbt.

Step 10: Add a Connector Catalog

Trino reaches external systems through connector catalogs. Each catalog is a small properties file under /opt/trino-data/etc/catalog. For example, to add a PostgreSQL catalog, create /opt/trino-data/etc/catalog/postgresql.properties with the connector name and your connection details, then restart the engine:

sudo systemctl restart trino

The new catalog appears in SHOW CATALOGS once the engine has restarted. Trino ships connectors for PostgreSQL, MySQL, Apache Iceberg, Delta Lake, Hive, ClickHouse, MongoDB, Kafka, object storage and dozens more; see the Trino documentation for the properties each connector expects.

Step 11: The Data Volume

The engine configuration, the connector catalogs and the node data directory live on a dedicated EBS volume mounted at /opt/trino-data. This keeps the engine state off the operating system disk and lets you resize or snapshot it independently. Confirm the mount with:

df -h /opt/trino-data

To grow the volume, expand the EBS volume in the AWS console, then grow the filesystem on the instance with sudo resize2fs on the underlying device. The JVM heap is sized for a t3.large in /opt/trino-data/etc/jvm.config; increase the -Xmx value and the query.max-memory settings in config.properties when you move to a larger instance.

Step 12: Enable HTTPS

The Web UI and APIs are served over plain HTTP on port 80 by nginx. For production use, place them behind TLS. Obtain a certificate for your domain (for example with a managed certificate on an Application Load Balancer in front of the instance, or with Certbot installed on the instance), then configure nginx to listen on 443 with your certificate and proxy to 127.0.0.1:8080 exactly as the bundled site does for port 80, keeping the HTTP Basic authentication in place. Restrict the security group so ports 80 and 443 are reachable only from the networks that run queries.

Step 13: Backup and Maintenance

The interesting state on a Trino node is its configuration and catalogs under /opt/trino-data/etc; back these up by snapshotting the /opt/trino-data EBS volume. The tpch connector data is generated on demand and the memory connector is transient, so there is no query data store to back up unless you add a connector to a persistent system, in which case that external system holds the data. Apply operating system security updates with sudo apt-get update && sudo apt-get upgrade and reboot when a new kernel is installed; Trino and nginx start automatically on boot.

Support

This image is published and supported by cloudimg. Support covers deployment, connector and catalog configuration, query tuning, memory and JVM sizing, BI and JDBC integration, and TLS. Contact cloudimg through the support channel listed on the AWS Marketplace listing.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.