Amazon Athena: Serverless Presto/Trino for S3
What it is: Amazon Athena is AWS's serverless query service built on the Presto/Trino engines. You point it at files in S3 (Parquet, ORC, CSV, JSON), write standard SQL, and pay only for the data each query scans — no cluster to size, patch, or keep running.
Quick answer: Amazon Athena is the easiest "managed Presto service": a fully serverless AWS offering that runs Presto/Trino-based SQL directly against data in S3 for $5 per TB scanned (as of 2026). There is zero infrastructure to manage, but costs are driven entirely by how much data each query reads — so partitioning and columnar formats matter more than anything else.
Is Athena the same as Presto?
Effectively yes, from the SQL side. Athena is a managed service wrapped around the open-source engines: engine version 1 was based on Presto 0.172, while engine versions 2 and 3 are based on Presto and then Trino. You get largely the same ANSI SQL dialect and functions as Presto and Trino, but AWS operates the cluster, autoscales it invisibly, and bills per query instead of per node.
The practical differences: Athena limits you to connectors AWS provides (S3 natively, other sources via Lambda-based federated connectors), you cannot tune worker memory or cluster size on the standard tier, and long-running queries hit service timeouts that a self-managed Trino cluster would not impose.
When do Athena costs blow up?
Athena costs explode when queries scan far more data than they return. The classic failure mode is running SELECT ... WHERE date = '2026-08-01' against an unpartitioned table of raw CSV or JSON: Athena must read every byte in the S3 prefix, so a "small" query scans terabytes. At $5/TB, a single careless query over a 10 TB unpartitioned dataset costs $50 — and dashboards repeat that query all day.
-- Unpartitioned CSV: scans the whole dataset every time ($$$)
SELECT COUNT(*) FROM logs_raw WHERE event_date = DATE '2026-08-01';
-- Partitioned Parquet: scans one day's worth of one column (pennies)
SELECT COUNT(*) FROM logs_parquet WHERE dt = '2026-08-01';Three fixes cut most bills by 90%+: partition on the columns you filter by (usually date), convert to Parquet or ORC so Athena reads only needed columns, and compress. AWS's own guidance shows Parquet conversion alone routinely reducing scanned bytes by an order of magnitude.
What It Does Best
Zero-ops SQL on S3. No cluster, no capacity planning, no idle costs. Create a table over existing files and query it in under a minute.
Pay-per-query economics. Ideal for spiky, ad-hoc workloads — you pay nothing between queries, unlike an always-on warehouse or EMR cluster.
AWS-native integration. Reads the Glue Data Catalog, writes results to S3, plugs into QuickSight, Step Functions, and Lake Formation permissions out of the box.
Key Features
Serverless Trino/Presto engine: standard ANSI SQL, window functions, arrays, and joins across S3 data
Federated queries: Lambda-based connectors reach RDS, DynamoDB, Redshift, and more
Apache Iceberg support: ACID inserts, updates, deletes, and time travel on S3 tables
Athena for Spark: serverless PySpark notebooks under the same service
Provisioned Capacity: optional dedicated capacity (per-DPU pricing) for predictable heavy workloads
Pricing
SQL queries: $5 per TB of data scanned, rounded up to a 10 MB minimum per query (as of 2026)
Failed queries: free; cancelled queries billed for data scanned so far
Provisioned Capacity: hourly per-DPU pricing instead of per-TB, for steady high-volume use
Hidden costs: S3 storage/requests and Glue catalog charges are billed separately
When to Use It
✅ Ad-hoc SQL over data already sitting in S3
✅ Spiky or infrequent query workloads (pay only when querying)
✅ Teams with no bandwidth to operate a Trino/EMR cluster
✅ Log and event analysis (ALB, CloudTrail, VPC Flow Logs)
✅ Serving as the query layer for an S3 data lake with Glue
When NOT to Use It
❌ Constant heavy workloads — per-TB fees exceed a dedicated cluster's cost
❌ Sub-second latency dashboards (queries typically take seconds)
❌ Unpartitioned raw data you can't reformat (every query scans everything)
❌ Cross-cloud or many non-AWS sources (Trino/Starburst connect more natively)
❌ Workloads needing engine tuning, custom connectors, or long-running queries
Common Use Cases
Log analytics: query CloudTrail, ELB, and application logs in place
Data lake SQL: the default query layer over Glue-cataloged S3 data
One-off investigations: answer questions over cold data without loading a warehouse
ETL-lite: CTAS/INSERT INTO jobs that convert CSV to partitioned Parquet
BI backends: QuickSight and other tools querying S3 through Athena
Athena vs Alternatives
vs self-managed Trino: Athena is zero-ops but less tunable; a Trino cluster wins on control, connectors, and cost at sustained high volume
vs EMR (Presto/Trino): EMR gives cluster-level tuning for EC2 + ~25% surcharge; Athena removes all ops for $5/TB
vs Starburst Galaxy: Galaxy offers managed Trino with more connectors and cross-cloud reach; Athena is simpler and more AWS-native
vs Redshift Spectrum: similar per-TB S3 scanning, but Spectrum requires a Redshift cluster; Athena stands alone
vs BigQuery: comparable serverless per-TB model on Google Cloud, with its own storage layer
Unique Strengths
True serverless: no clusters, no warm-up management, no idle spend
Instant start: from S3 files to SQL results in minutes
AWS ecosystem: deepest integration with Glue, Lake Formation, and QuickSight
Transparent pricing: one number ($5/TB scanned) you can directly engineer down
Bottom line: If you searched for a "managed Presto service" and your data lives in S3, Athena is the answer with the least friction: the real Presto/Trino engine, fully serverless, $5 per TB scanned. Partition your data and store it as Parquet, and it's remarkably cheap; skip that step and the bill will teach you. Move to self-managed Trino or Starburst only when volume, latency, or connector needs outgrow it.