Amazon Athena is a serverless, Trino-based SQL engine that queries data in Amazon S3 with no clusters to manage and pricing of $5 per TB scanned. This explainer covers its architecture, engine v3, Iceberg support, and when to pick it over Redshift Spectrum.
Most teams meet Amazon Athena the same way: data is already sitting in Amazon S3, someone needs to run a SQL query against it, and nobody wants to stand up a cluster to do it. You point Athena at the bucket, define a table, and run SELECT. There is nothing to provision, patch, or scale. That convenience is also the source of every surprise people hit later, from runaway scan bills to confusion about how it relates to Redshift, Glue, and Iceberg, which most new S3 lakes now use.
This post is the overview. If you are here for the tuning checklist (partitioning layouts, compression codecs, CTAS rewrites), that lives in our AWS Athena cost and performance optimization guide. Here we cover what Athena is, how the engine works, where Apache Iceberg fits, and how to decide between Athena and the Redshift options that look similar on paper.
What Amazon Athena is
Amazon Athena is a serverless, interactive query service that runs standard SQL directly against data stored in Amazon S3, with no infrastructure to manage and pricing based on the amount of data each query scans. You define a schema over files that already exist in S3, and Athena reads them in place. There is no ingestion step and no separate storage layer that you pay to keep running.
The model is schema-on-read. Your data stays as Parquet, ORC, JSON, CSV, or Avro objects in a bucket. The table definition is metadata that tells Athena how to interpret those bytes: column names, types, file format, and partition layout. Because the table is just a view over files, you can drop and recreate it without touching a single object, and let multiple engines read the same files. Athena is the query layer, S3 is the storage layer, and the two scale independently. You are not sizing a warehouse to match peak load or paying for idle compute overnight. You pay per query, and only for the bytes that query reads.
How Athena works under the hood
Athena is built on open source query engines. The SQL engine is a managed fork that tracks Trino and Presto, so the dialect, functions, and execution model will feel familiar to anyone who has used either. When you submit a query, Athena parses it, builds a distributed plan, pulls table and partition metadata from a catalog, reads the relevant objects from S3, executes the plan across a pool of compute it manages for you, and writes results to an S3 location you configure, or to Athena-managed result storage (available since June 2025, at no cost) if you skip that step.
The catalog is where Glue enters the picture. Athena uses the AWS Glue Data Catalog as its metastore, the central registry of databases, tables, columns, and partition locations. A Glue crawler can populate the catalog automatically by inferring schema from your files, or you can define tables yourself with DDL. The same catalog is shared by Glue ETL jobs, Amazon EMR, and Redshift, which is why a table defined once can be queried by several services. The Data Catalog is billed separately from Athena under Glue pricing. For a deeper treatment of the catalog and Glue's job model, see our complete guide to AWS Glue.
One consequence of the serverless model: query compute is drawn from a shared, multi-tenant pool. Most of the time you will not notice, but during regional peak hours a large ad-hoc query can queue or run slower than it would on dedicated hardware. Zero idle cost in exchange for less predictable latency is the trade you are making.
Athena engine version 3, launched in October 2022, is the only engine available for new workgroups. It tracks upstream Trino closely and enforces ANSI SQL more strictly than v2 did, so if you still have a v2 workgroup, test before you flip the version: CONCAT requires at least two arguments, nested columns in GROUP BY must be double quoted, and the Iceberg time-travel syntax is FOR TIMESTAMP AS OF rather than FOR SYSTEM_TIME AS OF.
Pricing: you pay for bytes scanned
Standard Athena queries cost $5 per terabyte of data scanned, billed by the bytes actually read from S3, rounded up to the nearest megabyte, with a 10 MB minimum per query. Failed queries are not charged. Cancelled queries are charged for whatever was scanned before the cancel, and that includes queries killed by a workgroup data-scanned limit. There is no charge for the service when no queries are running, which is what makes Athena attractive for spiky, intermittent workloads.
Because the meter is bytes scanned, your storage layout is your cost-control lever:
- Columnar formats. A query that selects four columns from a 200-column Parquet table reads only those four columns. The same query against raw CSV or JSON has to read every row in full. Converting to Parquet or ORC routinely cuts scan volume by an order of magnitude.
- Partitioning. Partitioning by a column such as date lets a
WHEREclause prune entire prefixes of S3 objects so they are never opened. A query over one day of a year's worth of logs should scan roughly 1/365 of the data. - Compression. Athena scans the compressed bytes. ZSTD or Snappy Parquet means fewer bytes read, which means a smaller bill, on top of the columnar pruning.
SELECT * with no filter on a large table reads everything and bills accordingly, and so does the AWS console's habit of running a preview query. The concrete tuning patterns (file sizing, bucketing, predicate pushdown, CTAS to reshape data) live in our dedicated Athena cost and performance guide.
For predictable, heavy usage there is Capacity Reservations: you reserve compute as Data Processing Units (one DPU is roughly 4 vCPUs and 16 GB) at $0.30 per DPU-hour, with a 4 DPU minimum and, since February 2026, a 1-minute billing minimum. The arithmetic for the break-even is simple. The smallest reservation, 4 DPUs around the clock, is $1.20 an hour or about $29 a day, which buys you roughly 5.8 TB of per-query scanning at $5/TB. If your workgroup scans more than that per day, or you need queries to stop queueing behind other tenants, reserved capacity wins. If your daily scan volume is in the hundreds of gigabytes, stay on per-query billing. Real reservations for production workloads are usually larger than 4 DPUs, so run the same arithmetic with the DPU count your queries actually consume.
Partition projection
Partition projection changes both performance and operations. Instead of storing every partition's location in the Glue Data Catalog and looking them up at query time, you describe the partition scheme as table properties, a range and a type, and Athena computes partition values and locations in memory. The GetPartitions call to Glue disappears, and you no longer need a crawler to register new partitions as data lands.
CREATE EXTERNAL TABLE logs (
request_id string,
status int,
message string
)
PARTITIONED BY (dt string)
STORED AS PARQUET
LOCATION 's3://my-bucket/logs/'
TBLPROPERTIES (
'projection.enabled' = 'true',
'projection.dt.type' = 'date',
'projection.dt.range' = '2023-01-01,NOW',
'projection.dt.format' = 'yyyy-MM-dd',
'projection.dt.interval' = '1',
'projection.dt.interval.unit'= 'DAYS',
'storage.location.template' = 's3://my-bucket/logs/${dt}/'
);
The catch is that projection only applies when the table is read through Athena SQL. Read the same table from Redshift Spectrum, Athena for Spark, or EMR and they fall back to standard catalog partitions. And if more than half of your projected partitions are empty, the in-memory enumeration can be slower than plain catalog partitions, so projection suits dense, predictable layouts such as daily logs rather than sparse ones.
Athena and Apache Iceberg
For years, Athena tables were read-mostly. You could append files, but row-level UPDATE and DELETE were not part of the picture, because plain Hive-style tables on S3 have no transaction layer. Apache Iceberg closes that gap, and Athena supports it natively.
Athena supports read, time travel, write, and DDL on Apache Iceberg tables, which brings ACID transactions, row-level INSERT, UPDATE, DELETE, and MERGE, schema evolution, hidden partitioning, and snapshot-based time travel to data sitting in S3. Athena creates and operates on Iceberg v2 tables. Time travel reads a consistent snapshot as of a timestamp or snapshot ID, which means you can query the table as it looked yesterday without keeping a separate copy:
-- Query the table as of a point in time
SELECT * FROM orders FOR TIMESTAMP AS OF (current_timestamp - interval '1' day);
-- Or as of a specific snapshot
SELECT * FROM orders FOR VERSION AS OF 949530903748831860;
Two operational details matter before you lean on DML. First, Athena SQL only does merge-on-read: UPDATE, DELETE, and MERGE INTO always write positional delete files, and copy-on-write table properties are silently ignored. Every row-level change adds delete files that readers must apply at query time, so a table taking heavy update traffic gets slower to read until you compact it. Second, that compaction is your job on plain Iceberg tables: schedule OPTIMIZE ... REWRITE DATA to fold delete files back into data files and VACUUM to expire old snapshots, or read latency and metadata size both creep up.
Iceberg also changes how partitioning works. With hidden partitioning, the table tracks the relationship between a column and its partition transform in metadata, so queries do not need a special WHERE clause to benefit from pruning, and you can evolve the partition scheme without rewriting old data. That is a real operational improvement over the partition projection approach above, though projection still has a place for append-only log tables that do not need DML.
If you do not want to run compaction yourself, AWS S3 Tables (table buckets) provide managed Iceberg tables with automatic compaction and snapshot maintenance. For the conceptual grounding before choosing, our pieces on Iceberg vs Delta Lake and the broader data lake architecture put these formats in context, and we have a practical lakehouse integration guide for teams already running Iceberg.
Beyond SQL: federation and Apache Spark
Athena is not limited to S3. Through Athena Federated Query, a connector lets a single SQL statement join S3 data with sources such as Amazon DynamoDB, PostgreSQL, MySQL, Snowflake, Amazon DocumentDB, OpenSearch, and Redshift. Since April 2026, connectors for a dozen common sources are managed by AWS and registered as Glue Data Catalogs, with no Lambda function in your account; the rest, and anything you build with the Query Federation SDK, still run as Lambda connectors. Either way, the connector translates Athena's requests into each source's native API, so you can correlate a data lake table with operational data without an ETL pipeline copying it into S3 first. Federated scans bill at the same $5/TB. The classic pattern here, exploratory analysis and ETL with Presto-style federation over Glue-cataloged data, is covered in our Presto and AWS Glue walkthrough.
There is also Athena for Apache Spark, a serverless Spark environment for work that does not fit cleanly into SQL: complex transformations, ML feature engineering, iterative exploration. It comes in two flavors. PySpark engine version 3 uses notebooks in the Athena console; the newer Apache Spark 3.5 runtime (November 2025) runs from SageMaker Unified Studio notebooks or any Spark Connect client, not from the Athena console. Both use the same Glue Data Catalog as the SQL engine. Spark applications are billed at $0.35 per DPU-hour, where one DPU is 4 vCPUs and 16 GB of memory, with no charge for the console notebook. You get Spark without operating an EMR cluster, with the same caveat as the rest of Athena: shared serverless capacity over guaranteed throughput.
A workgroup is where you put the per-query data-scanned limit so a single bad SELECT * cannot run up a four-figure bill (remember that a limit-cancelled query still bills for what it scanned). Workgroups also isolate queries, set the result location and encryption, and are the unit you attach to a capacity reservation. Use separate workgroups to split costs between teams and to apply different controls to ad-hoc analysts versus production pipelines.
When to use Athena, and when not to
Athena is the right tool when your data lives in S3, your query patterns are interactive or intermittent, and you would rather not run a warehouse around the clock. It shines for log analytics, ad-hoc exploration, lightweight ETL via CTAS, and serving as the SQL front door to a data lake. The decision that trips people up most often is Athena versus the Redshift options, because all three can query S3.
| Amazon Athena | Redshift Spectrum | Redshift Serverless | |
|---|---|---|---|
| Compute model | Fully serverless, shared pool | Runs on your Redshift cluster's compute | Serverless Redshift (RPU-based) |
| Where data lives | S3 (plus federated sources) | S3, joined with Redshift tables | Redshift managed storage, plus S3 via Spectrum |
| Pricing | $5 per TB scanned (or DPU capacity) | $5 per TB scanned on S3 + Redshift compute | Billed per Redshift Processing Unit-hour |
| Latency profile | Variable under load, no idle cost | Tied to cluster size, more consistent | Consistent, scales with usage |
| Best for | Ad-hoc and intermittent S3 queries | Joining S3 data with an existing warehouse | Warehouse workloads without cluster management |
| Setup overhead | Define a table, run SQL | Requires a Redshift cluster | Provision a serverless workgroup |
Athena and Spectrum share the $5 per TB external-scan price; the difference is whether you are also paying for Redshift compute and getting Redshift's predictability in return. Redshift Serverless is the pick when you want full warehouse semantics (high concurrency, consistent low latency, materialized views, result caching) without managing a cluster.
Athena is the wrong choice for sub-second BI dashboards refreshing for hundreds of concurrent users, where the shared pool and per-query planning show up as latency. It is also the wrong choice for large, constant workloads: past the break-even above, per-TB scanning costs more than reserved capacity or a right-sized warehouse running the same queries all day.
Two things readers get wrong
- Cancelled queries still bill. A workgroup data-scanned limit caps the damage from a runaway query, but you pay for everything scanned up to the cancel.
- Iceberg DML is merge-on-read only, and compaction is on you. Heavy
UPDATE/DELETEtraffic without scheduledOPTIMIZEandVACUUMdegrades read performance, unless you are on S3 Tables.
If you are weighing Athena against Redshift, Snowflake, or an Iceberg-based lakehouse for a specific workload, our team helps data teams design and tune these architectures for cost and performance.
