Serverless data lake and analytics with S3, Glue, and Athena
Store everything once in S3, catalog it with Glue, and query it in place with Athena, so you pay for compute only when a query actually runs.
Storage and compute, finally separated
A traditional data warehouse couples storage and compute: the data lives inside a database engine that has to be running (and billed) before you can ask it anything. A serverless data lake breaks that coupling. Amazon S3 becomes the single durable source of truth for all data, and the query engine is a separate, on-demand service that reads straight from S3.
That separation is the whole point. S3 gives you effectively unlimited, highly durable object storage for structured, semi-structured, and unstructured data in one place, at storage prices rather than database prices. Amazon Athena is a serverless, interactive query service that runs standard SQL directly against that S3 data, with no clusters to provision and no servers to manage. Because Athena is serverless, you are billed for the queries you run rather than for an always-on engine, and storage keeps costing the same whether or not anyone is querying it.
Decoupling storage from compute: one S3 lake, many on-demand engines
Trace
A traditional warehouse couples storage and compute inside one always-on engine that bills continuously. The serverless lake breaks that coupling: S3 is the single durable source of truth at storage prices, and several independent, on-demand engines (Athena, EMR, Redshift Spectrum, SageMaker) read straight from it and bill only while a job runs.
Zones, the crawl, and the shared catalog
Data does not arrive query-ready. In this pattern the lake is organized into zones inside S3: a raw zone that holds data exactly as it was ingested (often verbose CSV or JSON), and a curated zone that holds cleaned, optimized data ready for analytics. An AWS Glue ETL job reads the raw zone, transforms and cleans the records, and writes them into the curated zone. AWS Glue is a serverless data integration service, so the transformation runs without you managing any Spark cluster.
Athena still needs to know the shape of the data, because S3 objects have no schema by themselves. That is the job of the AWS Glue Data Catalog, a central metadata store that holds table definitions (columns, types, and the S3 location of each table). A Glue crawler scans the data in S3, infers its schema, and registers or updates the corresponding table in the Glue Data Catalog. Athena then uses that catalog as its metastore: you write a SQL query against a table name, and Athena reads the underlying objects from the S3 location the catalog points to.
Serverless data lake: S3 storage, Glue catalog and ETL, Athena query
Trace
Raw data lands in an S3 raw zone straight from ingestion. A Glue ETL job rewrites it as partitioned Parquet in the curated zone, and a Glue crawler records the schema in the Glue Data Catalog. Athena then runs SQL directly against the curated S3 data using the catalog as its table metastore, so nothing needs to be loaded into a running database and compute is billed only per query.
Why Parquet and partitions cut the bill
Athena charges based on the amount of data it scans to answer each query, so the cheapest and fastest query is the one that reads the fewest bytes. This is why the curated zone stores data as Apache Parquet rather than raw CSV or JSON. Parquet is a compressed, columnar format: a query that selects three columns reads only those three columns' data instead of every field in every row, and compression shrinks the bytes on disk. Converting CSV to Parquet is the canonical transformation the Glue ETL job performs.
Partitioning compounds the savings. When the curated data is laid out in S3 by a partition key such as date or region, and queries filter on that key, Athena can skip entire partitions it does not need to read. Columnar format plus compression plus partition pruning together mean Athena scans a small slice of the lake instead of all of it, which lowers both the query cost and the query latency at the same time.
Why Parquet and partitions cut the bill: scanning a small slice
Trace
Athena charges by bytes scanned, so the cheapest query reads the fewest bytes. The Glue ETL job rewrites raw CSV/JSON as compressed, columnar Parquet partitioned by date. A query that filters on the partition key lets Athena prune whole partitions, and columnar layout means only the selected columns of the matching partition are read.
Governance and what this teaches for the exam
Once many teams query one shared lake, access control becomes the hard part. AWS Lake Formation sits on top of the Glue Data Catalog and lets you grant fine-grained permissions (down to specific databases, tables, columns, and rows) centrally, instead of hand-writing S3 bucket policies for every consumer. The catalog stays the single place where both schema and permissions are defined.
For the exam, recognize the shape of the scenario: a question that describes lots of data already sitting in S3 and a need to run ad hoc SQL 'without loading it into a database' or 'without managing servers' is pointing at Athena, with the Glue Data Catalog as its metastore and Glue crawlers or ETL jobs preparing the data. When the same question asks how to make those queries cheaper or faster, the answer is converting the data to a columnar format like Parquet, compressing it, and partitioning it so Athena scans less. Reach for a provisioned warehouse like Amazon Redshift only when the workload is sustained, high-concurrency reporting rather than intermittent ad hoc queries.
Central governance: Lake Formation over the shared Glue catalog
Trace
Once many teams query one shared lake, Lake Formation sits on top of the Glue Data Catalog and grants fine-grained permissions (database, table, column, row) centrally, instead of hand-writing an S3 bucket policy per consumer. Every governed engine checks the catalog, and Lake Formation vends the temporary S3 credentials, so each team sees only what it is allowed to.
